Develop Reference

Issues running obfuscated DEX modules - AbstractMethodError

I'm developing an Android application based on a main APK installed on the mobile device, and some android modules that are compiled to a .dex file. These files are loaded at runtime by the main application and the classes inside the .dex files are instantiated via Dynamic Dex Loading.
I'm facing some issues related to proguard, as even if I use the #Keep annotation on exposed methods in the modules and the main APK and I tell to proguard to keep interfaces methods, when I call one of the methods implemented in a module i get:
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.android.myproject, PID: 13893
java.lang.AbstractMethodError: abstract method "z.a com.android.myproject.MyClass.mymethod()"
at com.android.myproject.MainService.H(:784)
at com.android.myproject.MainService.M(:258)
at com.android.myproject.MainService.a0(:198)
at com.android.myproject.MainService.U(:148)
at com.android.myproject.MainService.C(:133)
at com.android.myproject.MainService.onServiceConnected(:90)...
If i try to debug, and i place a breakpoint right on the method call, using the "Evaluate Expression" tool in Android Studio I'm able to call the method with success, but if I let it execute on its own it crashes with the previous exception.
Can someone help me please? Thank you very much

Is Android Gradle Plugin test apk builder automatically multidexing my test apk? If so, why is this generating "NoSuchMethodError"

This all started with this error when running instrumentation tests:
java.lang.NoSuchMethodError: No static method closeQuietly(Ljava/net/ServerSocket;)V in class Lokhttp3/internal/Util; or its super classes (declaration of 'okhttp3.internal.Util' appears in /data/app/com.example-vKdPJoTLl49ntRbZfsRBqQ==/base.apk!classes2.dex)
at okhttp3.mockwebserver.MockWebServer$2.execute(MockWebServer.java:333)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
I went looking into the generated test.apk to see what was present/missing in dex files.
First thing I noticed is that the test apk has two .dex files. Why? I'm not using multidex (and IIRC multidex doesn't work on test apks anyways). I then added up the two "referenced method counts" and sure enough I'm over the 65k limit. So is AGP auto-multi-dexing my test apk?
Furthermore I see the "missing" method in the first dex.
Why is it listed as a "reference" not a "defined" method? It's not like there is an OkHttp Util class provided by the framework.
In the initial crash, it said it can't find method in classes2.dex. Why is it looking in classes2.dex? Why not look in both?
I'm keeping everything in my test apk (using proguard but keeping everything) (maybe this explains the +65k ref methods). So why is this getting stripped/screwed with in the first place.
UPDATE:
It turns out this method was needed in my app .apk (not the test .apk). When I updated my proguard rules for the app apk everything worked. I still don't know why this class is needed in-app?

java.lang.NoSuchMethodError:
No static method closeQuietly(java.net.ServerSocket) in class okhttp3.internal.Util;
method closeQuietly(java.net.ServerSocket) might not be in use.
to explicitly keep it:
-keep class okhttp3.internal.Util {
public static void closeQuietly(java.net.ServerSocket);
}

I don't know how I didn't know this but apparently multidex is enabled by default on API 21+
https://developer.android.com/studio/build/multidex#mdex-on-l
Therefore, if your minSdkVersion is 21 or higher multidex is enabled
by default, and you do not need the multidex support library.
So yeah, this is normal. What might be happening is that the class is just not in the first dex file.

NoClassDefFoundError ObjenesisStd on Android API 19

I'm getting the following crashing during an instrumentation test ONLY on emulators running API v19. If I run on newer versions everything works fine.
03-01 20:26:18.781 2878-2878/? E/MonitoringInstrumentation: Exception
encountered by: Thread[main,5,main]. Dumping thread state to outputs
and pining for the fjords.
java.lang.NoClassDefFoundError: org.objenesis.ObjenesisStd
at org.mockito.internal.creation.jmock.ClassImposterizer.(ClassImposterizer.java:36)
at org.mockito.internal.creation.jmock.ClassImposterizer.(ClassImposterizer.java:29)
at org.mockito.internal.util.MockCreationValidator.isTypeMockable(MockCreationValidator.java:17)
at org.mockito.internal.util.MockCreationValidator.validateType(MockCreationValidator.java:21)
at org.mockito.internal.creation.MockSettingsImpl.validatedSettings(MockSettingsImpl.java:133)
at org.mockito.internal.creation.MockSettingsImpl.confirm(MockSettingsImpl.java:127)
at org.mockito.internal.MockitoCore.mock(MockitoCore.java:50)
at org.mockito.Mockito.mock(Mockito.java:1243)
at org.mockito.Mockito.mock(Mockito.java:1120)
The problem is this line:
java.lang.NoClassDefFoundError: org.objenesis.ObjenesisStd
My app is multi-dex, and I'm using dexmaker-mockito for androidTestCompile. I'm at a complete loss why this only breaks on an older API. It started happening when I added another module to my project, which is a pure java module with no dependency on mockito.

