2015-08-02 18 views
5

Un'app di esempio per la libreria ha ~ 67k metodi. Ha il multidex abilitato per superare il limite del metodo 65k. Sfortunatamente con multidex abilitato, l'app si arresta in modo anomalo a VerifyError quando si tenta di iniettare EndpointAdapter nell'attività principale.VerifyError nell'app multidex quando si inietta la dipendenza con Dagger

Questo problema non si verifica quando l'app è proguardata e il multidex è disabilitato, quindi deve essere causato dai problemi di multidex e di Dagger 1.

Sono sicuro che EndpointAdapter è nel file dex principale, ma alcune classi generate da Dagger si trovano nel secondo file dex generato da multidex. Questo problema si verifica sui dispositivi con API < 21 (ad esempio su genymotion con KitKat 4.4.4).

Qualche idea del perché si blocca con VerifyError?

FATAL EXCEPTION: main 
Process: pl.toro.libsample.debug, PID: 11775 
java.lang.VerifyError: pl/toro/lib/network/EndpointAdapter 
    at java.lang.Class.getDeclaredConstructors(Native Method) 
    at java.lang.Class.getDeclaredConstructors(Class.java:574) 
    at dagger.internal.loaders.ReflectiveAtInjectBinding.getConstructorsForType(ReflectiveAtInjectBinding.java:232) 
    at dagger.internal.loaders.ReflectiveAtInjectBinding.create(ReflectiveAtInjectBinding.java:168) 
    at dagger.internal.FailoverLoader.getAtInjectBinding(FailoverLoader.java:74) 
    at dagger.internal.Linker.createBinding(Linker.java:224) 
    at dagger.internal.Linker.linkRequested(Linker.java:141) 
    at dagger.ObjectGraph$DaggerObjectGraph.getInjectableTypeBinding(ObjectGraph.java:309) 
    at dagger.ObjectGraph$DaggerObjectGraph.inject(ObjectGraph.java:279) 
    at pl.toro.lib.app.BaseApplication.inject(BaseApplication.java:135) 
    ... 

Ecco uscita del tag MultiDex

VM with version 1.6.0 does not have multidex support 
install 
MultiDexExtractor.load(/data/app/pl.toro.libsample.debug-1.apk, false) 
Detected that extraction must be performed. 
Extraction is needed for file /data/data/pl.toro.libsample.debug/code_cache/secondary-dexes/pl.toro.libsample.debug-1.apk.classes2.zip 
Extracting /data/data/pl.toro.libsample.debug/code_cache/secondary-dexes/pl.toro.libsample.debug-1.apk.classes-1477675005.zip 
Renaming to /data/data/pl.toro.libsample.debug/code_cache/secondary-dexes/pl.toro.libsample.debug-1.apk.classes2.zip 
Extraction success - length /data/data/pl.toro.libsample.debug/code_cache/secondary-dexes/pl.toro.libsample.debug-1.apk.classes2.zip: 187777 
load found 1 secondary dex files 
install done 

EDIT

che ho passato a Dagger 2 e questo problema è stato risolto, al momento. Dagger 2 non utilizza più la riflessione, che è il principale fattore di questo problema.

+0

fa EndpointAdapter avere un costruttore che prende un parametro nella dex secondario? Inoltre, puoi confermare che questo errore si verifica dopo che il classloader è stato riparato? –

+0

Dovrò controllarlo. Ha il costruttore annotato '@ Inject' con 2 dipendenze ma non sono sicuro in quale dex dipendono le dipendenze. Per "patch" intendete dopo che il MultiDex è stato inizializzato e stampato il log "install done"? – tomrozb

+0

Sì, questo è quello che sto verificando, che Multidex ha finito con successo. Ultima domanda, quale versione di Android SDK stai usando? –

risposta

1

Come indicato in questo post del blog [1], state creando il grafico del pugnale dopo aver installato il multi-dex. Quindi in MultiDexApplication#attachBaseContext dopo la chiamata a super (o chiamando MultiDex.install() da soli).

[1] https://developers.soundcloud.com/blog/congratulations-you-have-a-lot-of-code-remedying-androids-method-limit-part-2

+0

Scusa ma non capisco. Che dopo chiamata a super? – tomrozb

+0

Scusa, se hai sottoclassi 'MultiDexApplication', devi creare il grafico di Dagger in' attachBaseContext' dopo aver chiamato 'super.attachBaseContext()'. Ha senso? – Jeroen

+0

Sei sicuro? Si chiama dopo "onCreate" o prima? Non uso più Dagger 1 quindi abbiamo bisogno di qualcun altro per confermare che risolve il problema. – tomrozb

Problemi correlati