Develop Reference

Evernote Android SDK library throws java.lang.VerifyError under R8

Facing notorious java.lang.VerifyError. Initially problem showed up in Fabric. Was able to reproduce (with identical stacktrace) once set minifyEnabled true for debug build.
Caused by java.lang.VerifyError: Verifier rejected class com.evernote.client.conn.mobile.TEvernoteHttpClient: void com.evernote.client.conn.mobile.TEvernoteHttpClient.cancel() failed to verify: void com.evernote.client.conn.mobile.TEvernoteHttpClient.cancel(): [0x6] 'this' argument 'Reference: org.apache.http.client.methods.HttpRequestBase' not instance of 'Reference: org.apache.http.client.methods.AbstractExecutionAwareRequest'
void com.evernote.client.conn.mobile.TEvernoteHttpClient.flush() failed to verify: void com.evernote.client.conn.mobile.TEvernoteHttpClient.flush(): [0x7F] 'this' argument 'Reference: org.apache.http.impl.client.DefaultHttpClient' not instance of 'Reference: org.apache.http.impl.client.CloseableHttpClient' (declaration of 'com.evernote.client.conn.mobile.TEvernoteHttpClient' appears in base.apk)
at com.evernote.client.android.ClientFactory.createNoteStoreClient + 85(ClientFactory.java:85)
I see that typically java.lang.VerifyError issues are recognized as related to difference between code to compile and run against.
This is not the case since code runs just fine when minification is disabled.
The way I see this can be helped is making another rule, but I am failing to understand which classes need to be kept from this error details.
We are already doing
-keep class com.evernote.** { *; }
-keep interface com.evernote.** { *; }
-keep class org.apache.http.** { *; }
-keep interface org.apache.http.** { *; }
... and those classes don't get modified in any way. I've checked it using -printusage ./full-r8-config.txt instruction and checking the output. Classes mentioned in error details do not show up there.
UPDATE 1 day later:
Really strange thing going on here.
So far I have a verified backup plan: switching back to proguard fixes issue.
But in case if I want to stay with R8, here comes:
using -dontshrink, -dontoptimize and -dontobfuscate (all three at once) does no impact;
forcing specific apache.http version dependency does no impact;
I've checked mapping: neither Evernore SDK, nor Apache http classes don't get obfuscated;
issue pertains when app executed on api22 device (emulator, actually);
I was able to debug code once I had -dontobfuscate set. All goes well until Evernote's ClientFactory#createUserStoreClient decides to instantiate TEvernoteHttpClient - the moment program execution touches latter class's constructor - exception thrown.
It looks like it is all good to go, but this verifier fails.
Later update:
Issue filed as a bug for R8: https://issuetracker.google.com/issues/139268389. Please feel free to star it if facing similar situation (all code is in place but VerifyError is thrown)

Try to write below proguard rules.
-dontwarn com.evernote.client.conn.mobile.TAndroidTransport
-dontwarn com.evernote.client.conn.mobile.DiskBackedByteStore
-dontwarn com.evernote.client.conn.mobile.ByteStore
-dontwarn org.apache.commons.codec.binary.Base64

appcompat-v7 v21.0.0 causing crash on Samsung devices with Android v4.2.2

