Using build types in Gradle to run same app that uses ContentProvider on one device

Question

I have set up Gradle to add package name suffix to my debug app so I could have release version that I\'m using and debug version on one phone. I was referencing this: http:

Answer 1

New Android build system tip: ContentProvider authority renaming

I guess all of you have heard of the new Android Gradle-based build system. Let's be honest, this new build system is a huge step forward compared to the previous one. It is not final yet (as of this writing, the latest version is 0.4.2) but you can already use it safely in most of your projects.

I've personnaly switched most of my project to this new build system and had some issues because of the lack of support in some particular situations. One of which is the support for ContentProvider authority renaming

The new Android built system lets you deal with different types of your app by simply modifying the package name at build time. One of the main advantage of this improvement is you can now have two different versions of your app installed on the same device at the same time. For instance:

android {
   compileSdkVersion 17
   buildToolsVersion "17.0.0"

   defaultConfig {
       packageName "com.cyrilmottier.android.app"
       versionCode 1
       versionName "1"
       minSdkVersion 14 // Listen to +Jeff Gilfelt advices :)
       targetSdkVersion 17
   }

   buildTypes {
       debug {
        packageNameSuffix ".debug"
            versionNameSuffix "-debug"
       }
   }
}

Using such a Gradle configuration, you can assemble two different APKs :

• A debug APK with the com.cyrilmottier.android.app.debug package name • A release APK with the com.cyrilmottier.android.app package name

The only issue with that is you won't be able to install the two APKs at the same time if they both expose a ContentProvider with the same authorities. Pretty logically we need to rename the authority depending on the current build type … but this is not supported by the Gradle build system (yet? ... I'm sure it will be fixed soon). So here is a way to go:

First we need to move the provider Android manifest ContentProvider declaration to the appropriate build type. In order to do that we will simply have :

src/debug/AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="com.cyrilmottier.android.app"
   android:versionCode="1"
   android:versionName="1">

   <application>

       <provider
           android:name=".provider.Provider1"
           android:authorities="com.cyrilmottier.android.app.debug.provider"
           android:exported="false" />

   </application>
</manifest>

src/release/AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="com.cyrilmottier.android.app"
   android:versionCode="1"
   android:versionName="1">

   <application>

       <provider
           android:name=".provider.Provider1"
           android:authorities="com.cyrilmottier.android.app.provider"
           android:exported="false" />

   </application>
</manifest>

Make sure to remove the ContentProvider declaration from the AndroidManifest.xml in src/main/ because Gradle doesn't know how to merge ContentProviders having the same name but a different authority.

Finally we may need to access to the authority in the code. This can be done pretty easily using the BuildConfig file and the buildConfig method:

android {   
   // ...

    final PROVIDER_DEBUG = "com.cyrilmottier.android.app.debug.provider"
    final PROVIDER_RELEASE = "com.cyrilmottier.android.app.provider"

   buildTypes {
       debug {
           // ...
           buildConfigField "String", "PROVIDER_AUTHORITY", PROVIDER_DEBUG
       }

       release {
           buildConfigField "String", "PROVIDER_AUTHORITY", PROVIDER_RELEASE
       }
   }
}

Thanks to this workaround you'll be able to use BuildConfig.PROVIDER_AUTHORITY in your ProviderContract and install two different versions of your app at the same time.

---

Originaly on Google+: https://plus.google.com/u/0/118417777153109946393/posts/EATUmhntaCQ

Answer 2

My solution is to use placeholder replacement in AndroidManifest.xml. It also handles packageNameSuffix attributes so you can have debug and release as well as any other custom builds on the same device.

applicationVariants.all { variant ->
    def flavor = variant.productFlavors.get(0)
    def buildType = variant.buildType
    variant.processManifest.doLast {
        println '################# Adding Package Names to Manifest #######################'
        replaceInManifest(variant,
            'PACKAGE_NAME',
            [flavor.packageName, buildType.packageNameSuffix].findAll().join()) // ignores null
    }
}

def replaceInManifest(variant, fromString, toString) {
    def flavor = variant.productFlavors.get(0)
    def buildtype = variant.buildType
    def manifestFile = "$buildDir/manifests/${flavor.name}/${buildtype.name}/AndroidManifest.xml"
    def updatedContent = new File(manifestFile).getText('UTF-8').replaceAll(fromString, toString)
    new File(manifestFile).write(updatedContent, 'UTF-8')
}

I have it up on a gist too if you want to see if it evolves later.

I found to be a more elegant approach than the multiple resources and XML parsing approaches.