1

My APK is to big (to many methods) and as a solution I am trying to put some of the library classes (e.g. android/support/v4) to framework.jar. I pull framework.jar, extract the classes.dex, baksmali, add then android/support/v4, smali, build a new framework.jar, sign it, push to device and reboot device. Unfortunately I get some weird dalvikvm verifier errors:

FATAL EXCEPTION: main
Process: com.example.myapp, PID: 3792
java.lang.VerifyError: android/support/v4/view/ViewPager
at java.lang.reflect.Constructor.constructNative(Native Method)
at java.lang.reflect.Method.invokeNative(Native Method)
at dalvik.system.NativeStart.main(Native Method)
/system/framework/framework2.jar odex has stale dependencies
/system/framework/telephony-common.jar odex has stale dependencies
/system/framework/voip-common.jar odex has stale dependencies
/system/framework/mms-common.jar odex has stale dependencies
/system/framework/android.policy.jar odex has stale dependencies
/system/framework/services.jar odex has stale dependencies
/system/framework/apache-xml.jar odex has stale dependencies
/system/framework/webviewchromium.jar odex has stale dependencies
/system/framework/am.jar odex has stale dependencies
VFY: unable to resolve virtual method 283: Landroid/content/Context
.getCodeCacheDir ()Ljava/io/File
/system/framework/framework2.jar odex has stale dependencies
/system/framework/telephony-common.jar odex has stale dependencies
/system/framework/voip-common.jar odex has stale dependencies
/system/framework/mms-common.jar odex has stale dependencies
/system/framework/android.policy.jar odex has stale dependencies
/system/framework/services.jar odex has stale dependencies
/system/framework/apache-xml.jar odex has stale dependencies
/system/framework/webviewchromium.jar odex has stale dependencies
DexOpt: resolve class illegal access: Landroid/support/v4/app/BackStackRecord$2
-> Landroid/support/v4/app/BackStackRecord
DexOpt: resolve class illegal access: Landroid/support/v4/app/BackStackRecord$3
-> Landroid/support/v4/app/BackStackRecord

Any idea what I am doing wrong? I am just using one device for testing. So I do not want my apk to work on any other device.

I think it is related to:

Is it necessary to keep classes of the same package in the same dex while using multiple dex files

However I do not understand how framework would work since it contains is own separate dex file.

Community
  • 1
  • 1
joe-jeff
  • 324
  • 1
  • 9
  • 27

1 Answers1

2

It may be because apps using the support library (except yours, I guess) will now have the support library classes from two sources: one from the framework, and one included in their apps.

So you get an error like this, where (if I'm reading this error log correctly) an inner class is not allowed to access its parent:

DexOpt: resolve class illegal access:
Landroid/support/v4/app/BackStackRecord$3
-> Landroid/support/v4/app/BackStackRecord

If we assume that the BackStackRecord$3 and BackStackRecord classes ended up being brought in from two different sources, this is reasonable: BackStackRecord is not public (it's package-protected), so classes outside its package (which apparently includes "classes with the same package name but different source") are not allowed access. Or maybe the inner class is trying to access a private field, and is denied that access? Anyway, something like that.

It may work if you rename all the classes you add to the framework (and all the references they make to eachother), but... like the question comments say, you should probably use multidex instead.

Snild Dolkow
  • 6,669
  • 3
  • 20
  • 32
  • Again, I'd like to note that this is *pure speculation*. I have no actual proof or concrete analysis to support this. *Please* don't link this answer as an authorative source for anything. :P – Snild Dolkow Sep 07 '15 at 16:45