1

My Android application uses rather large number of non trivial external libraries. These libraries are all written in Java and simply added to the build path.

Launching the application from within Eclipse takes a REALLY long time, roughly 5 minutes. This is extremely frustrating!

I enabled the verbose android build output. This shows that the build process is iterating overall *.class files in the external libraries. I get hundreds of these lines:

...
Dx processing android/support/v4/app/FragmentTransaction.class...
Dx processing android/support/v4/app/FragmentManagerImpl$3.class...
Dx processing android/support/v4/app/LoaderManagerImpl.class...
...
Dx processing com/prosysopc/ua/client/ServerStatusListener.class...
...
Dx processing org/opcfoundation/ua/core/BrowseNextRequest.class...
...

(This is just a small sample, again I get hundreds of these for each *.class)

I am not really sure what the Dx tool is doing here, but it is definitely annoying!

Making matters worse this process is repeated for EVERY single launch, no caching no nothing...

Possible ideas:

  • Is there a cache for this somewhere? Where? Maybe it is readonly and thus does not persist?
  • Can I completely disable the "DX processing" step for my development builds?

Any possible solutions or at least ideas? This is really driving me crazy ;-)

Thanks!

Eric
  • 2,053
  • 2
  • 13
  • 6
  • Those libraries are android libraries required for operation of the application. So, no, don't disable them. I don't even think you can. – Vinay S Shenoy Oct 08 '12 at 08:02
  • This is just an example, I have other libraries with cause this as well. And I DO NOT want to remove the libraries but instead the "Dx Processing" step. – Eric Oct 08 '12 at 08:06
  • Just check out http://stackoverflow.com/questions/9332778/android-dx-processing-too-slow – Vinay S Shenoy Oct 08 '12 at 08:15
  • Dx is the tool which converts .class files to Android bytecode.. The libraries which are causing the slowdown seem to poorly written as mentioned in my linked answer.. – Vinay S Shenoy Oct 08 '12 at 08:17
  • Ah okay, I just found another answer [http://stackoverflow.com/questions/2883635/android-compilation-is-slow-using-eclipse](http://stackoverflow.com/questions/2883635/android-compilation-is-slow-using-eclipse) saying the same thing... Too bad... – Eric Oct 08 '12 at 08:22
  • Yeah.. Looks like something Google has to work on.. – Vinay S Shenoy Oct 08 '12 at 08:25

1 Answers1

1

The dx tool is able to merge dex files. So one option would be to pre-convert these libraries to dex format, and let dx merge them with your main application classes.

This workflow does not seem to be supported out of the box by the default ant build script, and I doubt the eclipse build has anything like this either. You will have to either perform some steps manually, or tweak the ant build script.

Some notes:

  1. For dx to recognize and merge a library, it needs to be a jar/apk/zip containing a classes.dex file
  2. You still need the original java jars around, so that you can compile against them. You would need to prevent the java jars from being passed to dx, and pass the dex jars instead.
  3. Things get even more "interesting" if you are using something like proguard :)

I'll leave the decision of whether all this work and hackiness is worth it up to you.

JesusFreke
  • 19,784
  • 5
  • 65
  • 68
  • Thanks a lot for your inputs, I started to look into this. But unfortunately it is way over my head... So I guess I have to live with this suboptimal situation until Google finally decides to fix their development tools... – Eric Oct 12 '12 at 13:49
  • Just out of curiosity, have you actually done something like this? – Eric Oct 12 '12 at 13:49
  • I did do a quick manual test to verify that it works, so I know dx is able to do this. The main complication is around how to get the build system to do this for you :) – JesusFreke Oct 12 '12 at 18:16