Mobile App Development Service
  • Posted by:

    Adhish L

    • June 07, 2018

    Break the rules: Installing multiple APK for the same app

  • Blogs
  • Break the rules: Installing multiple APK for the same app
  • Blogs
  • Break the rules: Installing multipl...

While developing one of the apps for a client, I felt the need of one necessary requirement which was to install two or more instances of the same app in your Android phone without creating a new user or pointing to different servers.

But, before we move on to understanding how to install multiple variants of the same app in your phone, let's see what is an Application ID in an Android build system.

Your application ID is defined with the application ID property in your module's build.gradle file, as shown here:

android {
    defaultConfig {
        applicationId "com.example.myapp"
        minSdkVersion 15
        targetSdkVersion 24
        versionCode 1
        versionName "1.0"
    }
    ...
}

Here is the crack!

So, basically if we define multiple application ID  according to different instances, it will result in having multiple APKs of the same app in the same device without changing or switching the user, which is not what we need.

Now the question arises, as to how to define the multiple application ID of the same application?

The answer is simple, through different build variants.

For the APK,the application ID is tagged with the APK by the build tools defined in the defaultConfig block from the build.gradle file (as shown below). However, if you want to make multiple versions of your app to appear as different listings on the Google Play Store, such as a "free" and "pro" version, then you need to create separate build variants so that each have a different application ID.

In this case, each build variant should be defined as a separate product flavor. For each flavor inside the productFlavors block, you can redefine the application ID  property, or you can instead append a segment to the default application ID using applicationIdSuffix, as shown here:

android {
    defaultConfig {
        applicationId "com.example.myapp"
    }
    productFlavors {
        free {
            applicationIdSuffix ".free"
            resValue "string", "app_name", "My Free App"
        }
        pro {
            applicationIdSuffix ".pro"
            resValue "string", "app_name", "My Pro App"
        }
    }
}


This way, the application ID for the "free" product flavor is "com.example.myapp.free" and for "pro" it will be "com.example.myapp.pro" because the  applicationId will be suffixed by "free" and "pro" (by using applicationIdSuffix) respectively and so as the  application ID differs due to this suffix, there will be two instances of the same app in your device pointing to different environments!

Also, one thing to note, the two apps will have different app names as well. The "free" version will be named as "My Free App" and "pro" app will be named as "My Pro App". Just make sure you remove the "app_name" from strings.xml file from where your application name comes because we are defining the resource value of "string" with the name "app_name" as "My Free App" and "My Pro App".

Basically, you can define almost any resource value in your gradle file and it will configure your app based on the build variants.

If you want to switch between different servers then the code below will might help you:

flavorDimensions "default"
productFlavors {
    STAGE {
        dimension "default"
        buildConfigField 'String', 'API_BASE_URL', ""http://development.appinessworld.com/""
        buildConfigField 'boolean', 'ISPRODUCTION', "false"
        applicationIdSuffix ".dev"
        resValue "string", "app_name", "My Free App"
    }
    PRODUCTION {
        dimension "default"
        buildConfigField 'String', 'API_BASE_URL', ""http://appinessworld.com/""
        buildConfigField 'boolean', 'ISPRODUCTION', "true"
        resValue "string", "app_name", "My Pro App"

    }

}

Flavor Dimensions allow us to define groups of flavors. Gradle creates every combination between these groups for us.

Conclusion

It is too tough a job, sometimes,  for an Android developer to install the APK of same version of the same app in a phone pointing to two or more environments(staging, production, debug etc.) but it can be easily achieved by just changing the package name of the builds.  Gradle build system helps us in doing this. As the, Google’s PlayStore treats different package names as different apps, so does our phone. Just changing the package name of the APKs at the compile time via gradle actually does the needful. 

I hope this trick helps to expedite the coding process.

TOP