Home/ Questions/Q 8409575
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T23:56:56+00:00

Project explained below is created and built using Eclipse Juno(4.2). We receive the following

  • 0

Project explained below is created and built using Eclipse Juno(4.2).

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:

2857 com.android.foo.bar
12 com.android.foo.bar.util
236 com.blah.yo.io
6 com.blah.yo.util
2 com.hmm
82 com.hmm.android.app
2761 com.hmm.android.common
2761 com.hmm.android.map
2761 com.hmm.android.map.common
.
.
.

A list of namespaces follows with similar numbers preceding them

Conversion to Dalvik format failed with error 2

Here’s an example of our project structure:

Conceptual structure:
A – main/non-library module

  • B – library module/Android dependency of A
    • C – library module brought in as an Android dependency of library module B
  • D – library module/Android dependency of A
  • E – library module/Android dependency of A
    • F – library module/Android dependency of E
    • G – library module/Android dependency of E, B, D(a common IO module used across the different modules)

Folder structure:

/Project A/

       B/*Android module structure*
       C/*Android module structure*
       D/*Android module structure*
       E/*Android module structure*
       F/*Android module structure*
       G/*Android module structure*

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.

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.

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.

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I recently came across your exact same issue. My main project references a lot of library projects so I can easily re-use my code.

    Lets say that 3 of my library projects both depend on the much used library, actionBarSherlock. In all 3 packages it will auto generate R.java and place ALL of the ids from actionbarsherlock into the new R.java. So now you have 4 R.java files (ActionBarSherlock, lib1, lib2, lib3) with many of the same ids being used.

    The trick to get around this is to declare the same package name in all your library projects AndroidManifest.xml so you don’t have so many identical ids.

    The other alternatives are:

    1) Build your projects with ant to create and load more than 1 dex file (Horrible solution) http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html

    2) Merge and simplify the code

    I hope this helps

    • 0