We just changed our application to use the appcompat-v7 support library in order to take advantage of the support actionbar and support Material themes. Using v21.0.0 of appcompat-v7 (andv21.0.0 of support-v4), we are now seeing crashes in Google Play and Crashlytics only from Samsung devicesrunningAndroid v4.2.2. Here is the stack trace from Google Play and the app appears to crash as soon as theactionbar` is shown and/or invalidated.
java.lang.NoClassDefFoundError: android.support.v7.internal.view.menu.MenuBuilder
at android.support.v7.app.ActionBarActivityDelegateBase.initializePanelMenu(ActionBarActivityDelegateBase.java:991)
at android.support.v7.app.ActionBarActivityDelegateBase.preparePanel(ActionBarActivityDelegateBase.java:1041)
at android.support.v7.app.ActionBarActivityDelegateBase.doInvalidatePanelMenu(ActionBarActivityDelegateBase.java:1259)
at android.support.v7.app.ActionBarActivityDelegateBase.access$100(ActionBarActivityDelegateBase.java:80)
at android.support.v7.app.ActionBarActivityDelegateBase$1.run(ActionBarActivityDelegateBase.java:116)
at android.os.Handler.handleCallback(Handler.java:725)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:176)
at android.app.ActivityThread.main(ActivityThread.java:5299)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
at dalvik.system.NativeStart.main(Native Method)
Other devices and emulators running v4.2.2 do no exhibit this behavior. It's my understanding that many Google apps are already using this new version of appcompat to display the action bar. If these apps are not reporting crashes on these devices, it would be helpful to know how this is being avoided/fixed.
I reported this as a bug to Google but it got closed with the reason that it is a development issue. Although I do agree this may be the case, I'm wondering if/how anyone is currently able to use appcompat-v7 v21.0.0 and not get crashes on Samsung 4.2.2 devices.
Update: It looks like Google is at least considering possible workarounds for this. See this for details.

I found the proper solution here: https://stackoverflow.com/a/26641388/1266123
By using
-keep class !android.support.v7.internal.view.menu.**,android.support.v7.** {*;}
instead of
-keep class android.support.v7.** {*;}

As #150 from https://code.google.com/p/android/issues/detail?id=78377 said
Because careful with -keep class
!android.support.v7.internal.view.menu.**. There are a number of
classes in there which are referenced from the appcompat's resources.
The better solution is add the following lines instead:
-keep class !android.support.v7.internal.view.menu.MenuBuilder, !android.support.v7.internal.view.menu.SubMenuBuilder, android.support.v7.** { *; }
-keep interface android.support.v7.** { *; }

Since Appcompat 23.1.1 the .internal package in the AppCompat jar was removed.
Updated fix using proguard:
#FOR APPCOMPAT 23.1.1:
-keep class !android.support.v7.view.menu.*MenuBuilder*, android.support.v7.** { *; }
-keep interface android.support.v7.* { *; }

For all having this problem, only workaround so far seems to be using proguard. Checkout discussion at https://code.google.com/p/android/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&groupby=&sort=&id=78377

If anyone interested in using a solution without progaurd .
Read the link i have tried this in one of my apps which gave the exception on setSupportActionBar(toolbar) in onCreate().
Its pretty simple just add try catch block around the call
try {
setSupportActionBar(toolbar);
} catch (Throwable t) {
// WTF SAMSUNG!
}

I encountered the same issue on Tecno P9, but after using build tools 24 and for my support library I used 24.2.0, it was fixed.

Change the Compile Sdk Version of your project to "API 18:(JellyBean)"
The default is set to "Lollipop"
So far it solved my problem on Qmobile i9
STEPS
Right Click on your project and select Open Module Settings (or press F4)
In the properties tab Compiled Sdk Version

Replace AppCompatActivity
With Activity
This helped me.

Replace
public class class_name extends AppCompatActivity
{
.........
}
With
public class class_name extends Activity
{
.........
}
This helped me.

New Admob, Proguard, and Android 2.3

I'm integrating the new AdMob into my apps. The documentation states API 9 or above is required. Now here's the problem:
In debug mode, AdMob works fine on any supported devices. When I apply Proguard, devices running API-9 stop showing the ads, whereas more recent APIs still show the ads correctly. On API-9, the following shows up in Logcat:
11-08 00:32:03.523: W/Ads(24719): Could not get info for ad overlay.
Given that the problem only appears after Proguard, I assume this is due to a support class that is getting obfuscated. Unfortunately, AdMob's integration guide includes no instructions for Proguard, and my searching efforts have only yielded some suggestions like this which haven't fixed the issue. Currently, my Proguard config is as follows:
-keep class com.google.ads.**
-dontwarn com.google.ads.**
-keep class com.google.android.gms.ads.**
-dontwarn com.google.android.gms.ads.**
-keep public class com.google.gson.**
Anything else I need to add to it to fix the problem?

I am not to sure but try this:
-keep public class com.google.gson.**

How to set up ProGuard for Amazon IAP?

I'm trying to set up a basic ProGuard with Amazon IAP integrated. However when I'm trying to export my APK, I got the following errors:
[2012-06-17 10:59:44 - sc] Proguard returned with error code 1. See console
[2012-06-17 10:59:44 - sc] Unexpected error while performing partial evaluation:
[2012-06-17 10:59:44 - sc] Class = [com/amazon/inapp/purchasing/KiwiResponseHandler$PurchaseResponseHandlerRunnable]
[2012-06-17 10:59:44 - sc] Method = [run()V]
[2012-06-17 10:59:44 - sc] Exception = [java.lang.IllegalArgumentException] (Can't find common super class of [java/lang/String] (with 4 known super classes) and [com/amazon/inapp/purchasing/KiwiPurchaseResponseCommandTask] (with 1 known super classes))
[2012-06-17 10:59:44 - sc] java.lang.IllegalArgumentException: Can't find common super class of [java/lang/String] (with 4 known super classes) and [com/amazon/inapp/purchasing/KiwiPurchaseResponseCommandTask] (with 1 known super classes)
[2012-06-17 10:59:44 - sc] at proguard.evaluation.value.ReferenceValue.generalize(ReferenceValue.java:344)
[2012-06-17 10:59:44 - sc] at proguard.evaluation.value.IdentifiedReferenceValue.generalize(IdentifiedReferenceValue.java:65)
[2012-06-17 10:59:44 - sc] at proguard.evaluation.value.ReferenceValue.generalize(ReferenceValue.java:481)
...
I have the default ProGuard configuration file, and I have already added the:
-dontwarn com.amazon.**
-keep class com.amazon.** {*;}
-keepattributes *Annotation*
lines to it. What went wrong?

There is some fishy stuff with the recommended config of Amazon.
1) -dontwarn is hiding a deeper underlying issue, where some Amazon specific libraries are not present, but referenced so that proguard will try some wired optimization which likely causes the above mentioned stacktrace.
2) -dontoptimize is disabling all optimizations, which is defenitivly wrong, because it is most probably just one specific optimization which is causing this issue, and proguards optimizations are removing alot of dead and unused code from your app and its libraries, so it shrinks the total dex size.
I guess fixing 1) is the real solution. This could be eventually achieved by extracting Amazons system libs from a device and make them present (as a provided lib) while building
the app.
For 2) you can try:
-dontwarn com.amazon.**
-keep class com.amazon.** {
*;
}
-optimizations !code/allocation/variable
which solved the issue for me.

Per Amazon's SDK Docs, here are the lines you should include:
Preventing Obfuscation of In-App Purchasing API
When incorporating the In-App Purchasing API into your library, you will need to specify classes to 'keep' and not obfuscate. Add the following lines anywhere in your proguard.cfg file.
-dontwarn com.amazon.**
-keep class com.amazon.** {*;}
-keepattributes *Annotation*
In addition, you will also need to skip Proguard's optimization step.
-dontoptimize
Note: Make sure to remove any other flags dealing with optimization, or any flag that may conflict with the above settings.

In addition, you will also need to lower the number of optimization passes to 1, or skip proguard's optimization step.
-optimizationpasses 1
or
-dontoptimize

Proguard and Netty on Android

Basically I am trying the same as this guy: How can I tell proguard to assume a package is not used? but am not able to add any comments.
I keep getting warnings like this:
Warning: org.jboss.netty.logging.Slf4JLogger: can't find referenced class org.slf4j.Logger
Basically, org.jboss.netty.logging.Slf4JLogger is referencing third party library class org.slf4j.Logger which is not part of my project. org.jboss.netty.logging.Slf4JLogger is not used either.
So I try to tell proguard not to load/use org.jboss.netty.logging.Slf4JLogger as proposed by Eric Lafortune but constantly fail in doing so.
I added -injars libs/netty-3.3.1.Final.jar(!**Slf4JLogger) or -injars libs/netty-3.3.1.Final.jar(!**Slf4JLogger.class) but this does not seem to do anything. Even
-injars libs/netty-3.3.1.Final.jar("!whatever is in here") yields the same results so I assume this option does not do anything...
How can I tell Proguard to not consider several specific classes in the netty.jar?

Using the latest ADT (18.0) which fixes some problems with ProGuard integration (as compared to ADT 16.00), I was able to successfully run my Netty based app with the following additional ProGuard Settings:
# Get rid of warnings about unreachable but unused classes referred to by Netty
-dontwarn org.jboss.netty.**
# Needed by commons logging
-keep class org.apache.commons.logging.* {*;}
#Some Factory that seemed to be pruned
-keep class java.util.concurrent.atomic.AtomicReferenceFieldUpdater {*;}
-keep class java.util.concurrent.atomic.AtomicReferenceFieldUpdaterImpl{*;}
#Some important internal fields that where removed
-keep class org.jboss.netty.channel.DefaultChannelPipeline{volatile <fields>;}
#A Factory which has a static factory implementation selector which is pruned
-keep class org.jboss.netty.util.internal.QueueFactory{static <fields>;}
#Some fields whose names need to be maintained because they are accessed using inflection
-keepclassmembernames class org.jboss.netty.util.internal.**{*;}
My conclusions about why a specific line is needed may not be 100% precise and this is definitly not the must tuned solutions but at least it works. Feel free to edit if you think you can improve this.