sorry mate! :( • Simple explanation: You have too many methods in the dex file • More specific explanation: You have too many methods (over 65.536 methods), that can being invoked, in the dex file
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); helloPeople(); } private void helloPeople() { Log.d(MainActivity.class.getSimpleName(), "How many methods are in this Application??"); } } How many methods are in this example? • 1 Activity w/ 2 methods • Compile the play service library • Question: How many methods are in the APK file? • Answer: ~20.000 methods (1/3 of 65K) • Solution: only compile what you need (e.g. com.google.android.gms:play- services-maps:7.8.0)
is coming from - https://github.com/mihaip/dex-method- counts - https://github.com/siggijons/dex- methods 2. Use smaller libraries - Repack libraries with JarJar 3. Proguard / Dexguard to shrink your code pros: Dexguard can shrink quite much cons: Increases your build time package com.stupid.dexlimit; import android.app.Activity; import android.os.Bundle; import android.util.Log; public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); helloPeople(); } private void helloPeople() { Log.d(MainActivity.class.getSimpleName(), "How many methods are in this Application??"); } }
have 1 dex file • Get around this limit by using 3rd party libraries - pros: we can build the project - cons: longer building time • Mult-Dexing library from Google - com.android.support:support-v4:21.0.0 - Easy to use • Dexguard offers split dexing - splitdexfile com.facebook.** - More complex to use with the obfuscation • Today we use Dexguard
for split dexing • Choose what goes to the secondary dex file! • Build can break on run time when certain code is in secondary dex file • Avoid always being on the edge of the limit • Compile time increases, when split dexing :( • The tools for split dexing is becoming much better • Smile :)