55

Is it possible to change the package name of an Android application using Gradle?

I need to compile two copies of the same app, having a unique package name (so I can publish to the market twice).

Jonik
  • 80,077
  • 70
  • 264
  • 372
Seraphim's
  • 12,559
  • 20
  • 88
  • 129

5 Answers5

75

As a simpler alternative to using product flavours as in Ethan's answer, you can also customise build types.

How to choose between the approaches:

  • If you need different package names to be able to have both debug and release apks installed on a device, then use the build type approach below, as Gradle plugin docs agree. In this case flavours are an overkill. (I think all projects should by default do this, as it will make life easier especially after you've published to the store and are developing new features.)
  • There are valid uses for product flavours, the typical example being an app with free and paid versions. In such case, check Ethan's answer and read the documentation too: Configuring Gradle Builds and Gradle Plugin User Guide.

(You can also combine the two approaches, which results in every build variant having distinct package name.)

Build type configuration

For debug build type, and all other non-release types, define applicationIdSuffix which will be added to the default package name. (Prior to Android Gradle plugin version 0.11 this setting was known as packageNameSuffix.)

android {
    buildTypes {
        debug {
            applicationIdSuffix '.debug'
            versionNameSuffix '-DEBUG'
        }

        beta {
            applicationIdSuffix '.beta'
            versionNameSuffix '-BETA'

            // NB: If you want to use the default debug key for a (non-debug) 
            // build type, you need to specify it:
            signingConfig signingConfigs.debug 
        }

        release {
            // signingConfig signingConfigs.release
            // runProguard true
            // ...
        }

    }
}

Above, debug and release are default build types whose some aspects are configured, while beta is a completely custom build type. To build the different types, use assembleDebug, assembleBeta, etc, as usual.

Similarly, you can use versionNameSuffix to override the default version name from AndroidManifest (which I find very useful!). E.g. "0.8" → "0.8-BETA", as configured above.

Resources:

Myself I've been using productFlavors so far for this exact purpose, but it seems build type customisation may be closer to my needs, plus it keeps the build config simpler.

Update (2016): I've since used this approach in all my projects, and I think it definitely is the way to go. I also got it included in Android Best Practices guide by Futurice.

Jonik
  • 80,077
  • 70
  • 264
  • 372
  • Wow! thanks. Can I avoid the -debug-unaligned- and -release-unaligned- builds apks that are generated automatically by Gradle? – Seraphim's Jan 08 '14 at 21:43
  • 3
    Well, yeah. If you do `gradle assembleDebug`, it will only produce `myapp-debug-unaligned.apk`. Building a custom type like `beta` above, `assembleBeta` will produce both `myapp-beta-unaligned.apk` and `myapp-beta.apk` ([aligned i.e. optimised](http://developer.android.com/tools/help/zipalign.html)), *unless* you define `zipAlign false` for that type. See "The possible properties and their default values" in [User Guide](http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Types). I assume it's usually fine to only use zipAlign only for actual release builds. – Jonik Jan 08 '14 at 22:29
  • Sorry I can't upvote your answer twice! ;) thanks I'll try your solution – Seraphim's Jan 08 '14 at 22:31
  • 4
    Another tip: when building with Android Studio, make sure you are aware [which build variant (type & flavour) is selected](http://stackoverflow.com/questions/17656826/what-product-flavor-does-android-studio-build-by-default-in-build-gradle). (Perhaps obvious, but I just learned about it a few days ago. :) – Jonik Jan 08 '14 at 22:37
  • I've a bad karma for AndroidStudio. I'll wait for a decent release. I'm using Eclipse and Gradle with batch. Anyway, thanks for the tip. – Seraphim's Jan 08 '14 at 22:48
  • What do you do when you need GCM or other permission which depends on the application ID? e.g `. Any way to provide variables in androidManifest.xml? – Nilzor Jan 21 '15 at 15:03
  • @Nilzor: Sorry, I have no experience with that. Consider asking a new question. – Jonik Jan 21 '15 at 16:08
  • The drawback of this approach (which is fine and should be used _in conjunction with the above_ is that Android won't let you have both (say BETA and DEBUG) installed at the same time, because the package is the same and the OS couldn't care less about the file name ;) – Martin Marconcini Feb 16 '15 at 23:57
  • @MartínMarconcini: you might have misunderstood something. With `applicationIdSuffix` you specifically change the application ID (package name), which means you certainly **can** have beta and debug installed at the same time. *In addition*, my answer shows how to customise version name (which you might for example show inside the app) using `versionNameSuffix `. – Jonik Feb 17 '15 at 09:55
  • 1
    @Jonik you're correct, I misread your post. This is the correct way to do it if you want to have qa/debug/releases build at the same time (useful when you're developing and you want to keep a release version side by side with your development version, to compare behaviors). – Martin Marconcini Feb 17 '15 at 18:07
  • 2
    @Nilzor you can add this to your AndroidManifest: – 3dmg May 13 '15 at 14:54
  • 1
    For AndroidAnnotations users, [this](http://stackoverflow.com/questions/31116644/android-annotations-and-applicationidsuffix) may also help. – Louis CAD Jun 09 '16 at 16:20
58

You could so something like this

android {
    ...

    defaultConfig {
        minSdkVersion 8
        versionCode 10
    }

    flavorDimensions "flavor1", "flavor2"

    productFlavors {
        flavor1 {
            applicationId "com.example.flavor1"
            versionCode 20
        }

        flavor2 {
            applicationId "com.example.flavor2"
            minSdkVersion 14
        }
    }
}

You can also change the field android.defaultConfig.applicationId if you want to do one-off builds.

Taken from: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration

Jonik
  • 80,077
  • 70
  • 264
  • 372
Ethan
  • 6,883
  • 3
  • 33
  • 41
  • 3
    For those wondering how to tell Gradle to build a particular flavour: By default all flavours are built, or you can specify one by running e.g. `gradle assembleFlavor1Debug` or `gradle assembleFlavor2Release`. `gradle tasks` is also helpful. – Jonik Dec 19 '13 at 09:47
  • Hey should I need to copy java files from main/java to the flavor/java when changing the packageName using productFlavor? – Ashwin N Bhanushali Apr 29 '14 at 12:28
  • I don't think so, but I have no data to support that guess. – Ethan Apr 29 '14 at 13:50
  • 1
    Note that `packageName` was renamed `applicationId` (and `flavorGroups` => `flavorDimensions`) in [Android Gradle plugin version 1.0](http://tools.android.com/tech-docs/new-build-system/migrating-to-1-0-0). (Consider updating the answer.) – Jonik May 01 '15 at 21:58
  • 4
    `packageName` is not the same as `applicationId`, see http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename – Philipp E. Sep 21 '15 at 14:41
  • So multiple apps with the same package string in the manifest, but different applicationIds can be uploaded to the Play Store? – Adam Johns May 14 '18 at 00:13
10

With the gradle plugin version of 1.0.0+ you have to use applicationId as stated in the migration guide

Renamed Properties in ProductFlavors

packageName => applicationId

Thus in your build.gradle you would now use:

productFlavors {
   flavor1 {
      applicationId "com.example.flavor1"
   }

   flavor2 {
      applicationId "com.example.flavor2"
   } 
}
Community
  • 1
  • 1
Amio.io
  • 20,677
  • 15
  • 82
  • 117
  • yes, see my other question https://stackoverflow.com/questions/27374933/android-studio-1-0-and-error-library-projects-cannot-set-applicationid/27376053#27376053 – Seraphim's Dec 23 '14 at 14:25
9

From Ethan's answer, both flavorGroups and packageName both are not available anymore. Below works as of March 2015.

android {
...

defaultConfig {
    minSdkVersion 8
    versionCode 10
}

flavorDimensions "flavor"

productFlavors {
    flavor1 {
        flavorDimension "flavor"
        applicationId "com.example.flavor1"
        versionCode 20
    }

    flavor2 {
        flavorDimension "flavor"
        applicationId "com.example.flavor2"
        minSdkVersion 14
    }
}
}
sivag1
  • 4,734
  • 3
  • 32
  • 35
  • 1
    Hey, your response has already been posted! Please delete it before someone vote it down. – Seraphim's Mar 06 '15 at 09:05
  • 1
    Hi @Seraphim's, sorry I don't see where it is posted in the thread. Can you please point me? I would be glad to delete. – sivag1 Mar 07 '15 at 04:39
2

I did not want to use Flavors, so I found a way to do so with buildTypes. I did this by changing my app/build.gradle file as follows:

defaultConfig {
        applicationId "com" // See buildTypes.type.applicationIdSuffix
        ...
    }

    ...

    buildTypes {
        debug {
            applicationIdSuffix ".domain.name.debug"
            ...
        }
        releaseStaging {
            applicationIdSuffix ".compagny.staging"
            ...
        }
        release {
            applicationIdSuffix ".domain.name"
            ...
        }
    }

This allows me to have 3 apps next to each other on my devices.

I hope this helps others.

Francois Nadeau
  • 7,023
  • 2
  • 49
  • 58