Obsolete
Status Update
Comments
da...@gmail.com <da...@gmail.com> #2
can you share your android studio version
aa...@gmail.com <aa...@gmail.com> #3
Is this happening with Studio 3.0?
st...@gmail.com <st...@gmail.com> #4
Note: This worked for me on Windows 7 Pro 32-bit (with Android Studio 2.3.3). Seems like an issue with adt-branding module (which should contain the "/idea/AndroidStudioApplicationInfo.xml" resource).
ss...@gmail.com <ss...@gmail.com> #5
Hi, also happened on Mac Book Pro 15 retina mi-2015
MacOs Sierra 10.12.6
Android Studio 2.3.3
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
MacOs Sierra 10.12.6
Android Studio 2.3.3
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
st...@gmail.com <st...@gmail.com> #6
Thank you for this feedback. Your feedback helps make sure Android development tools are great! Given your issues has been resolved I am closing this issue.
ss...@gmail.com <ss...@gmail.com> #7
And even if passing the --multi-dex option to dx would be possible as mentioned in #2, we would still need to dynamically load the multiple dex files using custom code. In fact that's the part I'd like to see a solution built into the build tools for.
sz...@gmail.com <sz...@gmail.com> #8
Hi, in android maven plugin there is possibility to pass multi-dex option do dx and it's really simple to implement https://github.com/jayway/maven-android-plugin/pull/425 .
Is there any chance to add the same possibility in gradle plugin, then loading classes would be done via reflection in code
Is there any chance to add the same possibility in gradle plugin, then loading classes would be done via reflection in code
ts...@googlemail.com <ts...@googlemail.com> #9
We have also to deal with large android apps exceeding the dex limit. It would be already a big improvement for us to have a little DSL or a property to trigger the --multi-dex option. We are even using the entire Google Play Services from a separate DEX but the maintenance of the build-process is a nightmare. We just need that for Android 4.0+ and we have no problems to maintain a class loader hack on our own (which we are already doing).
Or another idea: Create a DSL where the dex-merge is disabled and instead of a single file, dex and include each dependency/library individually. This would speed up the build-process enormously (at least for our projects) because you can reuse all those single dex-files without merging them.
Or another idea: Create a DSL where the dex-merge is disabled and instead of a single file, dex and include each dependency/library individually. This would speed up the build-process enormously (at least for our projects) because you can reuse all those single dex-files without merging them.
xa...@android.com <xa...@android.com>
ss...@gmail.com <ss...@gmail.com> #10
See http://stackoverflow.com/a/25975702/1127485 for a quite clean work-around I've found recently. In particular, this does not involve patching the dx script to contain "--multi-dex" anymore.
Description
SDK tools version (available in the "About" section of the 'android' tool
UI): 22.3
Eclipse version: 20110218-0911
ADT plug-in version: 22.3
There is a well-known issue in Android when an app that reached DEX limit can't be built.
And looks like there is still no official solution from Google yet.
One of the best-known not official solutions is to split project and libraries classes like the following:
- keep only main project's classes.dex file
- move libraries classes.dex to assets folder
- during application startup dynamically read lib's classes.dex from the assets folder
(
STEPS TO REPRODUCE:
1. Try to build an app which has more class links than DEX limit
2. DEX limit error will occur
EXPECTED RESULTS:
Of course the best is to have an official solution to extend current DEX limit or at least there is a 'jar' task from 'java' plugin inside 'android' plugin.
Then it would really help to easy prevent packaging all library *.class files in the same classes.dex, simply by customizing 'jar' task like the following:
configure(jar) {
include 'classes.dex'
}
OBSERVED RESULTS: No 'jar' task, and resolving Android DEX limit issue is really difficult on gradle