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.
Related
this is a conceptual/design question.
We have a Xamarin Forms apps and I'm creating a build and release pipeline for the Android version in Azure DevOps.
We have 4 environments in total, internal, RC, staging and production.
For each of those I have created a powershell pre-build script that changes some configuration xml files, the app icons (different colours for different environments) and even the app name and package name (this way we can have all 4 installed on one device and be able to test using the different servers)
Now I have a build in DevOps which runs the pre-build script to modify all those things, builds the project, signs the apk and publishes it. In my release pipeline, I cannot use this logic because I need to be able to deploy the different apps to their own test groups in App Center.
So I decided to split the build, it would just build and then the release pipeline would have stages - alpha would run the script and modify the app and sign it and put it for testing in an Alpha group, the Beta stage to beta etc...
However, this means I have to modify the .apk after it was produced using powershell. For example, the Android Manifest file's content doesn't look like XML anymore and has strange NUL, DLE and other symbols in it. It'd make my life harder.
Do I build all 4 packages in my Build pipeline with prepared packages for all environments? This would increase the time a lot so it's undesirable but it'd save me from having to edit APKs later...
What are best practices in these kind of situations, what are you able to suggest I do, change the way I do everything or what?
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.
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.
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.
I've got a handful of side-project apps on the go at home, I've setup a Jenkins installation to check them out and build APKs, which I then transfer over to my handset and play around with.
I'm looking to release some of these freely on the market, so I need to sign them with a certificate and prepare the final APK.
Is it possible to do this from Jenkins? For example, could I have one build target that generates my "in development" APKs, and also have that target (or another) create the final APK files ready to go?
Any advice?
If the signing is possible to do automatically (by command line or similar), then the answer is "Yes".
There are several ways to achieve this, but firstly: Is there any good reason not to sign every build?
Signing every build would mean that you don't need any extra configuration to create a releasable artifact, and you know that what you test and what you deploy are the same things.
If you want to be selective about what builds you sign, two approaches come to mind:
Parameterized builds: These are environment variables that can be customized when you click Build now. You can add a flag that you later react on in a build step.
Add another job that picks up the artifacts from your main build job and signs them, using https://jenkins-server/job/jobname/lastSuccessfulBuild/artifact/ or one of the approaches here: How to access Hudson job1 artifacts from another job2?
In the standard Android ant build file is a release target contained. This will if started without further configuration just build an unsigned apk. As Christopher pointed out to do a signed build you can use key.store, key.store.password and key.alias,key.alias.password to configure your keystore and generate signed apks through the ant script. The documentation on this may fprovide further information on configuring the build.
Yes... the easiest way imho is to automate it with Maven Android Plugin. The samples project has the MorseFlash example I wrote in there that has the whole release process automated including jarsigning, zipaligning and proguard runs, switching between development and production config and more.
This can all be done on the command line and therefore on Hudson. Btw if you are interested I did presentations about Maven and Android as well as testing and CI for Android at AnDevCon and the slides are on my web site. http://www.simpligility.com