Solving the problem of android_65535

People who have done larger projects know that when the app is large to a certain extent, there will be 65535 this error, that is, 64K, that is, an app package, the number of methods can not exceed 65,535, more than will be divided into several Dex package, this individual asked why, Android restrictions. Can also be understood as a "Bug" for Android.

The Eclipse era, in order to solve this problem, is actually very painful, but it doesn't matter, now there is Android Studio, this problem is solved, the official also gave a real solution.

Here, to divide the situation, with Android5.0 (api:21) as a watershed.

After 5.0 to solve this problem, it is actually very simple

Minsdkversion  targetsdkversion multidexenabled True

As long as the minsdkversion is 21 (or more), just add more than one multidexenabled true in Build.gradle, just add it in the curly braces where minsdkversion is located.

However, at present, the domestic still many 4.X system, so, have to take the following way:

First, add library support

Android {    Defaultconfig {        ...        Minsdkversion         targetsdkversion        multidexenabled true} ...    } dependencies {  compile ' com.android.support:multidex:1.0.1 '}

Then, write your own application class, and let it inherit from Multidexapplication

<?xml version= "1.0" encoding= "Utf-8"? ><manifest xmlns:android= "http://schemas.android.com/apk/res/ Android "    package=" Com.example.myapp ">    <application            android:name=" Android.support.multidex.MultiDexApplication "> ...    </application></manifest>
public class MyApplication extends Multidexapplication {...}

If, this step, you cannot achieve, that is to say, your application has inherited the other application, you can do this:

public class MyApplication extends Someotherapplication {  @Override  protected void Attachbasecontext (Context Base) {     Super.attachbasecontext (context);     Multidex.install (this);}  }

It's that simple, two-step fix, and Android Studio is handy.

Specific further can be referred to the official. This is the official text (or directly click on the link above).

