I have created a Wear OS module in our existing Android mobile application. Both application modules remain in the project like following:
Project/app
Project/wear/wear_presentation
Project/otherLibModule/other_lib_module_presentation
and we have a common.gradle that is used by app and wear_presentation:
buildTypes {
release {
minifyEnabled true
debuggable false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
debug {
debuggable true
minifyEnabled false
}
}
Before Wear OS module, we had a single proguard file inside app module that handles all minifying work, but now we have 2 application modules that have separate proguard files. That forces me to copy/paste all content from app proguard file into wear_presentation proguard file and this approach seems amateurish.
I want to use a single common proguard file that is used by both app and wear_presentation modules.
Is it possible?
Importing from Libraries is supported already.
https://developer.android.com/studio/build/shrink-code#configuration-files
/proguard.txt - If an AAR library is published with its own ProGuard rules file, and you include that AAR as a compile-time dependency, R8 automatically applies its rules when compiling your project.
Using rules files that are packaged with AAR libraries is useful if certain keep rules are required for the library to function properly—that is, the library developer has performed the troubleshooting steps for you.
However, you should be aware that, because ProGuard rules are additive, certain rules that an AAR library dependency includes cannot be removed and might impact the compilation of other parts of your app. For example, if a library includes a rule to disable code optimizations, that rule disables optimizations for your entire project.
/META-INF/proguard/ - for JAR libraries
It's commonly used by libraries like OkHttp https://github.com/square/okhttp/blob/okhttp_4.10.x/okhttp/src/main/resources/META-INF/proguard/okhttp3.pro
I'm working on an Android SDK that is about to be split into separate modules, with some code being shared between others, namely:
shared classes
SDK with feature #1
SDK with feature #2
There is a need of obfuscating the output AARs. With one single module it's not an issue, but I can't find how to configure the whole project correctly with Proguard.
How does the Proguard obfuscation work in case when I want to publish a new version of all these libraries? Will all the modules be obfuscated separately? How can I make sure that all the modules will be obfuscated at once and the release version of the libraries will correctly refer to all the artifacts that are located in the shared module?
Not sure I understand the issue.
But if you want to release 2 SDKs now instead of 1 (before split), I don't think the setup should differ very much.
Just make sure you have proguard file in these SDKs and you are using it in the build script specific to that SDK (module). Then just run something like :sdk:assembleRelease and you are done.
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'library.pro'
}
It is described in detail in this issue:
Obfuscating the .aar files
I understand that shared module is not published, so there you just need to define specific proguard rules that will be used by other modules, like this:
release {
minifyEnabled true
consumerProguardFiles 'onboarding-proguard-rules.pro'
}
I am developing one android library for that i want enable the progurad.
First thing i did is:
I have enabled the minification for my library
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
After this, I have generated the AAR file with minification. And then i used the AAR file to my testing app to check whether my library classes were available. But classes were not there, Because the pro guard removed all my classes from library as it was not used.
Second thing i did is:
-keep public interface com.example.client.** { *; }
I have added the above thing to my proguard-rules.pro. Now i can able to see all my classes with proguard applying the same class, function, variable names. (In mapping file i could see the same name getting applied)
I don't know the exact way to apply the proguard to generate the obfuscated AAR.
Is there any guideline to generate AAR with the minification/
Or in my case what is fix to generate AAR with the class available?
I am struggling for a long time... Could someone please try to help me!!!
I'm use in my android project gson library:
compile 'com.google.code.gson:gson:2.7'
I'm use it not in app module, but in my android library and this library added to project. Only several classes (groupA) used gson. Android library is common library and used in several android projects, but in current android project do not used classes from groupA.
I have in build.gradle of app:
android {
...
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
I build release apk and decompile classes.dex. I do not find classes groupA in apk. It's ok. proguard remove unused code.
Unfortunately I see gson classes. But why? Why proguard do not remove gson classes? gson really do not used in release version of project.
I think you should have a look at the proguard file of gson which is included in each build: https://github.com/google/gson/blob/master/examples/android-proguard-example/proguard.cfg Recognize the remaining classes there?
Why proguard do not remove gson classes?
Ask it:
Use the proguard option -whyareyoukeeping to find out why the gson classes are not removed
http://proguard.sourceforge.net/manual/usage.html#shrinkingoptions
Since I am using many dependencies in my app, I am reaching the 65k Method Limit (I am reaching 76k methods). I've read on android.developer that proguard is used to shrink the code.
So - does proguard only shrink my application code or does it shrink the code of my dependencies too? Do I need to be wary of something when shrinking code with proguard? How do I do that?
My Gradle Build:
apply plugin: 'com.android.application'
android {
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "some.Path"
minSdkVersion 15
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
packagingOptions {
exclude 'META-INF/DEPENDENCIES'
exclude 'META-INF/NOTICE'
exclude 'META-INF/NOTICE.txt'
exclude 'META-INF/LICENSE'
exclude 'META-INF/LICENSE.txt'
}
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
debuggable true
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
configurations {
compile.exclude group: 'org.apache.xmlbeans'
}
repositories {
maven { url "https://jitpack.io" }
}
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:21.0.3'
compile 'com.github.PhilJay:MPAndroidChart:v2.1.0'
compile 'com.opencsv:opencsv:3.4'
compile 'org.apache.poi:poi:3.12'
compile 'org.apache.poi:poi-ooxml:3.12'
}
TL; DR: invert your -keep option unless you love troubles
Firstly: I believe, that you are making right choice by using Proguard to overcome the dex limitation. I would not recommend using multidex support library under any circumstances: it introduces problem of multiple classloaders in your application, and that may backfire in many non-obvious ways.
Here is my personal approach to shrinking the app efficiently:
Pick a couple of hugest third-party dependencies you have;
Check if those really support Proguard;
If they do, shrink them with Proguard;
If you still don't fit in maximum method count, do steps above for some of remaining dependencies;
If you still don't fit, possibly reevaluate some, that do not support Proguard, possibly read their source code to get better idea why they don't, and apply Proguard to them yourself;
In the worst case, apply Proguard to your own code;
If absolutely nothing of above helps, use multidex.
Picking dependencies for shrinking
In your case, there aren't many (direct) dependencies in the first place. You may want to look at output of gradlew dependencies to get better idea of your indirect dependencies, some of which may be biggest contributors to total app size. Then you may proceed to use some of tools listed in "Dex" section of Android Arsenal to learn which libraries contribute most to dex method count. You seem to already have a general idea of it, so I won't dwell much on this part.
Remember: shrinking executable code is somewhat non-trivial intervention in library internals, so you'd rather shrink less to avoid mysterious problems in future. If in doubt, start from libraries, that openly declare, that they do support Proguard officially (in your case that would be Android Support libraries).
Note, that "supporting Proguard" may mean different things for different developers. You can expect Android Support Library developers to be at least basically competent, but many others will ship with consumer Proguard rules like this:
-keep class com.example.library.** { *; }
In case you wonder, the above config is based upon many real-life configs, such as Square's Leak Canary Proguard configuration. It does not say anything about overall competency of developers in question, just reminder that using Proguard can be hard. And yes, this kind of configuration will completely prevent shrinking and obfuscation of the library, unless you build it's local copy from source code and remove such helpful consumer-proguard-rules.pro from there.
Evaluating dependencies for Proguard
As shown above, even experienced developers sometimes choose to ignore Proguard. If Google searches regarding the library and it's compatibility with Proguard return nothing (and even if they do return some results!) you may have to make your own judgement regarding usage of Proguard. Here is how I personally do:
If there are words "framework", "enterprise", "reflection" anywhere on the library site, it is likely to be poorly compatible with Proguard;
If the library has anything to do with compile-time code generation (a-la Butterknife, Dagger etc.), think twice before using Proguard;
If the library messes with JNI, think a couple more times before using Proguard on it, and Google for it's effects on Proguard even if you don't shrink the library itself;
If in doubt, Google for it and/or read library source code: usage of Class.forName as well as Proxy.getInvocationHandler and similar reflection code are usual bad signs.
Libraries, that offer Android UI components (such as MPAndroidChart) are usually ok to shrink, at least if you keep getDefaultProguardFile('proguard-android.txt') in your Gradle config.
The most important part
A lot of developers (including Proguard developers themselves!) will offer you a misguided recommendation to start from empty Proguard config + default Android Proguard configuration, and eventually add -keep rules when necessary.
DO NOT DO THAT!!
Those advices come from people, who are either too badass to understand problem of average developer (read: "the Proguard developer himself") or don't have a clue about using Proguard properly. In fact, these kind of misguided practices are the very reason, why many answers to this question warn you against using Proguard: it's default behavior is like suggesting someone to start mountaineering from scaling the Everest.
Default Proguard configuration will obfuscate, shrink and optimize everything—your entire application with all dependencies except some classes you explicitly exclude. You don't want that, unless you have absolute understanding of every library and line of code in your projects: how they work and interact with each other, which techniques they internally use etc.
Instead you want to do the minimal necessary intervention (shrinking the code to reduce dex method count) in the minimal possible range (few hugest libraries) with minimal consequences (only where Proguard is known to work for sure). Here is my Proguard config for such cases:
-dontoptimize
-dontobfuscate
# Prints some helpful hints, always add this option
-verbose
-keepattributes SourceFile,LineNumberTable,Exceptions,InnerClasses,Signature,Deprecated,*Annotation*,EnclosingMethod
# add all known-to-be-safely-shrinkable classes to the beginning of line below
-keep class !com.android.support.**,!com.google.android.**,** { *; }
Add the above rules to your app's proguard-rules.pro, they will shrink only classes, that you explicitly allow to shrink. Append wildcards for other safely shrinkable packages (exactly as above—with ! and .** parts) to beginning of the -keep line.
As an alternative to ProGuard you could use the built-in Gradle shrinker by turning off ProGuard but still reference a ProGuard config. This will remove unused code but not obfuscate or do any other "magic". Although recommended only for Debug builds I don't see why you can't use it for Release builds as well if you don't think that you need obfuscation.
The main benefit, compared to ProGuard (in my opinion) is that you avoid tight coupling between a ProGuard configuration and the structure of your codebase and third party dependencies.
build.gradle:
minifyEnabled true
useProguard false
proguardFiles ('proguard-basic.pro', getDefaultProguardFile('proguard-android.txt'))
proguard-basic.pro:
-dontwarn javax.**
-keep class com.mycompany.** { *; }
If you enable minification via ProGuard, it will also minify your dependencies.
Libraries are typically not already obfuscated/minified with ProGuard. Some libraries will not work properly by default if they are obfuscated, so you should check any libraries you use to see if they have any documentation surrounding ProGuard. Butterknife, for example, has a few special ProGuard rules that you need to include to ensure that it continues working properly.
For me you should rather look for multidex, to go beyond 65k limit, not proguard as in longer run the later is not a solution to your problems.
See docs: https://developer.android.com/tools/building/multidex.html
If you enable minification in your build.grade file, then yes it will also shrink your dependencies.
Keep in mind that Proguard may introduce unwanted side effects. Not all libraries/dependencies can be shrunk as Proguard also obfuscates the code. (i.e. turns String name into String n) and removes unused code.
Take a look at this Github project: https://github.com/krschultz/android-proguard-snippets
As an alternative, you can look into using MultiDex. You can read about it here: https://developer.android.com/tools/building/multidex.html
As per the new Android Studio update in version 3.2 new code shrinker that also obfuscates by adding the line below to your project’s gradle.properties file
Add This line:
android.enableR8 = true