A project I'm working on contains a lot of external dependencies on 3rd party libraries. While analyzing compiled apk I found out that a package within the app that is supposed to be obfuscated remains clean. When I dived deeper I figured out that merged ProGuard configuration contains a rule breaking obfuscation logic.
None of the project's ProGuard configurations contain this rule. So I assume that it was gotten from one of the dependencies and merged to final configuration.
I look through this question but it seems that the answer is no longer valid for Android Plugin for Gradle 3.0.1 that I'm using because build/intermediates/exploded-aar folder no longer contains any ProGuard configurations.
So I'm wondering:
Is there a way to find what library causes the problem?
Is it still possible to disable a rule from consumer proguard file?
Related
I have an android library hosted on jitpack, but due to its dependencies requirements it is not built to and AAR file. It just a basic project that you can pull the methods from.
I want to hide the names for the classes, methods, and variables within the project itself without compilation. I understand that I could minify it in the gradle but that would only work once the project is built into and apk or bundle.
Is there a way to post process the code to have the same effect?
I have found the answer I was looking for. Jitpack pre-builds the project after you commit changes. In this compilation process it does take the minification in the gradle and proguard rules into account. Even though I don't distribute an AAR or Jar file, the code still gets hidden in the same way.
In conclusion, Just set up the minification and proguard rules as your normally would and Jitpack will handle the rest.
As instant app features are compiled into seperate APKs the proguard step becomes a little bit more tricky.
For example you can no longer just have one proguard file defined in the runnable module and let it obsfuscate all features. Every feature must have its own proguard.
I would like to know how you can easily define one proguard file and use some gradle magic to apply them to all feature modules?
Having multiple proguard files in each module is just unmaintainable.
I am using a third party .aar project and they have enabled the proguard in the aar project. And in my Application Project i am enabling Proguard as well and its giving me errors.
So, do i need their(.aar project) proguard rules to be included in my proguard config files or is there any other possibility?
I have read in blogs and posts that the best approach is to include the .aar project without proguard and then run the proguard on aar and application project as a whole.
If i run proguard on Application will it affect the imported library's(already proguarded) code ?
So, do i need their(.aar project) proguard rules to be included in my proguard config files or is there any other possibility?
Quoting the documentation:
You can enable code shrinking on your library by adding a ProGuard configuration file to your library that includes its ProGuard directives. The build tools embed this file within the generated AAR file for the library module. When you add the library to an app module, the library's ProGuard file gets appended to the ProGuard configuration file (proguard.txt) of the app module.
So, if the library module has consumerProguardFiles 'lib-proguard-rules.txt' in its defaultConfig (see the docs), in principle, those rules will get applied automatically.
I have read in blogs and posts that the best approach is to include the .aar project without proguard and then run the proguard on aar and application project as a whole.
AFAIK, that's the typical plan. So, the AAR is left alone, with ProGuard applied on the app.
If i run proguard on Application will it affect the imported library's(already proguarded) code ?
AFAIK, the library's code should not be run through ProGuard.
I received some legacy code of app (not developed by me, but by some other team, with no documentation), which has almost 20+ dependencies, in build.gradle.
Now, I wanted to clean up unused Libraries/dependencies, by removing them from build.gradle
I searched on Google and came across this project for resource shrinking. But it seems to be used for removal of resources that are unused, at build time, in the packaged app and this also removes resources from libraries you are depending on if they are not actually needed by your application.
Also, I use ProGuard, for obfuscation and shrinking in conjunction with shrinkResources true in build.gradle
My intention is to remove unused Libraries/dependencies from build.gradle itself, without breaking app functionality.
Is there a way or tool which shows which library is safe to remove without breaking the app functionality?
By 20+ dependencies you don't need any tooling and can do a manual check.
I would proceed like this:
Comment out all dependencies and check what fails (see below)
Uncomment the dependency that causes the failure
Repeat
This way you might also notice dependencies that are seldom used or can be replaced with standard libraries or other libraries that you use in the project.
Here are the things that will indicate you that a dependency is required (in the order of slowing down the feedback loop):
compilation errors
unit test errors
integration / system / end-to-end / device test errors (whatever you use and call them)
application functionality at runtime
application performance at runtime
Runtime dependencies can be especially tricky. For example, your code might not depend on a library, but this library provides a runtime implementation for some other library you depend on. Removing such a dependency will only be visible at runtime as missing functionality or performance issues.
Instead of commenting out all dependencies I would go the other way around - comment out one dependency at a time and see what breaks. This way you would also get a grasp of use-cases of all dependencies because the IDE will point you to the place where code broke. If nothing breaks after commenting out a dependency you'll know that it's not used. Another thing you could potentially do is analyze an unobfuscated release .apk where all unused dependencies will be missing but package structure will be preserved.
If you mean that finding unused library or import, you can easily see with "Ctrl + alt + shift + i" and type "unused import"
You can see now all unused imports.
Finding libraries and resources used in an Android app comes up in several contexts.
For the apps published in Google Play, AppBrain maintains reverse lookups, from the library to the more popular apps that use it. For example, apps using a newish 2D game library Godot.
Apktool will decode the APK directly.
The author instead wants to find (unused) resources, starting from the source code and the build process. Gabriele Mariotti above links to the question, whose accepted answer provides detailed information on use of minifyEnabled and shrinkResources in Gradle configuration.
Review Shrinking Android app and ProGuard vs R8.
I'm trying to setup proguard for my Android project. My application project has very little code in it, but references a library project which has the vast majority of the code and any other external jars. That being said, I'm not sure how to setup proguard to take this into account. Right now my proguard config file is just the Android example from the ProGuard site. I've been searching around, but haven't found a lot or any documentation on using proguard with library projects, just jars. I'm new to proguard, so any push in the right direction would be great. Thanks.
It makes sense to me to specify proguard settings for a library (like which library files shouldn't be obfuscated) in the library project. I've found that I also need to include proguard configurations from my library modules in my application. To do this, I added the following to the defaultConfig section in my library's build.gradle
apply plugin: 'com.android.library'
android {
defaultConfig {
consumerProguardFiles 'proguard-rules.pro'
}
}
and then configured the proguard-rules.pro file in my library module to keep the names of important serialized classes.
See also consumerProguardFiles gradle reference
Edit
As #BornToCode points out, a different answer (originally posted here) better explains how library projects are handled by Proguard. Additionally, this referenced question has more interest and more overall reputation than that linked in my original response. The quote:
Library projects by themselves don't run ProGuard, so they don't use
any configuration.
Application projects obfuscate the entire code base, including any
referenced libraries, so they need proper configuration for the
application code and for the library code.
Old Answer (not wrong, just probably not the best approach)
The library projects is more of a convenient way of linking a project to its jar in Eclipse. When you build the project, the only component of the library project that is visible to your compiler is the jar file.
If you want to obfuscate that jar, check out this post:
How to obfuscate an Android library (.jar file) using Proguard in Eclipse