The golden rule is to set debuggable option to off prior to releasing your Android application to the public.
What would happen if I leave (forget to turn off) this option on? I mean, how would it manifest to a user?
I tested and saw no difference.
how would it manifest to a user?
A normal user won't notice the difference.
By the way:
Support for a true debug build. Developers no longer need to add the android:debuggable attribute to the tag in the manifest — the build tools add the attribute automatically. In Eclipse/ADT, all incremental builds are assumed to be debug builds, so the tools insert android:debuggable="true". When exporting a signed release build, the tools do not add the attribute. In Ant, a ant debug command automatically inserts the android:debuggable="true" attribute, while ant release does not. If android:debuggable="true" is manually set, then ant release will actually do a debug build, rather than a release build.
On a standard phone with USB debugging disabled, it will allow any application to debug the App. This will effectively allow any malicious application to gain full access to the App.
See https://labs.mwrinfosecurity.com/blog/2011/07/07/debuggable-apps-in-android-market/ for a detailed description of this problem.
It's possible that it could slow down their mobile device, especially if you have a lot of debug statements in your application. It's also possible that a malicious user could learn more about the inner-workings of your app then you'd like them to.
Regarding the golden rule, you're absolutely right. It's a good idea to turn that off, just to be safe.
It's also possible that a malicious user could learn more about the inner-workings of your app then you'd like them to.
One good practice is to link debugging mode specifically to your unique device id.
#askmo: you can use some tools in the SDK to check if an APK has the debug value. Check the following link:
http://lulachronicles.blogspot.com/2011/04/how-to-check-if-apk-has-flag.html
BR,
Ignacio
Related
After I open the "Profile / debug APK" at the Android Studio for my apps, I found out there is a list of the properties. When I check other's apk, there is none like my apps. Should I care about it or not?
these libraries are from third parties, therefore should be considered as "outside of your responsibility" and most likely, their Manifest.xml does not even have attribute android:debuggable="true".
since you demand "official sources", have a look here, which only confirms what I've wrote:
However, you need to make sure you’re using an APK with debugging enabled.
I am new to android as well as android studio.
From my experience in visual studio, when we test the .exe in another machine we copy the release folder and .exe.
But in android studio I am seeing my colleagues test the debug apk by copying and deploying in other systems using USB drive. seems working also.
May I know what is the consequence of deploying that version? Is the release version relevant only for a play store purpose?
What is the technical difference/consequence other than that debug version contains debug information which may makes it slow or bulky?
Major differences are the debug flag and the signing keys:
For debug builds the apk will be signed with the default debug signing keys with debug flag enabled.
For release keys you will have to explicitly specify the keys to sign with and the debug flag will be turned off so that it cannot be debugged.
Proguard can be turned on for release builds. (also for debug builds but not advised). This step needs to be done explicitly and is false by default.
Note: these things can be altered in your build.config and you can choose what ever permutation and combination you wish.
One important difference is that release APKs typically have had ProGuard (code shrinking) run on them, which detects and removes unused code to reduce the APK size.
From Shrink Your Code and Resources:
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, because it might introduce bugs if you do not sufficiently customize which code to keep.
Your colleagues are probably testing on the debug build type to save time, because it can take significantly longer to build the release APK as opposed to the debug APK.
The all above answers are correct BUT the major difference is that if we use the debug.apk to install the app on the device/emulator we can
*Debug it with debuuger
*Profile the cpu, memory, network with android studio profiler
*See the logs in the logcat
*Debug the layout with layout inspector
if use release.apk we can't use the above features, and we configure some features/libraries to work in specific out put type (Like we can use leakCanary only in debug apk)
The primary difference (if specified otherwise in the build.gradle) between a debug build and a release build is the key with which they are signed. Most app distribution channels would [only] want an app signed with a release key to authenticate the developer. Otherwise, there are no differences.
A release build may also trigger other options like code obfuscation and splits so, look out for these.
However, there are many changes that can be brought about in between these two versions. These should be specified in your build.gradle, if any. So, you should keep an eye there.
What are some notable differences that a developer should take note?
The first one is debuggable and the second one isn't.
That means that the first one will output all your Log.d's and the production version won't.
Also, by default, debug versions are compiled without ProGuard while production builds are compiled using the default ProGuard rules
you may take a look at those posts
Android Studio: Build type release /debug - what relevance does this have?
also the officiel documentation is clear and hepful
http://developer.android.com/tools/publishing/app-signing.html
hint
debug when you are working on the project
release when you are about to publish the app
good luck !
One of the most important differences is that debug version of app is not prguarded so it can be reverse engineered. The reason why it's not proguarded is because you can track your logcat outputs easily without need to check mapping files.
In debug mode, you sign your app with a debug certificate generated by the Android SDK tools. This certificate has a private key with a known password, so you can run and debug your app without typing the password every time you make a change to your project.
To automate tests, we are considering the Android instrumentation tests. However, we are concerning the performance may differ significantly if the unit tests are put in the debug mode. After doing some search, there seems no definitive answers. Thus, we need some clarifications about the following points.
Does Eclipse/ADT compile the project using the same compiler optimization options whether it is in debug or release mode?
the apk generated by Eclipse/ADT is always in debug mode (whatever "run as" or "debug as"). The suggested way to build the release version is through the export wizard. The only difference is the attribute "android:debuggable='true'" in the resulting AndroidManifest.xml. Without proguard enabled, the resulting size seems the same. Assuming no compiler optimization, does this attribute cause or change the JIT optimization at run-time significantly?
We use the debug key to sign the apk and it seems to work. Is the resulting apk truly a release version (We think so because "android:debuggable="true" is removed)?
Thanks.
1) Yes and no, even though the optimization is the same, the application will run slower as it will have lots of subproceses monitoring it.
2) AFAIK it isn't significative but it will affect the performance of your app.
3) It will work but it's not recommended, you should try reading the SDK here
http://developer.android.com/tools/publishing/app-signing.html
Is it possible to debug a signed release of one's application on a commercial Android device that cannot be modified? One which does not have with debuggable = "true".
Yes it is possible. However, the application must have android:debuggable="true" in its manifest file.
Here is a similar question that gives you more detail.
If you can connect to the device with the debugger, than once the application is running it doesn't matter if it was from a signed apk, you can try to attach the debugger to the application process.