After updating dependencies to latest versions we ran into a Runtime crash in release builds because of missing interface implementation
java.lang.IncompatibleClassChangeError:
Class 'com.mypackage.app.data.cache.query.user.QueryUserFollowersCountById'
does not implement interface 'com.mypackage.app.data.cache.query.Query'
in call to 'java.lang.String[] com.mypackage.app.data.cache.query.Query.c()'
(declaration of 'com.mypackage.app.data.cache.database.util.Db'
appears in /data/app/com.mypackage.app-2/base.apk:classes2.dex)
Two days of debugging later, we think the issue is related to Proguard stripping out the 'implements Query' during its shrinking phase. The interface itself is kept as it is used in hundreds of other classes, it is only missing in 3 classes. We also found some RxJava Func0 and Action0 interfaces stripped out in the same way, again in a very few places. Thus the app runs perfectly for 95% of the screens, but obviously crashes where the interface implementation is missing.
We are using Gradle build tools version 3.1.3 but also tried with 3.3.0-alpha03, also tried disabling D8, thus it shouldn't be a build tools issue (also Proguard version 5.3.3 and 6.0.3 behave in the same way in this case)
The issue appears when bumping Dagger2 from version 2.11 to 2.12 or later, thus it might be related to the amount of fields/methods/classes etc in the app
The issue remains even when using -dontoptimize, we have gone through Proguard documentation and enabled/disabled almost all relevant flags
The issue is gone by setting minifyEnabled to false or by using -dontshrink flag for Proguard
The app uses Multidex, both builds with Dagger 2.11 and Dagger 2.12 end up with 3 classes.dex files. The problematic interface and the implementations are in the same .dex file in both cases.
For example, there are 5 files in the same package that implement Query, 3 of them have the interface in the resulting bytecode, but 2 files do not. So it should not be related to where the files are placed.
Bytecode when built using Dagger 2.11 or -dontshrink
.class public Lcom/mypackage/app/data/cache/query/user/QueryUserFollowersCountById;
.super Ljava/lang/Object;
.source "SourceFile"
# interfaces
.implements Lcom/mypackage/app/data/cache/query/Query;
# annotations
.annotation system Ldalvik/annotation/Signature;
value = {
"Ljava/lang/Object;",
"Lcom/mypackage/app/data/cache/query/Query<",
"Ljava/lang/Integer;",
">;"
}
.end annotation
......
Bytecode when built using Dagger 2.12 or later
.class public Lcom/mypackage/app/data/cache/query/user/QueryUserFollowersCountById;
.super Ljava/lang/Object;
.source "SourceFile"
# annotations
.annotation system Ldalvik/annotation/Signature;
value = {
"Ljava/lang/Object;"
}
.end annotation
......
We obviously want to use the latest version of Dagger2 and also keep shrinking and optimising our code with Proguard.
How to make sure that Proguard will not strip out implements interface statements?
Or how to add logging/debugging to Proguard shrinking step?
If proguard is removing implements part, it is more likely that during optimize phase proguard is considering it as dead code.
You have already mentioned
The issue is gone by setting minifyEnabled to false or by using -dontshrink flag for Proguard
This validates my assumption that implements part could be a dead code
please go through this thread, this explains how to get the list of dead code. In other words the answer to your query about adding logs for debugging using -printusage [filename]
Related
play-services-base-16.0.1.aar (mvnrepository) has proguard.txt with following content:
# b/35135904 Ensure that proguard will not strip the mResultGuardian.
-keepclassmembers class com.google.android.gms.common.api.internal.BasePendingResult {
com.google.android.gms.common.api.internal.BasePendingResult$ReleasableResultGuardian mResultGuardian;
}
But you can see in classes.jar that type of mResultGuardian is already obfuscated to BasePendingResult.zaa. I guess that is why I get
Note: the configuration refers to the unknown class 'com.google.android.gms.common.api.internal.BasePendingResult$ReleasableResultGuardian'
How that's supposed to work? I'm new to Proguard and only have very basic understanding of what is going on so please make your answers simple :)
Project details:
gradlew version: 5.4
build plugin: com.android.tools.build:gradle:3.2.0
Unfortunatelly I can't update gradle build plugin to 3.3.* or 3.4.* right now because some of the scripts are incompatible and would require significant refactoring.
app/proguard.txt (from recommendations I've seen):
-keep class com.google.android.gms.analytics.** { *; }
-keep class com.google.android.gms.gcm.** { *; }
-dontwarn com.google.android.gms.**
But that doesn't help.
UPD
I end up upgrading to com.android.tools.build:gradle:3.4.1 (some api changes had to be adapted) which fixed the issue but I still don't get how that's supposed to work with rules like that.
“If the proguard set up in your project it does some jobs for us in the built process : Minification, obfuscation, repackaging and optimisation. Enabling it is straightforward if you’re using gradle, just set minifyEnabled to true for your release buildType in build.gradle and pass the default set of android optimisation rules.
This will help to shrink, speed up and protect your app. However it mainly works by removing code that is never called and renaming what’s left. This is all well and good until you encounter reflection.
Reflection lets you write code that can look up and execute other code based on its name (among other things)”
“You can also use ProGuard if you or any of the libraries in your app use reflection, here you specify rules as to which classes, methods and other parts of your app ProGuard should leave alone. You can list all these rules in a file and pass them to ProGuard via the proguardFiles method back in your build.gradle. The general convention is for this file to be called proguard-rules.pro”
These doc1, doc2 provide you more information on how to work with rules
I have an error after switching from Dagger 2.5 to 2.12 when using proguard on my release build.
DaggerGraph.java:662: error: cannot find symbol
ReportingService_MembersInjector.injectA(instance, provideDataLayerProvider.get());
I have an Android Library that is compiled and obfuscated and an Android App that includes that Library.
The graph is generated using components from both modules.
Any hints?
Thanks
PS. With Dagger 2.5 it is working without problems.
PPS. The debug build without proguard is also working good with Dagger 2.12
Speculative answer: This may have less to do with Proguard and more to do with some of the optimizations made specifically in Dagger 2.12.
Because you're running Dagger on the library you're created, and then consuming that library from a different Dagger app, Dagger gets two chances to run: First for the library, which creates your ReportingService_MembersInjector, and then a second which presumably consumes that same ReportingService. Between those steps, Proguard can effectively do whatever it wants to classes that you haven't marked with -keep and related switches. My hunch is that Dagger needed to keep your injectA method as of 2.5, but the 2.12 optimizations no longer need you to keep that method, so Proguard eliminates it.
In your Android app that consumes the library, Dagger detects a class named ReportingService_MembersInjector, so it doesn't create another copy, and incorrectly assuming it contains all of the methods that it would generate.
I think the root of the problem is that your library exposes an #Inject-annotated class that your outer (app) Dagger graph is evidently consuming directly, and then you are also keeping the Factory and MembersInjector classes that Dagger provides adjacent to it. Even if you were to properly -keep your generated MembersInjector, Provider, and Factory classes, you might experience version differences between the inner obfuscated library and the outer copy of Dagger that would make for different sorts of trouble. Instead, provide a factory or other official way of creating your library class from the outside of the library, so there's no reason that the two Dagger runs can interfere with one another.
I have an Android project with a proguard-rules.pro file for the app module that contains only the following:
# ProGuard rules
-dontobfuscate
-dontwarn android.arch.util.paging.CountedDataSource
-dontwarn android.arch.persistence.room.paging.LimitOffsetDataSource
I am not keeping anything myself. All -keep rules are coming from something else, whether that is the rules provided by getDefaultProguardFile('proguard-android-optimize.txt') or from rules packaged in libraries.
However, stuff is being kept that I am not using. If I use the Android Studio APK Analyzer on my release build, while lots of things are removed by ProGuard, lots of other things are kept that I am not referencing.
For example: through transitive dependencies, I have the Support Library module that contains ViewPager in the app's dependencies tree. However, I am not (presently) using ViewPager in this app. Despite this, something is causing it to be kept, as the APK Analyzer shows 107 defined methods for android.support.v4.view.ViewPager, including its constructor.
I could use various ProGuard options to track down why this is being kept. However, it is not coming from my rules. There is no -keep of my own that needs fixing — the -keep is coming from somebody else, presumably a Google engineer.
So, how do I get rid of ViewPager? Is there a way that I can override the -keep rule that is causing it to be kept (e.g., using allowshrinking)? If so, how does ProGuard, as invoked by Android Studio, determine whose -keep rule wins?
The ViewPager class isn't kept in a small app that I just checked, so it must be other code or other rules in your project indeed.
You can start with letting ProGuard print out the chain that triggers ViewPager to be kept:
-whyareyoukeeping class android.support.v4.view.ViewPager
You may need to repeat this a number of times for various classes and methods to get to the root cause. ProGuard doesn't print out which rule exactly is responsible -- admittedly, this would be a useful feature.
You can then look for the proguard.txt file in build/intermediates/exploded-aar that contains a matching rule.
As for a solution at that point:
It is not possible to override -keep rules; they only accumulate.
As far as I know, the Android Gradle plugin also doesn't support disabling overly conservative proguard.txt files in libraries, so you'd need to create a custom .aar file with the updated rule, or send a suggestion to the developers of the library.
I have enabled minifyEnabled in my gradle file for using the feature of ProGuard to obfuscates code as a result it throwing some error.
Note: there were 1 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
Warning: there were 309 unresolved references to classes or interfaces.
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
and much more.
I have gone through the ProGuard documentation.i guess this is what happening wrong.am using third party libraries and jars.and it confuses as i have more number of libraries and jars.how can i decide which one should keep in my proguard-rules.pro and which one doesn't ? And what else need to do for using ProGuard successfully and efficiently ?
ProGuard analyzes all the code in your application (that includes libraries) and generates warnings if it sees unresolved references (or other problems, but unresolved references is the important thing here). It is very common for libraries to refer to system or library code that doesn't exist in your project.
For example: Picasso optionally integrates with OkHttp, and has code referring to that library. But if you haven't included OkHttp ProGuard will warn about unresolved references.
A successful build must not have any warnings from ProGuard. ProGuard also checks for reflection, if there are unresolved references found in reflection, ProGuard will generate notes instead of warnings. Both warnings and notes may point to issues with the classpath. You could check the code yourself to see if there's an actual problem, or trust the libraries that their code works on Android (and on your target platform version).
Kevin Schultz opened up a public collection of ProGuard configuration files. His blogpost should help you get started with your configuration file.
http://www.kevinrschultz.com/blog/2014/02/15/proguard-with-gradle/
Do double check the configurations that you copy. They can be a little aggressive sometimes. If possible you want to avoid -dontwarn/dontnote {entire-package} and instead narrow down on the actual problems.
You need to add proguard rules specific to the libraries you use. A compilation of such rules is available at https://github.com/StarWar/android-proguard-snippets/tree/master/libraries
You can also try adding dontwarn directive for packages causing issues. An example of this would be -dontwarn org.codehaus.jackson.**
I recently migrated a project from Eclipse/Ant to Android Studio/Gradle. I am able to successfully build a signed release version of the project with proguard enabled. However, while testing the release version, I'm getting crashes from certain library projects and jars (which work fine when building a debug version).
For example, when attempting to upload a file to Dropbox (a jar dependency), I get the following error:
java.lang.IncompatibleClassChangeError: interface not implemented
at com.dropbox.client2.session.AbstractSession.sign(SourceFile:238)
at com.dropbox.client2.DropboxAPI.putFileRequest(SourceFile:2199)
at com.dropbox.client2.DropboxAPI.putFileOverwriteRequest(SourceFile:1571)
at com.dropbox.client2.DropboxAPI.putFileOverwrite(SourceFile:1537)
Also, when attempting to sign into Box (a library project dependency), I get the following error:
java.lang.NoSuchMethodError: org.apache.http.conn.params.ConnManagerParams.setMaxTotalConnections
at com.box.restclientv2.BoxBasicRestClient.()
at com.box.boxjavalibv2.BoxRESTClient.()
at com.box.boxjavalibv2.BoxClient.createRestClient()
at com.box.boxjavalibv2.BoxClient.()
at com.box.boxandroidlibv2.BoxAndroidClient.(SourceFile:49)
at com.box.boxandroidlibv2.activities.OAuthActivity.startOAuth(SourceFile:71)
at com.box.boxandroidlibv2.activities.OAuthActivity.onCreate(SourceFile:52)
I have other jars and library projects that work just fine...
Again, there are no issues with either of these when building a gradle debug build (no proguard). I was also able to create a release build with proguard enabled using ant without any issues (able to sign into both Dropbox and Box).
Any ideas?
You appear to be including a version of the org.apache.http library. In principle, this library is already part of the Android runtime android.jar, so you shouldn't add it to your project. ProGuard is probably printing warnings about these duplicate classes.
In practice, it may be a newer version of the library, and some of your code may be using additional classes from this version. You then probably should leave the names of the classes, fields, and methods untouched, to avoid introducing (additional) conflicts:
-keep class org.apache.http.** { *; }
A build process may filter out the classes, or it may be adding the above line, but I don't think the default Android builds currently do either.
You need to -keep Proguard from removing or renaming all the class and method names that it can't determine are referenced from code that it doesn't processes, that are referenced via reflection (e.g. XML references), etc.
Keeping all apache classes may keep more than necessary (which is OK) but it may not be enough to fix all the Proguard issues.
It's good to ask why it worked from your ant build without this -keep. Maybe the ant build didn't actually call Proguard (ant is tricky), maybe it used a different Proguard data file, or maybe the relevant libraries changed in the meantime. You can debug that by listing hypotheses and testing them. E.g. if you put a malformed command in the Proguard data file then run the ant build, you can tell whether it actually runs Proguard or not.