I recently updated my Song Scrapbook app to the latest version and also made sure to update all third-party APIs used by the app. One such third-party tool is the PayPal Android SDK which I use to monetize my app since I live in a country where the Google Wallet Merchant service is currently not supported - which means I cannot use the Play Store in-app or once-off purchase systems in my app.
However, after updating the PayPal SDK to the latest version in my app (via mavenCentral) I get the following error in Android Studio (version: 1.5.1) everytime I want to execute a PayPal transaction:
debug W/paypal.sdk: PayPalService created. API:19 PayPalSDK/PayPal-Android-SDK 2.13.3 (Android 4.4.4; samsung GT-I9060I; )
03-20 16:58:45.540 7804-7804/com.whitsoft.songscrapbook.debug W/ApplicationPackageManager: getCSCPackageItemText()
03-20 16:58:45.550 7804-7804/com.whitsoft.songscrapbook.debug W/ApplicationPackageManager: getCSCPackageItemText()
03-20 16:58:45.550 7804-7804/com.whitsoft.songscrapbook.debug I/dalvikvm: Could not find method com.google.android.gms.common.GooglePlayServicesUtil.isGooglePlayServicesAvailable, referenced from method com.paypal.android.sdk.at.a
03-20 16:58:45.550 7804-7804/com.whitsoft.songscrapbook.debug W/dalvikvm: VFY: unable to resolve static method 10405: Lcom/google/android/gms/common/GooglePlayServicesUtil;.isGooglePlayServicesAvailable (Landroid/content/Context;)I
03-20 16:58:45.610 7804-7804/com.whitsoft.songscrapbook.debug I/dalvikvm: Could not find method io.card.payment.CardIOActivity.checkSelfPermission, referenced from method io.card.payment.CardIOActivity.onCreate
03-20 16:58:45.610 7804-7804/com.whitsoft.songscrapbook.debug W/dalvikvm: VFY: unable to resolve virtual method 13172: Lio/card/payment/CardIOActivity;.checkSelfPermission (Ljava/lang/String;)I
03-20 16:58:45.820 7804-7843/com.whitsoft.songscrapbook.debug I/System: Loaded time zone names for "en" in 132ms (127ms in ICU)
03-20 16:58:45.840 7804-7804/com.whitsoft.songscrapbook.debug W/dalvikvm: threadid=1: thread exiting with uncaught exception (group=0x4168cbc0)
03-20 16:58:45.840 7804-7804/com.whitsoft.songscrapbook.debug E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.whitsoft.songscrapbook.debug, PID: 7804
java.lang.RuntimeException: Unable to start service com.paypal.android.sdk.payments.PayPalService#41e9c5a0 with Intent { cmp=com.whitsoft.songscrapbook.debug/com.paypal.android.sdk.payments.PayPalService (has extras) }: java.lang.IllegalStateException: Unable to extract the trust manager on a.a.k#41ff61a0, sslSocketFactory is class com.paypal.android.sdk.bn
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2987)
at android.app.ActivityThread.access$2100(ActivityThread.java:166)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1380)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5584)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.IllegalStateException: Unable to extract the trust manager on a.a.k#41ff61a0, sslSocketFactory is class com.paypal.android.sdk.bn
at a.ak.<init>(Unknown Source)
at a.ak.<init>(Unknown Source)
at a.am.b(Unknown Source)
at com.paypal.android.sdk.bt.<init>(Unknown Source)
at com.paypal.android.sdk.payments.PayPalService.a(Unknown Source)
at com.paypal.android.sdk.payments.PayPalService.onStartCommand(Unknown Source)
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2970)
at android.app.ActivityThread.access$2100(ActivityThread.java:166)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1380)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5584)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(Native Method)
03-20 17:03:46.103 7804-7804/? I/Process: Sending signal. PID: 7804 SIG: 9
I know this problem is not caused by the device on which I tested the app - as I have tested this app on two very different devices (Samsung Grand Neo and Cubot X15) and both devices produced similar errors. I tried googling the problem to try and solve the problem but after hours of searching found no solution.
Any assistance will be much appreciated.
SilSur.
So it took me roughly 5 hours to figure this one out - which I achieved through a step-by-step elimination of possible causes of the problem.
Turns out the real problem was my haste in trying to update the app. The reason being that the PayPal SDK 2.13.3 version has a new rule in the 'proguard-rules.pro' file that is very important to include:
Rule as follows:
# This is added for okhttp 3.1.2 bug fix as shown at https://github.com/square/okhttp/issues/2323
-keepclassmembers class * implements javax.net.ssl.SSLSocketFactory {
private javax.net.ssl.SSLSocketFactory delegate;
}
This prevents the minify (obfuscation) process of Gradle from removing IMPORTANT code from a previous bug-fix in the PayPal SDK that caused problems with the secure layer socket factory. So yeah - that was the fix: the updated app now works perfectly (just as required).
Lesson learnt: make sure your 'proguard-rules' are exactly as they are suppose to be!
Over & Out, SilSur.
This question already has answers here:
Libraries do not get added to APK anymore after upgrade to ADT 22
(7 answers)
Closed 9 years ago.
This morning I updated various SDK components from Eclipse. I think it was
- Android SDK or Platform tools
- Google APIs 17 update
- Android Support Library
- Google Play Services
Now, my apps won't deploy. They build ok (eventually, after an hour of reconfiguring and rebuilding) but now when I deploy to the device, I get the following:
VFY: unable to find class referenced in signature (Landroid/support/v4/app/Fragment;)
VFY: unable to find class referenced in signature (Landroid/support/v4/app/Fragment;)
VFY: unable to find class referenced in signature (Landroid/support/v4/app/Fragment;)
Unable to resolve superclass of Lcom/com/myapp/MainActivity; (81)
Link of class 'Lcom/com/myapp/MainActivity;' failed
VFY: replacing opcode 0x71 at 0x0006
VFY: unable to find class referenced in signature (Landroid/support/v4/app/Fragment;)
Unable to resolve superclass of Lcom/com/myapp/MainActivity; (81)
Link of class 'Lcom/com/myapp/MainActivity;' failed
Shutting down VM
threadid=1: thread exiting with uncaught exception (group=0x40015560)
FATAL EXCEPTION: main
java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{com.myapp/com.myapp.MainActivity}: java.lang.ClassNotFoundException: com.myapp.MainActivity in loader dalvik.system.PathClassLoader[/data/app/com.myapp.apk]
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1680)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784)
at android.app.ActivityThread.access$1500(ActivityThread.java:123)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:130)
at android.app.ActivityThread.main(ActivityThread.java:3835)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:864)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:622)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: com.myapp.MainActivity in loader dalvik.system.PathClassLoader[/data/app/myapp.apk]
at dalvik.system.PathClassLoader.findClass(PathClassLoader.java:240)
at java.lang.ClassLoader.loadClass(ClassLoader.java:551)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at android.app.Instrumentation.newActivity(Instrumentation.java:1021)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1672)
... 11 more
Bear in mind that this project, and others, have been happily running for months, so this isn't just some daft error like the activity missing from the manifest file.
I'm really wishing I hadn't bothered with the update now... any ideas welcome!
I faced this issue couple of days before.
Right click your project, Go to properties->Java Build path->Order and Export
Check Android Private Library->Click Ok
Clean the project and run it.it will work.
sdk\extras\android\support\v4 inside there is a jar file android-support-v4.jar add this to the external jars
I am trying to use the library DigestUtils in Android 2.3.1 using JDK 1.6, however I get the following error when executing the app:
Could not find method org.apache.commons.codec.binary.Hex.encodeHexString, referenced from method org.apache.commons.codec.digest.DigestUtils.shaHex
Here you have the stacktrace:
02-03 10:25:45.153: I/dalvikvm(1230): Could not find method org.apache.commons.codec.binary.Hex.encodeHexString, referenced from method org.apache.commons.codec.digest.DigestUtils.shaHex
02-03 10:25:45.153: W/dalvikvm(1230): VFY: unable to resolve static method 329: Lorg/apache/commons/codec/binary/Hex;.encodeHexString ([B)Ljava/lang/String;
02-03 10:25:45.153: D/dalvikvm(1230): VFY: replacing opcode 0x71 at 0x0004
02-03 10:25:45.153: D/dalvikvm(1230): VFY: dead code 0x0007-0008 in Lorg/apache/commons/codec/digest/DigestUtils;.shaHex ([B)Ljava/lang/String;
02-03 10:25:45.163: D/AndroidRuntime(1230): Shutting down VM
02-03 10:25:45.163: W/dalvikvm(1230): threadid=1: thread exiting with uncaught exception (group=0x40015560)
02-03 10:25:45.173: E/AndroidRuntime(1230): FATAL EXCEPTION: main
02-03 10:25:45.173: E/AndroidRuntime(1230): java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Hex.encodeHexString
02-03 10:25:45.173: E/AndroidRuntime(1230): at org.apache.commons.codec.digest.DigestUtils.md5Hex(DigestUtils.java:226)
02-03 10:25:45.173: E/AndroidRuntime(1230): at com.caumons.trainingdininghall.ConnectionProfileActivity.onCreate(ConnectionProfileActivity.java:20)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1586)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1638)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.app.ActivityThread.access$1500(ActivityThread.java:117)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:928)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.os.Handler.dispatchMessage(Handler.java:99)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.os.Looper.loop(Looper.java:123)
02-03 10:25:45.173: E/AndroidRuntime(1230): at android.app.ActivityThread.main(ActivityThread.java:3647)
02-03 10:25:45.173: E/AndroidRuntime(1230): at java.lang.reflect.Method.invokeNative(Native Method)
02-03 10:25:45.173: E/AndroidRuntime(1230): at java.lang.reflect.Method.invoke(Method.java:507)
02-03 10:25:45.173: E/AndroidRuntime(1230): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
02-03 10:25:45.173: E/AndroidRuntime(1230): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
02-03 10:25:45.173: E/AndroidRuntime(1230): at dalvik.system.NativeStart.main(Native Method)
The line of code which causes the exception is:
String hash = DigestUtils.shaHex("textToHash");
I have executed the same code in a Java class outside Android and it works! So, I do not know why when working with Android it does not work... I put the libraty inside a new libs/ folder in my app and updated the BuildPath to use it. If I try to use md5 instead of sha1 I get the same exception. Any help would be appreciated! Thank you.
UPDATE:
As this is a very active question, I've changed the accepted answer in favour of #DA25, as his solution is straightforward and the high number of upvotes prove that it works.
I ran into the same issue trying to use DigestUtils in my Android app. This was the best answer I could find by searching, but I was reluctant to rebuild the .jar file with the namespace changed. After spending some time on this issue, I found an easier way to solve the problem for my case. The problem statement for my code was
String s = DigestUtils.md5Hex(data);
Replace this statement with the following and it will work:
String s = new String(Hex.encodeHex(DigestUtils.md5(data)));
Similarly, for shaHex exampl, you can change it to
String hash = new String(Hex.encodeHex(DigestUtils.sha("textToHash")));
This works because even though Android does not have encodeHexString(), it does have encodeHex(). Hope this would help others who run into the same issue.
Since there's no clear answer for the root cause of this problem, I'd like to clarify what's happening here.
Why the NoSuchMethodError is thrown in the first place?
According to exception stack trace, the line that causes the fault is 226 in DigestUtils#md5hex method. Let's see what we have there (I'm assuming you have used version 1.4, since this is the only release where Hex#encodeHexString method is being invoked in line 226):
public static String md5Hex(String data) {
return Hex.encodeHexString(md5(data));
}
The exception says java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Hex.encodeHexString.
Let's understand why.
First of all, Android framework already includes the Commons Codec library (except the DigestUtils class). Yes, it is not exposed as part of the Android SDK and you cannot use it directly. But you still want to use it. So what you do? You add Commons Codec library as part of your application. The compiler doesn't complain - from his point of view everything was fine.
But what happens at runtime? Let's follow your exception stack trace:
First, you're calling DigestUtils#md5Hex from your Activity's onCreate method. As I wrote above, the framework doesn't include that class, so DigestUtils (from Commons Codec version 1.4) is loaded from your dex.
Next, md5hex method tries to invoke Hex#encodeHexString method. Hex class is part of the Commons Codec library that included in framework. The thing is that its version is 1.3 (ancient release from July 2004). Hex class exists in boot classpath, which means that the runtime will always favor it instead of the Hex class that packaged inside your dex. You can see warnings about it in your application logs when you start your app (with Dalvik runtime):
D/dalvikvm? DexOpt: 'Lorg/apache/commons/codec/binary/Hex;' has an earlier definition; blocking out
I/dalvikvm? DexOpt: not resolving ambiguous class 'Lorg/apache/commons/codec/binary/Hex;'
D/dalvikvm? DexOpt: not verifying/optimizing 'Lorg/apache/commons/codec/binary/Hex;': multiple definitions
I/dalvikvm? Could not find method org.apache.commons.codec.binary.Hex.encodeHexString, referenced from method org.apache.commons.codec.digest.DigestUtils.md5Hex
Hex#encodeHexString method was introduced in version 1.4 of Commons Codec library and therefore it doesn't exist in framework's Hex class. The runtime can't find this method and thus throws NoSuchMethodError exception.
Why the accepted answer's solution works?
String s = new String(Hex.encodeHex(DigestUtils.md5(data)));
First, DigestUtils#md5 method is called. As I already stated, DigestUtils class that will be used is the one that packaged in your dex. This method doesn't use any other Commons Codec classes, so no problem with it.
Next, Hex#encodeHex will be called. The Hex class that will be used is the framework's one (version 1.3). The encodeHex method (that takes a single parameter - byte array) exists in version 1.3 of Commons Codec library, and therefore this code will work fine.
What would I suggest?
My suggested solution is to rename the classes namespace/package. By doing so I'm explicitly specifying which code is going to execute, and prevent bizarre behavior that may occur because of versioning issues.
You can do it manually (as Caumons wrote in his answer), or automatically with jarjar tool.
See this issue summary and tips for using jarjar in my blogpost.
Finally I get the answer and it works well. As described in No such method error in Apache codec for another type of encrypt (Base64) I tried to reproduce the same issue and I get exactly the same error. So I was in the case of the question attached. As they say, it seems to be an internal name collision with the package name org.apache.commons.codec and as stated by #Don I changed it to com.apache.commons.codec and worked fine! How I did it?
I downloaded the source code and changed the 3 directories org to com. I also replaced all the occurrences of the package name in the files where they appear and also changed the references in the docs to com/apache/commons/codec/. (Do not try to remane them manually or you will spend the hole day). Then I compiled the library and generated the jar with Ant, which I called commons-codec-1.6-android.jar. I put the jar in the libs/ folder of my Android app and added it to the buildpath. Also, I attached the sources as the folder which contains all the files. So now I have the library ready to use with Android!
Hope that it helps someone else!
Thanks #DA25
This is working fine for me
I have add dependency
compile 'commons-codec:commons-codec:1.9'
ref: http://mvnrepository.com/artifact/commons-codec/commons-codec/1.9
my function
public String encode(String key, String data) {
try {
Mac sha256_HMAC = Mac.getInstance("HmacSHA256");
SecretKeySpec secret_key = new SecretKeySpec(key.getBytes("UTF-8"), "HmacSHA256");
sha256_HMAC.init(secret_key);
return new String(Hex.encodeHex(sha256_HMAC.doFinal(data.getBytes("UTF-8"))));
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
} catch (InvalidKeyException e) {
e.printStackTrace();
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
return null;
}
For me proguard removed the class during obfuscation .Add this to your Proguard rules.
-keep class org.apache.commons.** { *; }
Here's the method I was using of apache package.
Hex.encodeHex(digest)
Add method
public static String byteArrayToHexString(byte[] bytes) {
final char[] toDigits = "0123456789abcdef".toCharArray();
int l = bytes.length;
char[] out = new char[l << 1];
int i = 0; for (int j = 0; i < l; ++i) {
out[(j++)] = toDigits[((0xF0 & bytes[i]) >>> 4)];
out[(j++)] = toDigits[(0xF & bytes[i])];
}
return new String(out);
}
We used below code and it worked :
HmacUtils hmacUtils = new HmacUtils(HmacAlgorithms.HMAC_SHA_256, keyString);
String digest = new String( Hex.encodeHex(hmacUtils.hmac(msg)));
Another way to rename DigestUtils class will be with proguard.
If you are not using proguard you can enable it and add this one line which will obfuscate only DigestUtils class, and leave everything else intact.
-keep class !org.apache.commons.codec.digest.DigestUtils,com.** { *; }
and add this to your app build.gradle
buildTypes {
debug {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
Or OPTION 2
Use old version of the library in your code:
implementation("commons-codec:commons-codec:1.3"){
force = true
}
Need to use force = true if common-codec dependency come from third part library otherwise Gradle will resolve by default to higher version.
I followed the advice given on the internet regarding working with Application classes in android.
I also added a field "android:name=.Session" to my Application object in the manifest.
The application is called "Session".
What do you think is the error? This is happening even before the my App starts.
This is the error stack:
**java.lang.RuntimeException: Unable to instantiate application com.appfire.Session: java.lang.InstantiationException: com.appfire.Session**
at android.app.ActivityThread$PackageInfo.makeApplication(ActivityThread.java:523)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3996)
at android.app.ActivityThread.access$2900(ActivityThread.java:119)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1901)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4363)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
at dalvik.system.NativeStart.main(Native Method)
**Caused by: java.lang.InstantiationException: com.appfire.Session**
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1479)
at android.app.Instrumentation.newApplication(Instrumentation.java:957)
at android.app.Instrumentation.newApplication(Instrumentation.java:942)
at android.app.ActivityThread$PackageInfo.makeApplication(ActivityThread.java:518)
Make sure your Session class is public, is not static, and does not have a default constructor.
public class Session extends Application {}
In the Manifest application tag, make sure you include the fully-qualified class name of your custom Application object:
<application
android:name="com.mycompany.myapp.Session"
.... />
The Android docs do say the class name must be fully qualified:
http://developer.android.com/guide/topics/manifest/application-element.html#nm
(This is not the case for Activity class names that are included in the activity tag of the Manifest. Those can be relative, preceded with a '.').
My solution was to delete the whole project from Eclipse and load it again from SVN. Now it works
I'm attempting to integrate JTwitter into an Android application, and I have been completely successful up until the point where I decided to regression test on older Android versions. In Android 2.x my code works great, but in Android 1.5/1.6 Dalvik throws a VerifyError on the following line:
OAuthSignpostClient oauthClient
= new OAuthSignpostClient(KEY_TWITTER, SECRET_TWITTER, "oob");
and provides this logcat output and stack trace:
Could not find method javax.swing.JOptionPane.showInputDialog, referenced from method winterwell.jtwitter.OAuthSignpostClient.askUser
VFY: unable to resolve static method 1703: Ljavax/swing/JOptionPane;.showInputDialog (Ljava/lang/Object;)Ljava/lang/String;
VFY: rejecting opcode 0x71 at 0x0000
VFY: rejected Lwinterwell/jtwitter/OAuthSignpostClient;.askUser (Ljava/lang/String;)Ljava/lang/String;
Verifier rejected class Lwinterwell/jtwitter/OAuthSignpostClient;
Shutting down VM
threadid=3: thread exiting with uncaught exception (group=0x4001aa28)
Uncaught handler: thread main exiting due to uncaught exception
java.lang.VerifyError: winterwell.jtwitter.OAuthSignpostClient
at com.wirelessdesigns.android.AuthActivity.onCreate(AuthActivity.java:37)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2364)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2417)
at android.app.ActivityThread.access$2100(ActivityThread.java:116)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1794)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4203)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
at dalvik.system.NativeStart.main(Native Method)
I'm trying to figure out what may have changed in the underlying implementation between the Android versions that would affect this and what the workaround might be? A similar question was answered a while back, but the answer was in the form of a now-dead link to a forum post.
Any thoughts?
Before Android 2.0, the verifier would immediately reject classes when something wasn't right. In 2.0 and later, reporting of certain failures is deferred until the code is actually executed. Attempting to call a nonexistent or inaccessible method is one such case.
This is an example of why the verifier behavior was changed. Even though you're not calling the absent function, the whole class that's trying to call it is getting rejected.
Some workarounds can be found here, but it sounds like you've found one on your own.