This exception (ClassNotFoundException) tells you about a unmet dependency at runtime: the JVM needs to load a class; which is not present in the class path.
Here it is Mockito that needs Objenesis. Normally that library should be pulled automatically when you a system like maven and give the correct dependency to Mockito.

directExecutor method missing in guava library

I'm using google's grpc library in my android app which relies on the google guava library. For some reason the guava embedded in grpc doesn't have 'directExecutor' method in the class MoreExecutors. But the method is present in the github version? What accounts for the discrepancy?
In a class called ClientCallImpl is where the call to directExecutor is made. On the import statement(import static com.google.common.util.concurrent.MoreExecutors.directExecutor;) AndroidStudio shows a can't resolve symbol message, but the build doesn't fail. The exception is raised when the call is made during execution.
Error Message
FATAL EXCEPTION: SyncAdapterThread-1
Process: com.asdf.asdf, PID: 4025
java.lang.NoSuchMethodError: No static method directExecutor()Ljava/util/concurrent/Executor; in class Lcom/google/common/util/concurrent/MoreExecutors; or its super classes (declaration of 'com.google.common.util.concurrent.MoreExecutors' appears in /data/data/com.fentale.dalol/files/instant-run/dex/slice-guava-jdk5-17.0_a8ada10dcaf113cb6e3b4d3e5b46975833f8ae8f-classes.dex)
at io.grpc.internal.ClientCallImpl.<init>(ClientCallImpl.java:100)
at io.grpc.internal.ManagedChannelImpl$RealChannel.newCall(ManagedChannelImpl.java:320)
at io.grpc.internal.ManagedChannelImpl.newCall(ManagedChannelImpl.java:299)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:130)
at com.fentale.dalol.nano.DalolGrpc$DalolBlockingStub.topPosts(DalolGrpc.java:365)
EDIT
It seems the problem is that my project has dependencies on both guava-18.0 and guava-jdk5-17.0. The method I want directExecutor is only defined in the MoreExecutors class of guava-18, not 17. But the code is looking for it in the latter version of the class. How can I resolve this.

My app had a dependency on the youtube library which inturn depended on guava. However youtube's guava dependency is from a different source than grpc's and using an older version. Two versions of the guava jar existed in the app and grpc was accessing youtube's older guava version rather than its own, which caused the problem.
compile('com.google.apis:google-api-services-youtube:v3-rev164-1.21.0') {
exclude module: 'guava-jdk5'
}

Native application crashes on Android L

I have a native application that always worked on Android KitKat with both Dalivik and ART runtimes, but it now crashes on Android L with the following trace:
E/art(12810): dlopen("/data/app-lib/com.mylib.example", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"...
D/AndroidRuntime(12810): Shutting down VM
E/AndroidRuntime(12810): FATAL EXCEPTION: main
E/AndroidRuntime(12810): Process: com.mylib.example, PID: 12810
E/AndroidRuntime(12810): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"...
E/AndroidRuntime(12810): at java.lang.Runtime.loadLibrary(Runtime.java:364)
E/AndroidRuntime(12810): at java.lang.System.loadLibrary(System.java:610)
Is ART runtime in Android L different from KitKat? There is no new NDK available yet, therefore, how to avoid this crash, because it seems that the function issetugid is no longer supported.

The issue has been fixed in the final Android 5.0 release. There is no need to re-compile existing binaries.
However, if the native lib is compiled with target android-21, it fails on previous Android versions (< 5.0)

I think i may have the answer, please correct me if iam wrong.I had faced similar issue and now its fixed (or i have found a workaround rather)
while registering native method to JNI, there are two ways of doing it.
1) Implement JNI_OnLoad() method in your .cpp file and register your native methods with the
appropriate classes.
Check- http://developer.android.com/training/articles/perf-jni.html#native_libraries
example - https://android.googlesource.com/platform/development/+/master/samples/SimpleJNI/jni/native.cpp
2) there is a particular naming convention to follow for the native methods, where the class path (including package) have to be added.
Check - http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp615
Here we need not implement any method. The JVM discovers the native method from the symbol names it self from the binary.
The first method doesn't seem to work in Android ART runtime (ART is Optional in kitkat and it will be the only runtime in Lolipop).I am not not sure why it doesnt work. but i think the reason is because the way ART performs.(The bytecodes are converted and cached during install time itself instead of runtime, so that app runs faster). So since the native libs are not loaded (on_load is not called) the conversion to machine code fails at some point
Use the second method to register natives. it should work.
Only disadvantage is now your function names will be and long and will look horrible (i bet none of the function will fit in 100char limit).bye bye function name readability.
Hope this helps
Cheers,
Shrish