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.**
Related
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
I'm getting the "No Class Def Found Exception" for the ToolBar in some kitkat devices like Samsung, ALTP etc. As per the below link(bug reported to google)
https://code.google.com/p/android/issues/detail?id=78377 #138 - asking the app to use old library classes, if the latest library is not supported is the only solution. I added these lines in my proguard-rules.pro:to fix this issue.
# Allow obfuscation of android.support.v7.internal.view.menu.**
# to avoid problem on Samsung 4.2.2 devices with appcompat v21
# see https://code.google.com/p/android/issues/detail?id=78377
-keep class !android.support.v7.internal.view.menu.**,android.support.** {*;}
`
I have fee in the xml format and proguard was not able to identify these classes,so added the below line too:
-keepclassmembers class * { *;}`
these are the only 2 changes i added extra. But after enabling proguard, my app performance is drastically reduced. It's taking lot of time to load pages and videos. This was not the case earlier. What might be the reason for this and how can I fix this issue. Is there any alternative for solving "NoClassDefFound Error".
Thanks in Advance..
Use this to solve your problem,
-keep class !android.support.v7.internal.view.menu.**,** {*;}
I have already answered for this issue,
NoClassDefFoundError: android.support.v7.internal.view.menu.MenuBuilder
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.
I am using crashlytics in my app. It caught a crash in the app, but not telling the line of code where crash occured. It is showing the verify error, but not telling where it is. This link is a screenshot to the report. It is showing ??? about the crash, see this link. How to study this crash now? ._.
Preserve annotations, line numbers, and source file names
-keepattributes *Annotation*,SourceFile,LineNumberTable
If you are using custom exceptions, add this line so that custom exception types are skipped during obfuscation:
-keep public class * extends java.lang.Exception
-printmapping mapping.txt
To skip running ProGuard on Crashlytics, add the following.
This will help speed up builds so that we can ship and test even faster.
-keep class com.crashlytics.** { *; }
-dontwarn com.crashlytics.**
More Info: Follow this link to Configure Crashlytics with Proguard.
https://docs.fabric.io/android/crashlytics/dex-and-proguard.html
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.