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
Related
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.
Now that my android app is released on the google app store, I would like to continue developing and debugging on the device.
I have a few options:
Delete the app from the device and install a new version during development.
This has disadvantages. I lose the local files saved with the released app, and, when the time comes for the next release, I do not share the same experience as my users while upgrading.
Introduce a minimal change by, say, renaming the package. The two apps are now distinct and can co-exist on the device.
This introduces a superfluous change in the souce tree, with all the headaches that that entails.
If you have avoided these difficulties, what approach have you taken when you continued to develop after release?
I recommend switching to Android Studio and Gradle. Using build types (which I can't link to because I am a n00b and have no reputation), you can easily switch between debug and release builds, and set up your build file to have both on your device at the same time without changing anything in your source or manifest.
The one big gotcha that I failed to understand and bit me in the butt several times until I got it is that in the Build Variants tool window, the selected build variant controls everything. If you choose the release variant:
when you build, it will build an APK with your release keys (if you've set them up in the build files)
when you run the app, it will put the release version on your device
if you try to debug the app, the debugger will not attach because the app is not debuggable
And of course all the reverse if you select the debug build variant.
You have to give up Eclipse, which if you're like me is a sad thing, but I've heard they're planning to add Gradle support to Eclipse at some point.
Suppose I have the code and the mapping of the obfuscated app. Can I somehow debug this app within Eclipse?
In Eclipse, Proguard obfuscation is activated only when the app is exported, aka Release Mode.
Debug information are not added in this configuration, as far as I know.
When you build your application in release mode, either by running ant
release or by using the Export Wizard in Eclipse, the build system
automatically checks to see if the proguard.config property is set. If
it is, ProGuard automatically processes the application's bytecode
before packaging everything into an .apk file. Building in debug mode
does not invoke ProGuard, because it makes debugging more cumbersome.
Source
Edit:
It looks some like hackish solutions exist.
Here are two discussions that may help you:
Issue 14469: Optional ability to run proguard on debug builds when using Eclipse ADT
Issue 34019: Allow proguard stripping in debug builds from ADT
Yes you can. Proguard simply makes it difficult to make sense of it by obfuscating the code.
Does anyone know of a clever way, ideally using the Eclipse/ADT workflow, to apply specific resources to a project depending on whether it was a debug or release build (i.e. in Eclipse whether the application was Run or Exported)? The common use case we run into all the time for this is with API keys (like Maps). It would be great to set up a project to have a strings.xml file specifically for all the debug strings, and then a separate one for all the release strings.
Is there any way to do this without needing to move to the ANT or Maven style of building?
Although it's not what you've asked for, I highly recommend automating the release build as you want that to be consistent and correct every time you build it.
For development you can keep using the Eclipse workflow in that case. For my own app, Rainy Days, I switch out the debug vs release map keys in the ant build. I've set the map key in a string resource and replace that string in the ant build. I then build the release using Jenkins and get the blessed apk from Jenkins if the build succeeds. The nice thing about that is that you can further automate the build with unit tests and device installation tests in an automated fashion.
IMHO you shouldn't be detecting debug builds in your code, as it adds more code paths and makes your code more complex, and even introduces overhead at runtime in some cases.
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