Applications with more than 64K configuration as the Android platform continues to grow, the size of Android apps is increasing. When your app and its referenced libraries reach a certain size, you'll encounter build errors that indicate that your app has reached the limits of the Android app build architecture. Earlier versions of the build system reported this error as follows: Conversion to Dalvik format failed:unable to execute Dex:method ID not in [0, 0xFFFF]: 65536 newer version of an Droid build System Although the errors displayed are different, the same problem is indicated: trouble writing output:too many field references:131000; Max is 65536.You can try using--multi-dex option. These error conditions will display the following number: 65,536. This number is important because it represents the total number of references that code within a single Dalvik executable (DEX) bytecode file can invoke. This page describes how to bypass this limitation by enabling an app configuration called Dalvik executable subcontracting to enable your app to build and read the Dalvik executable subcontracting DEX file. About the 64K reference limit Android app (APK) file contains executable bytecode files in the form of Dalvik executable (DEX) files that contain compiled code to run your app. The Dalvik executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including methods in the Android framework method, library methods, and your own code. In the field of computer science, the term thousand (abbreviation K) represents 1024 (or 2^10). Since 65,536 equals 1024, this restriction is also referred to as the "64K reference limit". Prior to Android 5.0, the Dalvik executable sub-package supports Android 5.0 (API level 21) before the platform version uses the Dalvik runtime to execute the app code. By default, Dalvik restricts the app to use only a single Classes.dex bytecode file for each APK. To circumvent this limitation, you can use the Dalvik executable sub-package support library, which becomes part of your app's primary dex file and then manages access to other Dex files and their included code. Note: If youThe Dalvik executable that the project is configured with is Minsdkversion 20 or earlier, and you deploy it to a target device running Android 4.4 (API level 20) or earlier, Android Studio deactivates the Ins Tant Run. Android 5.0 and later versions of Dalvik executable packages support Android 5.0 (API level 21) and later versions using the runtime named ART, which natively supports loading multiple DEX files from the APK file. ART performs precompilation at app installation, scans Classesn.dex files, and compiles them into a single. oat file for Android devices to execute. Therefore, if your minsdkversion is 21 or higher, you do not need to Dalvik the executable to subcontract the support library. For more information about the Android 5.0 runtime, see ART and Dalvik. Note: If you set the app's minsdkversion to 21 or higher, when you use Instant Run, Android Studio automatically configures the app to perform Dalvik executable subcontracting. Since Instant Run is only available for the debug version of the app, you still need to configure the release build for Dalvik executable subcontracting to circumvent the 64K limit. Circumvent the 64K limit before you configure your app to support using 64K or more method references, you should take steps to reduce the total number of references to your app code calls, including methods defined by your app code or included libraries. The following strategies can help you avoid reaching the DEX reference limit: Check your app's direct and transitive dependencies-making sure that you're using any large dependency library in your app is more of a disadvantage than adding a lot of code to your app. A common inverse pattern is to add a very large library to the application just to use a few practical methods. Reducing your app code dependencies can often help you circumvent the Dex reference limit. Remove unused code with Proguard-enables code compression to run Proguard for your version build. Enabling compression ensures that the APK you deliver does not contain unused code. Using these techniques allows you to eliminate the need to enable Dalvik executable subcontracting in your app, while also reducing the overall size of the APK. Configure your app to Dalvik executable sub-package set your app project to use the Dalvik executable package configuration requires the following modifications to your app project, depending on the minimum Android version supported by your app。        If your minsdkversion is set to 21 or higher, you only need to set multidexenabled to true in the module-level Build.gradle file, as shown here: Android {defaultconfig { ... minsdkversion targetsdkversion multidexenabled true} ...} However, if your minsdkversion is set to 20 or lower, you must use the Dalvik executable package support library as follows: Modify the module-level Build.gradle file to enable Dalvik executable subcontracting, and the Dalvik executable to subcontract the library Add as a dependency, as shown here: Android {defaultconfig {... minsdkversion targetsdkversion-Multidexen abled true} ...} dependencies {compile ' com.android.support:multidex:1.0.1 '} do one of the following, depending on whether you want to replace the application class: If you have not replaced the application class, Please edit the manifest file and set the Android:name:<?xml version= "1.0" encoding= "Utf-8" in the <application> tag as follows: ><manifest xmlns : android= "http://schemas.android.com/apk/res/android" package= "Com.example.myapp" > <application and Roid:name= "Android.support.multidex.MultiDexApplication" > ... </application></manifest> if you have replaced the Ap Plication class, make changes to it as follows to extend the MULTIDEXAPPlication (if possible): public class MyApplication extends Multidexapplication {...} Alternatively, if you replace the application class, but you cannot change the base class, you can replace the Attachbasecontext () method and call Multidex.install (this) to enable Dalvik executable subcontracting: public Class MyApplication extends Someotherapplication {@Override protected void Attachbasecontext (Context base) {super.     Attachbasecontext (context);  Multidex.install (this); After building the app, the Android build tool builds the main DEX file (Classes.dex) and the secondary Dex files (Classes2.dex and Classes3.dex, etc.) as needed. The build system then packs all of the DEX files into your APK. At run time, the Dalvik executable subcontracting API uses a special class loader to search for all the DEX files that apply to your method (instead of searching only in the main classes.dex file). Dalvik the limitations of the executable Subcontracting support Library Dalvik executables with some known limitations to incorporate into your application build configuration, you should be aware of these limitations and test them: the process of installing DEX files in a device data partition during startup is quite complex, If the secondary DEX file is large, it may result in an application unresponsive (ANR) error. In this case, you should apply code compression via Proguard to minimize the size of the DEX file and remove the unused portion of the code. Because of the Dalvik Linearalloc error (issue 22586), an app that uses Dalvik executable subcontracting may not start on a device that is running a platform version earlier than Android 4.0 (API level 14). If your target API level is below 14, be sure to test against these versions of the platform, because your app might have problems when it starts or loads a particular class of classes. Code compression can reduce or even possibly eliminate these potential problems. Due to the existence of the Dalvik Linearalloc limit (issue 78035),Therefore, if an application that uses the Dalvik executable package configuration makes a very large memory allocation request, a crash may occur during run time. Although Android 4.0 (API level 14) increases the allocation limit, apps may still experience this limitation on Android versions prior to Android 5.0 (API level 21). When declaring the required classes in the primary Dex file to build each DEX file for Dalvik executable subcontracting, the build tool performs complex decision making to determine the classes needed in the primary Dex file so that the application can start successfully. If any classes that are required during startup are not available in the primary DEX file, your app crashes with error java.lang.NoClassDefFoundError. The situation should not appear on code that is accessed directly from the application code, because the build tool recognizes these code paths, but may occur when the code path visibility is low, such as when the library you are using has complex dependencies. For example, if your code uses a self-test mechanism or calls a Java method from native code, these classes might not be recognized as required in the main DEX file. Therefore, if you receive java.lang.NoClassDefFoundError, you must declare them using the Multidexkeepfile or Multidexkeepproguard property in the build type to manually designate these other classes as primary DEX The required items in the file. If the class matches in a multidexkeepfile or Multidexkeepproguard file, the class is added to the main DEX file. Multidexkeepfile Properties The file you specify in Multidexkeepfile should contain one class per line and in Com/example/myclass.class format. For example, you can create a file named Multidex-config.txt, as follows: com/example/myclass.classcom/example/ Myotherclass.class You can then declare the file for the build type as follows: Android {buildtypes {release {multidexkeepfile file ' mult    Idex-config.txt ' ...} Keep in mind that Gradle will read the path relative to the Build.gradle file, so if MUltidex-config.txt and Build.gradle files are in the same directory, the above example will work. The Multidexkeepproguard property Multidexkeepproguard file uses the same format as Proguard and supports the entire Proguard syntax. For more information about the Proguard format and syntax, see the Keep Options section of the Proguard manual. The file you specify in Multidexkeepproguard should include the-keep option in any valid Proguard syntax. For example,-keep Com.example.MyClass.class. You can create a file named Multidex-config.pro, as follows:-keep class Com.example.myclass-keep class Com.example.MyClassToo If you want to specify all classes in a package, the file will look like this:-keep class com.example.** {*;}//All classes in the Com.example pack then,            You can declare the file for a build type as follows: Android {buildtypes {release {multidexkeepproguard ' Multidex-config.pro '    ...        } }} Dalvik executable sub-package Dalvik in the optimization development build will significantly increase the build processing time because the build system must make complex decisions about which classes must be included in the main Dex file and which classes can be included in the secondary Dex file. This means that incremental builds that use Dalvik executable subcontracting are typically time-consuming and may slow down your development progress. To shorten the build time of Dalvik executable subcontracting output, create two build variants with productflavors (a development customization and a release customization with different minsdkversion values). For development customizations, set Minsdkversion to 21. This setting enables a build feature called Pre-dexing, which uses the ART format for Android 5.0 only (API level 21) and later to generate the DaLvik executable file subcontracting output. For publishing customizations, set Minsdkversion to the actual minimum level of support that is appropriate for you. This setting generates a Dalvik executable package APK that is compatible with more devices, but takes longer to build. The following build configuration example shows how to set these customizations in the Gradle build file: Android {defaultconfig {... multidexenabled true} productflavo Rs {dev {//Enable pre-dexing to produce a APK that can is tested on//Android 5.0+ Witho            UT the time-consuming DEX build processes.            Minsdkversion} PROD {//The actual minsdkversion for the production version. Minsdkversion}} buildtypes {release {minifyenabled true proguardfiles get     Defaultproguardfile (' Proguard-android.txt '), ' Proguard-rules.pro '} }}dependencies {compile ' com.android.support:multidex:1.0.1 '} After you complete this configuration change, you can use the Devdebug variant of the app for incremental builds, which set dev product customization with Deb The properties of the UG build type are all in all. This will create a debug app that has Dalvik executable subcontracting enabled and disabled Proguard (because minifyenabled defaults to false). These settings enable the Android plug-in for Gradle to perform the following actions: Pre-dexing: Build each application module and each dependency into a separate DEX file. Add each DEX file to the APK without any modifications (code compression is not performed). Most importantly, the module Dex file does not perform a merge operation, so you can avoid long computations to determine the contents of the main Dex file. The benefit of these settings is that you can build quickly and incrementally, because only the DEX files of the modified modules are recalculated and repackaged during subsequent builds. However, these built-in APK can only be used for testing on Android 5.0 devices. However, because the configuration is implemented in a custom form, you retain the ability to perform a normal build using the lowest API level and Proguard code compression that is appropriate for the release. You can also build other variants, including the Proddebug variant build, which is built for a longer time but can be used for testing outside of development. Within the configuration shown, the Prodrelease variant will be the final Test and release version. For more information about using build variants, see Configuring Build variants. Tip: Because you have different build variants for different Dalvik executable subcontracting requirements, you can also provide different manifest files for different variants (so that only the manifest files that apply to API level 20 and earlier will change the <application> tag name). or create different application subclasses for each variant (so that only manifest files that apply to API level 20 and earlier will extend the Multidexapplication class or call Multidex.install (this)). Test Dalvik Executable Sub-package application writing instrument tests for Dalvik executable subcontracting applications, no additional configuration is required. Androidjunitrunner directly supports Dalvik executable subcontracting, provided that you use multidexapplication or replace the Attachbasecontext () method in your custom application object and call Multidex.install (this) to enable Dalvik executable file subcontracting. Alternatively, you can replace the OnCreate () method in Androidjunitrunner: public void onCreate (Bundle arguments) {Multidex.install (gettargetcontext    ()); Super.oncreate (arguments);   ...} Note: It is not currently supported to create a test APK using the Dalvik executable package.

　　

Solving the problem of android_65535