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'
}
}
Related
I want to build a secure release apk, It's mean that anyone can not mod or Tampering (hack)
There's no way to protect your app 100% from being modified, but to make it harder for hackers to understand and modify your code, change minifyEnabled to true in your build.gradle file.
You can read more about shrinking and optimizing your app here. https://developer.android.com/studio/build/shrink-code
android {
buildTypes {
release {
// Enables code shrinking, obfuscation, and optimization for only
// your project's release build type.
minifyEnabled true
}
}
}
If you sign your app, it cannot be tampered with without invalidating the signature.
However, that is not sufficient to stop someone moding your code and then running it on a "rooted" device. Or similar.
In fact, there is nothing you can do to 100% prevent that. The best you have is to use an obfuscator, and hope that the hackers are not going to try hard.
There is no technical solution that will prevent a user from tampering with a 3rd-party app on any platform that they control. This is not an Android or Java specific problem. It applies for all user-controlled platforms and all programming languages.
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 written many unit and instrumented tests for my Android app. So far, I only run these against the debug build variant. Is it necessary to run tests against the release build variant? What difference can there be that might give different results from testing? The main one that I can think of is when ProGuard is enabled, which I haven't done. What will ProGuard do that makes it necessary to run my test suite? What other issues should I be aware of that require testing the release build variant?
Is it necessary to run tests against the release build variant?
I think you should.
What difference can there be that might give different results from testing?
A couple of examples:
You might have code that uses fields of the BuildConfig class to enable/disable certain workflows. Some libraries might also use that, especially BuildConfig.BUILD_TYPE. It's common to do things like:
if (BuildConfig.BUILD_TYPE.equals("debug") {
ACRA.init(...);
Stetho.init(...);
...
}
but have code fail in release builds due to trying to use components/libraries that were not initialized correctly.
As you mentioned, ProGuard might throw away some of your classes unless it's properly configured (e.g. imagine you forgot to add rules for some 3rd party library). Running your tests against the release variant ensures that the ProGuard configuration is correct.
What will ProGuard do that makes it necessary to run my test suite?
ProGuard might remove classes/methods/fields that are, for example, loaded via reflection unless you add the #Keep annotation to them. It might also rename classes used by libraries like Realm, Retrofit, Gson or Volley resulting in all unit and integration tests passing on debug builds (where ProGuard isn't enabled) but failing on release builds. You definitely want to test these before shipping our a new APK.
What other issues should I be aware of that require testing the release build variant?
The release build might also apply PNG crunching, specify different parameters via the buildConfigField method in Gradle, apply splits by ABI or density or enable/disable multidex and others. All of these can have implications in the way that your app works, so why not be on the safe side and test them too.
Another frequent problem that you can catch using these is ensure that you've not accidentally put code in the wrong location (e.g. /src/debug/java/) that happens to be loaded in debug builds but not in other variants.
I have read Best way to include debug code for including debug only code in android and was really helpful.
what I'm asking and couldn't find answer for is:
Is debug only code suggested by above solutions completely removed from release type apk?
By using the method described in the suggested answer of the link you provided, the debug only code is removed by the compiler from the release type apk when setting DEV_MODE=false.
If you need to have automatic switching between debug and release code without having to remember to set a constant variable, you will have to add a debug folder next to your main folder in your src and re-implement any class you need to modify.
I have an Android project that I recently published to the market after running it through obfuscation with ProGuard.
The project exported without any complications, but how do I know it's been obfuscated? Is there anything I could do to verify that obfuscation was successful?
Look for dump.txt, mapping.txt, seeds.txt and usage.txt. They will probably be in a proguard folder at your project directory. These are created when ProGuard is run on your code.
These are filled with information about the obfuscation, especially useful is mapping.txt which shows what ProGuard turned your various member names in to.
Try to reverse engineer your own application. See what you can read in the code.
Use the following questions:
decompiling DEX into Java sourcecode
http://www.taranfx.com/decompile-reverse-engineer-android-apk
DISCALIMER: I am not the owner of decompileandroid.com and I am not paid to promote it. I am a develper, who is satisfied with this service.
There is actually an easier way than acquiring several different tools and passing the output of one of them to the other (this of course gives you a better control of what's going on). You can use the service
decompileandroid.com
Basically you upload and .apk file and it does all of these steps for you.
Then you can download a .zip file, which contains the decompiled sources.
You can first upload your .apk built in debug mode, then upload an .apk built in release mode. Just make sure that the flag minifyEnabled is set to true in your build.gradle file for the release build.
The difference was pretty obvious in my case - most of my classes were named a,b,c, etc in the minified build.