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.
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.
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.
I've been developing an app for a while and now I want to hand it out to friends for testing. The app works perfectly when debugging to my device but when I build and sign the apk and move it to my device I can install it without any errors but it will not run (I don't even get any error messages). Sometimes the screen goes black as if the app is about to start but then it just reverts back to the previous screen (One time the Monogame splash screen appeared before it reverted to the previous screen).
Here is what I have done so far and any specific details:
I'm using Visual Studio Professional 2014 with Xamarin.Android 4.20.
I'm creating my app using MonoGame.
I have cleaned and built my app in Release mode.
These are my packaging options:
These are my linker options:
(I believe choosing "None" only means my apk will be larger).
I created a keystore using Java's keytool.
I created and signed the apk using Xamarin's Visual Studio "Publish" command.
After all of this the apk will still not run.
So it turns out this was nothing to do with the signing or building of the release mode apk, it was actually down to an exception which was only being thrown when the app was built in release mode (I have no idea why this was the case).
The thing that was throwing the exception was the DotNetZip library, I'd post an issue on it's page but it looks like the project is dead anyway (Also, they don't explicitly support Xamarin Android).
My solution was to use ZipStorer alongside Mono's .Net compression implementation. Everything works nicely now.
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.
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.