as applications continue to iterate, lines of business expand, and applications become larger (such as the integration of various third-party SDKs or publicly supported JAR packages, project coupling is high, the number of repetitive classes is increasing), I believe many people have encountered the following errors:
- Unexpected top-level EXCEPTION:
- Java.lang.IllegalArgumentException:method ID not in [0, 0xFFFF]: 65536
- At com.android.dx.merge.dexmerger$6.updateIndex (Dexmerger.java:501)
- At com.android.dx.merge.dexmerger$idmerger.mergesorted (Dexmerger.java:282)
- At Com.android.dx.merge.DexMerger.mergeMethodIds (Dexmerger.java:490)
- At Com.android.dx.merge.DexMerger.mergeDexes (Dexmerger.java:167)
- At Com.android.dx.merge.DexMerger.merge (Dexmerger.java:188)
- At Com.android.dx.command.dexer.Main.mergeLibraryDexBuffers (Main.java:439)
- At Com.android.dx.command.dexer.Main.runMonoDex (Main.java:287)
- At Com.android.dx.command.dexer.Main.run (Main.java:)
- At Com.android.dx.command.dexer.Main.main (Main.java:199)
- At Com.android.dx.command.Main.main (Main.java:103)
Yes, the number of Dex file methods in your app exceeds the maximum of 65536, so simply put, the app is bursting.
in the Android system, all the code for a App is in a Dex file. Dex is a jar-like archive that stores multiple Java compiled bytecode. Because the Android system uses the Dalvik virtual machine, you need to use Java Compiler after compiling the The class file is converted to a Dalvik executable class file. It is emphasized here that Dex and Jar are the same archive file, which is still a bytecode file corresponding to the Java code. When the Android system launches an app, one step is to optimize Dex , a process that has a special tool to handle, called dexopt . The execution of dexopt is performed the first time the Dex file is loaded. This process generates a ODEX file, which is optimised Dex . Performing ODex is much more efficient than executing Dex files directly. But in earlier Android systems, there was a limit to the linearalloc of dexopt : android 2.2 and 2.3 had only 5mb,android 4 buffers. x increased to 8MB or 16MB. When the number of methods exceeds the buffer size, dexopt crashes, causing the installation to fail.
Of course,Google seems to be aware of the current number of application methods of the problem, now in the API has provided a common solution, that is Android-support-multidex.jar . This jar package can support up to API 4 version ( Mutidexis supported by default onAndroid L and above).
Specific integration:
Add the following configuration to the project Build.gradle
- Android {
- Defaultconfig {
- //enabling Multidex support.
- Multidexenabled True
- }
- }
- dependencies {compile ' com.google.android:multidex:0.1 '}
The next integration has two steps:
I. Import Android-support-multidex.jar into the project from the Sdk\extras\android\support\multidex\library\libs directory
Two. If your project already contains the application class, then let it inherit the Android.support.multidex.MultiDexApplication class,
If your application has inherited other classes and does not want to make changes, there is another way to use it, overwrite the Attachbasecontext () method:
- Public class MyApplication extends Fooapplication {
- @Override
- protected void Attachbasecontext (Context base) {
- Super.attachbasecontext (base);
- Multidex.install (this);
- }
- }
Finally, the complete configuration in Build.gradle is given:
- Android {
- Compilesdkversion
- Buildtoolsversion "21.1.0"
- Defaultconfig {
- ...
- Minsdkversion
- Targetsdkversion
- ...
- //enabling Multidex support.
- Multidexenabled True
- }
- ...
- }
- dependencies {
- Compile ' com.android.support:multidex:1.0.0 '
- }
Android uses Android-support-multidex to solve the limit of Dex out of method number