As my Android project getting bigger now I am facing the 64k references limit issue. I read the Configure Apps with Over 64K Methods
article, and it suggests me to reduce the methods count before diving into multidex solution. Now I successfully decreased about 12000 of methods count.
But I still have a problem that is the ProGuard can only take effect when exporing a signed App for release, but not for development. With this fact, I am afraid that I cannot put more code into Eclipse for development, because when I add more methods then I click ADT > Run, I will get the 64k limit error again. I don't want to keep exporting and checking the result during development that is really time wasted.
Will there be any solution for this? Thanks a lot for any advice!
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
This minifyEnable true. will make proguard enabled. but this is in Android studio.
I think you are using Eclipse, which google has deprecated .
Related
I have read the article. The author think every Android app should use code shrinking.
I use the following code to shrink and obfuscate code, proguard-rules.pro is original and blank, and proguard-android-optimize.txt is original. it's default made by Android Studio.
You know that some project can work well in Android Studio but failed after publish to Google Play, you can see the article.
When an app run in Android Studio, I think ProGuard doesn't work and it doesn't shrink and obfuscate code, so the app works well in Android Studio.
When I generate .aab file for publish in Android Studio, the ProGuard will shrink and obfuscate code, but it maybe cause runtime error due to incorrectly shrink and obfuscate operation.
How can I test if ProGuard works correctly before I publish an app to Google Play ?
buildTypes {
release {
minifyEnabled false
shrinkResources false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
debug {
}
}
Add content:
To Ryan M: Thanks!
It seems that I can test whether ProGuard works correctly in Android Studio by the article.
You can see Code A and Image A.
Is that right?
Code A
debugMini {
initWith debug
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
matchingFallbacks = ['debug']
}
Image A
Install and run the minified release version of your app (see here or here for info on installing AAB files) that you upload to Google Play, not the debug version.
If you're just hitting "Run" in Studio, you're installing the debug version that doesn't (by default) have Proguard or other minification run on it. If you instead use the minified release version before uploading it to Google Play, you'll get the same behavior you will after uploading: Google Play isn't running any "extra" Proguard tasks on it after you upload.
You can also use the Alpha/Beta testing tracks in Play to test the full Play experience without publishing to a wider audience or fiddling with bundletool.
There are several ways to confirm you code is being properly minimized. One is to check the youappmodule/build/outputs/mapping/release/mapping.txt file. This will include lines like
com.example.somepackage.SomeClass -> a.b.c.d:
If you see that, you know which classes are being properly obfuscated. You can also find out which classes have been removed by making sure there is no such entry for that class.
Another good way is to inspect the output APK in Android Studio. In Android Studio 4.1 you can do this by going to Build > Analyze APK and then selecting your APK that should have had Proguard run with it. You can then inspect the classes.dex file and check its contents. You can see which classes have been obfuscated and removed by directly traversing the file structure.
I think the easiest way to test it is to build your app in the release version and install it on your device.
This is the simplest way.
I am working an a existing Android app which includes the Dropbox SDK. The SDK includes a ton of new classes which makes it necessary to use minifyEnabled true in buildsettings to avoid multidex.
While this is no problem in my release config it has a major downside when debugging the app: Most of the breakpoint do not work any more.
Even if a breakpoint works and I would like to use the "step into" feature to step through the code it happens that this is not possible. Instead of stepping to the code, the call stack shows obfuscated instead of the real code:
a.c:111,f (com.my.app.a)
xb:106,f (com.my.app.a)
onCreate:62, MyApp (com.my.app.TheClass)
...
So, I cannot set minifyEnabled false. Is there anything else I can do to still use my breakpoints?
If you only want to use ProGuard (minifyEnabled true) in order to prevent the app from requiring multidex, you can disable obfuscation and only use the shrinking feature of ProGuard (assuming that you dont use optimization e.g. when using proguard-android.txt as default config).
This should not create obfuscated stacktraces and allow you to debug the application.
Edit:
In order to disable obfuscation, just add
-dontobfuscate
to your configuration file.
I have been working on android app development from past 4 months and now I have developed my first app and as it is easy to decompile a apk so we should use dex or proguard for shrinking and protection.The problem is I have read in an article that proguard may change the code so sometimes a app may misbehave ,this is my first app and I don't want to mess up.So before using proguard in my app I have few questions -
1.What are the points to keep in mind before using proguard.
2.I read you can use keep command but proguard will not obfuscate that code and it will remain same,so I want my all code but as I will use keep it won't do anything.
3.How to make sure that the after functioning of app is same as before after using proguard.
4.Is is necessary to sign app or make key for using proguard?
Question1. What to keep in mind!
The docs state that there may be unintended events that occur from using proguard
Be aware that code shrinking slows down the build time, so you should
avoid using it on your debug build if possible. However, it's
important that you do enable code shrinking on your final APK used for
testing.
After ProGuard shrinks your code, reading a stack trace is difficult (if not impossible) because the method names are obfuscated.
I believe this answers question 3
The key word here is test, test, test! The moment you create your release apk. Test the functionality against your use cases to see if the application is still running the way it should.
If you don't have tests yet I would recommend write some at least unit tests before you release and test the proguard app against that.
Question 4: No you do not need a key to use proguard. I have used it on my debug builds before.
So your typical release build variant could look something like this:
//AndroidStudio3.0.1Canary
release {
postprocessing {
removeUnusedCode true
removeUnusedResources true
obfuscate true
optimizeCode true
proguardFile 'proguard-rules.pro'
}
}
At first I know Remove all unused resources from an android project, but that is only for projects.
I want to remove unused images from a library like the Google Play Services or the Wearable SDK. I already know that I can remove unwanted languages in gradle by using resConfigs, but I don't know how to remove images and layouts which I don't use. Is there any way to avoid that they are added?
I almost missed it to write that there is now a nice solution:
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
}
}
}
This was annouced on Google+ by Tor Norbye for the build tools version 0.14.0
Probbably all you need to know about that is in this very good article from Cyril Mottier :
http://cyrilmottier.com/2014/08/26/putting-your-apks-on-diet/
Read the part about Lint ("Use Lint extensively"), as it's the tool that allow you to remove unused resources.
Hope it helps...
I have never used Android Studio before. The size of a simple "Hello world" app generated by default is almost 800k, while it is less than 100k in eclipse. I find that there are too many pictures in the drawable files, they seem come from res/all under the build folder, they still exist even if I delete the folder res manually.
My question is how to shrink the apk size in this situation?
The difference is due to the appcompat library which is compiled in by default to New Project Wizard-generated projects in Android Studio if you target an API level lower than 14. When I ran a test, the size increase was 642k for a debug APK, and 411k for a release APK (with Proguard enabled -- that will strip out unused code but not unused resources).
There's not a lot you can really do about this, short of removing the appcompat library if you're not using any of its features (though you should probably be using its features).
I haven't used Android Studio yet (my understanding is that it's still beta), but, I know that with other IDEs, the size of the resulting executable will change based on if it's a Debug or Release version. Eclipse lets you specify one or the other. Does Android Studio do the same?
Try to use "shrinkResources" in (build.gradle app)
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
https://developer.android.com/topic/performance/reduce-apk-size