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.
Related
I'm running the latest version of Android Studio (2.2 Preview 1) that was just released and trying to take advantage of some of the new tools.
The new APK Analyzer is very useful but I can't get it to work with debug builds, it only seems to be accurate for release builds.
Here is a screenshot of what the release build looks like, as you can see the method count looks accurate and all the android libraries that I am using are included.
Now, if I pull in the debug build of the same application it looks totally different. All of my application code is missing, as well as all the third party libraries. And you can see that the method count has also been reduced dramatically.
So am I doing something wrong here? How can I get this analyzation to take place on my debug builds as well?
Note via James Lau on G+:
tool was designed to help you understand and reduce the size of your
release APK, since that is what you publish. As such, you probably
want to run it on your Release APK. You can leave Instant Run turned
on for building Release APK as Instant Run only works on Debug.
Are you sure you have a complete debug build and not a APK file for an HOT or WARM SWAP?
Android Studio since 2.0 has a feature called "Instant Run" that allows to create some sort of "delta-APKs" for updating an app on-device after you made some small changes. The advantage is that you don't have to execute a full gradle build process and therefore such a HOT SWAP is much faster.
Those special HOT/WARM SWAP APKs include only the changes you made recently and some additional code for merging the created APK into the existing APK on-device.
Therefore you should try to execute "Rebuild project" or "Clean project" and see if the created debug APK is as you expect.
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.
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.
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
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.