I think a lot of Android developers use their daily-driver phone as a developer device. I know I do. This leads into a side effect: you can only have your debug build you’re working on or the production version from Google Play installed the same time. They both have the same app ID but are signed with a different signature. If you want to switch between production and debug it means uninstallations in between.

You should always have the production build of your app installed and not uninstall it to run debug. This helps you to catch issues like database creeping in size or strange update conditions you might otherwise miss. If you always run your app from a fresh install you won’t be on the same page with your users.

Keeping both installed

Fortunately, solving the above issue is easy. Let me explain how I do it in my hobby projects and customer projects. If you feel that this is not the best way to go by it, leave a comment or ping me on Twitter to explain your solution.

Separate debug app ID

Your app ID is defined in the app gradle file generated by Android Studio when you started your app.

You will want to keep the release app ID the most descriptive and least cluttered as it is visible to the users as part of your Play Store URL. So what you want to do is to make the debug build separate. Gradle allows us to do this nicely:

Add the above debug {applicationIdSuffix “.debug”} part to the same app module gradle file.

You now have the minimum viable solution to the problem. You can install the debug build next to your production into your phone.

Telling them apart

Having 2 app icons with the same name isn’t really very helpful. You need to be able to tell them apart and figure out which is which.

Android build variants to the rescue!

Next thing to do is to create specific folders for files that change based on the build variant. So your src folder should end up looking like this:

Gradle will automatically pull files from the right place based on these folder names.

I usually change the app name and the app icon to differentiate. To change the app name, you need to create another Strings file where you add String that change. You don’t want to replicate everything, just the ones changing. There is no right way to do it but here is one way to get it done:

Go to Android Studio and create another values resource file. I usually call this “technical_strings”

Once done, remove the “app_name” string from your Strings.xml and move it to the new file.

Now we just need to replicate the same in both build variants. I usually do this in a file explorer of my OS as this makes me feel like I know what is happening.

In your recently-created debug and release folders create res/values.

From your main/res/values folder copy the new technical_strings.xml to the debug/res/values and release/res/values and then delete it from main.

Get back to your Android Studio and you now see (debug) after the technical_strings file listed in the Android view.

From Build Variants view you can switch between the debug version and the release version of the file. I usually add “DEBUG — “ prefix to my debug version app name so it is very clear which one is which.

Swapping the icon

For even better and quicker differentiation I usually gray-scale the debug icon.

If you’re using adaptive icons and your icon background is either a solid color or AVD you can simply do the above trick to your color resource.

If you’re supporting non-adaptive icons or for some other reason use raster app icon, not to worry, it is just a bit more manual work. You’ll have to make gray-scale versions of each of your resources and copy the mipmap folders into release/res and debug/res and you’re good to go.

And there we go, ready:

You can now keep both apps installed all the time and you won’t get confused which one is running.

Take a look at this commit in one of my hobby projects to see the diff for this whole process:

What about Google Services?

Those pesky Google Services, like Firebase, use your app ID to map to your Firebase Console project, for example. If your app ID is different, your app will crash on startup.

Not to worry, this works as well. Actually, this makes your development process better. You do not want to run your debug builds against the production database / analytics anyways.

First thing to do is to create another Firebase Console project for your debug builds. Use the app ID with the .debug postfix to define everything there. Download the new google-services.json file and keep it on the side a bit.

Move your production google-services.json file into the release folder. Then copy your debug one into the app folder (this is where the console instructs you to put it). From now on, the release build will always use the google-services.json from release build variant and otherwise you use the default one directly from the app folder.