CODEWITHSUNDEEP
androidandroid-studioapk
Dan Chaltiel
Dan Chaltiel

Reputation: 8523

Keeping both release and beta versions of app on my phone

I recently uploaded my apk to the Playstore for my beta testers and I would like to keep this app on my phone.

But if I build it from android studio for further tests, it says :

Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE]

I think it's all about one being in debug mode and other in release mode.

I thought of changing applicationId with a flavour on debug, but I didn't found how to properly do it, and it prevent me for using content providers.

Is there a better way to do this ?

Upvotes: 1

Views: 304

Answers (1)

Richard Le Mesurier
Richard Le Mesurier

Reputation: 29762

Gradle will allow you to change the package name for the different buildTypes configurations. To do this, set the applicationIdSuffix property in your build types:

    debug {
        // append ".debug" to the application ID for this build
        applicationIdSuffix ".debug"

        debuggable true

        // here go the usual debug build properties
        minifyEnabled false
    }
    release {
        // no applicationIdSuffix for the release build

        // here go the usual release build properties
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules-release.pro'
    }

So if your release appliction ID is "mobi.glowworm.demo", then your gradle file will now create a debug build with the applictions ID "mobi.glowworm.demo.debug".

This way you can keep both on your phone at the same time.

I recommend also changing the app name between the 2 builds, as well as to consider a different launch icon. This allows you (and any other testers) to easily differentiate between the builds.

Both of these changes rely on creating different source folders for the builds, following the structure of the app\src\main\... folder that you already have. Create app\src\debug\res and app\src\release\res folders.

In there you can easily add different resources per build (and different source files, but that is harder to handle). Name these the same as the main resources, and gradle will override the default resources with these new ones.

To make it obvious, I call my build type strings file build_type_settings.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!--Override certain application strings to identify build-->
    <string name="app_name" 
        translatable="false">My Debug App</string>
    <string name="api_key_google" 
        templateMergeStrategy="preserve" 
        translatable="false">DEBUG_GOOGLE_KEY</string>
</resources>

Store this in:

  • e.g. \app\src\debug\res\values\build_type_settings.xml

Similarly, you can create separate ic_launcher.png files and store them in the mipmap resource folders:

  • e.g. \app\src\debg\res\mipmap-hdpi\ic_launcher.png

Lastly, at some point, you may need to update the application ID inside your manifest. Maybe for a Parse implementation, or some other reason.

The trick is to replace all instances of your application ID inside your manifest with the ${applicationId} property. Gradle will automatically insert the correct ID where required.

For full details on this, here is a post I have found myself coming back to again and again:

Upvotes: 2

Related Questions