Note that there are some explanatory texts on larger screens.

plurals
  1. POAndroid: FIELDS_IDS_SIZE Dalvik dex file max reached when having multiple library modules
    primarykey
    data
    text
    <p>Project explained below is created and built using Eclipse Juno(4.2).</p> <p>We receive the following error when executing the Run Configuration for our Android application: Dx trouble writing output: Too many fields: 65757; max is 65536. By package:</p> <p>2857 com.android.foo.bar<br> 12 com.android.foo.bar.util<br> 236 com.blah.yo.io<br> 6 com.blah.yo.util<br> 2 com.hmm<br> 82 com.hmm.android.app<br> 2761 com.hmm.android.common<br> 2761 com.hmm.android.map<br> 2761 com.hmm.android.map.common<br> . . .</p> <p><em>A list of namespaces follows with similar numbers preceding them</em></p> <p>Conversion to Dalvik format failed with error 2</p> <p>Here's an example of our project structure:</p> <p>Conceptual structure: A - main/non-library module</p> <ul> <li>B - library module/Android dependency of A<br> <ul> <li>C - library module brought in as an Android dependency of library module B</li> </ul></li> <li>D - library module/Android dependency of A</li> <li>E - library module/Android dependency of A <ul> <li>F - library module/Android dependency of E</li> <li>G - library module/Android dependency of E, B, D(a common IO module used across the different modules)</li> </ul></li> </ul> <p>Folder structure:</p> <p>/Project A/</p> <pre><code> B/*Android module structure* C/*Android module structure* D/*Android module structure* E/*Android module structure* F/*Android module structure* G/*Android module structure* </code></pre> <p>At first we thought "wow, we've hit the max fields_ids_size so our app must have gotten that big", which it is a rather large app functionality-wise. </p> <p>After some attempts at cleanup/discovery on the issue we are doubtful this is the cause. After analyzing the classes.dex file for the fields_ids_size and attempting different things we find that we can shrink the number of fields_ids down if we remove the library modules and just include them into the main project. Horrible for code/module reuse across projects, but takes the number from the above error message from 65757 down to nearly 24,000. Likewise, if jar'ing up a library module and including it into the classpath of the dependent entity(whether its the main non-library module or a library module), the number also shrinks if you remove the Android dependency to that library module and just use the jar file.</p> <p>Seeing this, I took D from the example above and made it it's own standalone app with no dependencies/tie-ins to other modules and created the classes.dex file for it. Let's assume for this example that D has the namespace com.android.foo.bar. From the example error above this namespace was taking up 2857 fields ids when used as a library module of A. When compiled as it's own app and analyzing the classes.dex file, I saw this number fall to around 120 fields ids.</p> <p>This is a rather large issue for our app as we're hitting this upper limit. We do have a workaround of sorts, but it is rather clunky and time consuming. I'm hoping there is a solution for this to allow us to have these library references and not have the issue of the number of fields_ids for library modules seemingly being inflated causing this issue.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload