I will start by saying that I am very new to Gradle, so I apologize if this has already been answered.
I'm working on an Android application that uses an API key to access a 3rd party tool. A different API key needs to be used depending on both the flavor and build type of the app.
Here is a basic outline of what I'm trying to do:
android {
defaultConfig {
manifestPlaceholders = [ apiKey:"DEBUG_KEY" ]
}
buildTypes{
debug{
// Some debug setup
}
release{
// Some release setup
}
}
productFlavors {
// List of flavor options
}
productFlavors.all{ flavor->
if (flavor.name.equals("someFlavor")) {
if (buildType.equals("release")) {
manifestPlaceholders = [ apiKey:"RELEASE_KEY_1" ]
} else {
manifestPlaceholders = [ apiKey:"DEBUG_KEY" ]
}
} else {
if (buildType.equals("release")) {
manifestPlaceholders = [ apiKey:"RELEASE_KEY_2" ]
} else {
manifestPlaceholders = [ apiKey:"DEBUG_KEY" ]
}
}
}
}
So far the manifestPlaceholders statement is working in a very simple case, but I don't know how to reference the buildType from within the productFlavors block so that I can use it as a conditional.
You may set manifestPlaceholders inside applicationVariants by accessing mergedFlavor for specific applicationVariant.
android.applicationVariants.all { variant ->
def mergedFlavor = variant.getMergedFlavor()
mergedFlavor.manifestPlaceholders = [appPackageId: "myPackageExample"]
}
If you're using the Kotlin DSL, you should use something like this:
android.applicationVariants.all { // don't put 'variant ->' here or you'll get the 'all' extension function
// no need to define 'mergedFlavor' because 'this' _is_ the variant so 'mergedFlavor' is already available.
mergedFlavor.manifestPlaceholders = ...
}
I would guess that you are referring to Fabric ApiKey? :) I just spent hours trying to do it in a similar way with the placeholders and specifying the ApiKey in the gradle file although it does not seem possible as of com.android.tools.build:gradle:1.3.1. It is possible to specify a placeholder for a specific flavor but not for a flavor AND buildType.
Just to correct your syntax, the way you would have to do it (if it was possible) would be something like that but manifestPlaceholders are unknown to variants.
applicationVariants.all{ variant->
if (variant.productFlavors.get(0).name.equals("someFlavor")) {
if (variant.buildType.name.equals("release")) {
manifestPlaceholders = [ apiKey:"RELEASE_KEY_1" ]
} else {
manifestPlaceholders = [ apiKey:"DEBUG_KEY" ]
}
} else {
if (variant.buildType.name.equals("release")) {
manifestPlaceholders = [ apiKey:"RELEASE_KEY_2" ]
} else {
manifestPlaceholders = [ apiKey:"DEBUG_KEY" ]
}
}
}
What you actually need to do is to keep the key in the AndroidManifest.xml and handle it with multiple manifest file
src/AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application>
<meta-data
android:name="io.fabric.ApiKey"
android:value="DEBUG_KEY" tools:replace="android:value"/>
</application>
</manifest>
src/someFlavorRelease/AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application>
<meta-data
android:name="io.fabric.ApiKey"
android:value="RELEASE_KEY_1" tools:replace="android:value"/>
</application>
</manifest>
src/someOtherFlavorRelease/AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application>
<meta-data
android:name="io.fabric.ApiKey"
android:value="RELEASE_KEY_2" tools:replace="android:value"/>
</application>
</manifest>
The manifestMerger will handle the replacement and you will end up with the proper key in every scenario. I just implemented it successfully. I just hope you were really referring to the Fabric key! :)
Hope this helps!
I found this great solution in https://azabost.com/android-manifest-placeholders/
android {
...
buildTypes {
release {
...
manifestPlaceholders.screenOrientation = "portrait"
}
debug {...}
}
}
or
android {
...
flavorDimensions "features"
productFlavors {
paid {
dimension "features"
manifestPlaceholders.hostName = "www.paid-example.com"
}
free {
dimension "features"
manifestPlaceholders.hostName = "www.free-example.com"
}
}
Similarly to the accepted answer, you could do it with string resources, if you didn't want to duplicate your manifests.
For example, if you had two flavors (flavor1 and flavor2)
You'd end up w/ the following source sets.
app/
src/
main/
res/
values/strings.xml
flavor1Release/
res/
values/strings.xml
flavor1Debug/
res/
values/strings.xml
flavor2Release/
res/
values/strings.xml
flavor2Debug/
res/
values/strings.xml
You could then just use a string resource for your key value
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application>
<meta-data
android:name="io.fabric.ApiKey"
android:value="#string/apiKey" tools:replace="android:value"/>
</application>
</manifest>
One further optimization to keep all your keys in one place is to define them all in strings.xml in your main source set. and then have the flavor/build source sets reference those.
for example:
<resources>
<string name="flavor1ReleaseKey">flavor1ReleaseKey</string>
<string name="flavor1DebugKey">flavor1DebugKey</string>
<string name="flavor2ReleaseKey">flavor2ReleaseKey</string>
<string name="flavor2DebugKey">flavor2DebugKey</string>
</resources>
then in each of your flavor/build sourceSets, you just reference those keys.
flavor1Release/res/values/strings.xml
<resources>
<string name="apiKey">#string/flavor1ReleaseKey</string>
</resources>
I believe that you need a manifestPlaceHolder to read that value in your Java code, right? If this is the case, you can already read the FLAVOR name in your generated BuildConfig.java. For example, if you define a flavor whose name is smartphone you can access that value using BuildConfig.FLAVOR String; then in your code you can use a simple if (BuildConfig.FLAVOR.equals("smartphone"))...
But maybe you need to read a sort of configuration of your app, an apiKey. In that case, the best way to go is to create a Class or a string resource for every flavor; this is the link for you.
What i did is copied current AndroidManifest.xml into app/src/debug
and changed the key there debug Manifest :
<meta-data
android:name="com.crashlytics.ApiKey"
tools:replace="android:value"
android:value="#string/crashlytics_debug" />
app/src/main Manifest is like :
<meta-data
android:name="com.crashlytics.ApiKey"
android:value="#string/crashlytics_live" />
You don't need duplicate files
Build.gradle
productFlavors {
prod {
applicationId "com.example.prod"
dimension "mode"
manifestPlaceholders = [hostName:"some String"]
}
dev {
applicationId "com.example.dev"
dimension "mode"
manifestPlaceholders = [hostName:"some String"]
}
Manifiest use "${hostName}". Example below
<meta-data
android:name="com.google.android.geo.API_KEY"
android:value="${hostName}" />
As a complement to #Eric's post, for AGP version com.android.tools.build:gradle:4.x, this code snippet
applicationVariants.all{ variant->
if (variant.productFlavors.get(0).name.equals("someFlavor")) {
if (variant.buildType.name.equals("release")) {
manifestPlaceholders = [ apiKey:"RELEASE_KEY_1" ]
} else {
manifestPlaceholders = [ apiKey:"DEBUG_KEY" ]
}
} else {
if (variant.buildType.name.equals("release")) {
manifestPlaceholders = [ apiKey:"RELEASE_KEY_2" ]
} else {
manifestPlaceholders = [ apiKey:"DEBUG_KEY" ]
}
}
}
should be updated to
androidComponents {
onVariants(selector().withBuildType("debug")) {
manifestPlaceholders.apiKey = "DEBUG_KEY"
}
onVariants(selector().withBuildType("release")) {
if(flavorName.equals("someFlavor"))
manifestPlaceholders.apiKey = "RELEASE_KEY_1"
else
manifestPlaceholders.apiKey = "RELEASE_KEY_2"
}
}
Related
In my AndroidManifest.xml file I have the following line:
<supports-gl-texture android:name="${supportedTexture}" />
I inject the correct supported texture in gradle file based on the selected flavor, for example like this:
productFlavors {
ETC1 {
manifestPlaceholders = [supportedTexture: "GL_OES_compressed_ETC1_RGB8_texture"]
}
}
However, this doesn't work if I want to add several supports-gl-texture lines in the manifest. So how should I edit AndroidManifest.xml and build.gradle file if I'd like to have multiple supportedTextures like this:
<supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
<supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />
Would it be possible to do something like this in gradle file:
productFlavors {
ETC1 {
manifestPlaceholders = [supportedTexture: "GL_OES_compressed_ETC1_RGB8_texture"]
}
ETC1andATC {
//manifestPlaceHolders = ???
}
}
Or is my only option to go outside gradle and have for example multiple Manifest files which I copy to project depending on gradle flavor?
If you have limited numbers of supported textures then you can define multiple keys for all those textures and use in the manifest file.
productFlavors {
ETC1 {
manifestPlaceholders = [
supportedTexture1: "GL_OES_compressed_ETC1_RGB8_texture",
supportedTexture2: "GL_AMD_compressed_ATC_texture"]
}
}
Then in your manifest
<supports-gl-texture android:name="${supportedTexture1}" />
<supports-gl-texture android:name="${supportedTexture2}" />
I want to create a global variable similar with applicationId.
It is set value in build.gradle and will be used in manifest. Is it possible?
You can set them, for instance I'm setting it for different product flavors
productFlavors {
production {
applicationId = "com.myapp.app"
resValue "string", "authority", "com.facebook.app.FacebookContentProvider5435651423234"
}
development {
applicationId = "com.myapp.development"
resValue "string", "authority", "com.facebook.app.FacebookContentProvider2134564533421"
}
qa {
applicationId = "com.myapp.qa"
resValue "string", "authority", "com.facebook.app.FacebookContentProvider29831237981287319"
}
}
And use it like this
<provider
android:name="com.facebook.FacebookContentProvider"
android:authorities="#string/authority"
android:exported="true" />
If you just want to use the application id set in gradle in your manifest, you can simply use:
${applicationId}
For instance:
<provider
android:authorities="${applicationId}.ShareFileProvider" ... >
...
</provider>
If you want the same behavior with custom variables, you can use manifestPlaceholders, like this:
android {
defaultConfig {
manifestPlaceholders = [hostName:"www.example.com"]
}
}
And in your manifest:
<intent-filter ... >
<data android:scheme="http" android:host="${hostName}" ... />
...
</intent-filter>
See https://developer.android.com/studio/build/manifest-build-variables.html for more information.
While Marko's answer seems to work, there's currently a better solution that doesn't require adding variables to the string resource files.
The manifest merger accepts placeholders:
For custom placeholders replacements, use the following DSL to
configure the placeholders values :
android {
defaultConfig {
manifestPlaceholders = [ activityLabel:"defaultName"]
}
productFlavors {
free {
}
pro {
manifestPlaceholders = [ activityLabel:"proName" ]
}
}
will substitute the placeholder in the following declaration :
<activity android:name=".MainActivity" android:label="${activityLabel}" >
You can also manipulate those strings with groovy functions.
To use the string in Manifest, you can directly make it in strings.xml.
Like this,
<string name="variable_name">value</string>
Is it possible to access a BuildConfig value from AndroidManifest.xml?
In my build.gradle file, I have:
defaultConfig {
applicationId "com.compagny.product"
minSdkVersion 16
targetSdkVersion 21
versionCode 1
versionName "1.0"
// Facebook app id
buildConfigField "long", "FACEBOOK_APP_ID", FACEBOOK_APP_ID
}
FACEBOOK_APP_ID is defined in my gradle.properties files:
# Facebook identifier (app ID)
FACEBOOK_APP_ID=XXXXXXXXXX
To use Facebook connect in my app, I must add this line to my AndroidManifest.xml:
<meta-data android:name="com.facebook.sdk.ApplicationId" android:value="#string/applicationId"/>
I want to replace #string/applicationId by the BuildConfig field FACEBOOK_APP_ID defined in gradle, like this:
<meta-data android:name="com.facebook.sdk.ApplicationId" android:value="FACEBOOK_APP_ID"/>
Is that possible using BuildConfig? If not, how can I achieve this?
Replace
buildConfigField "long", "FACEBOOK_APP_ID", FACEBOOK_APP_ID
with
resValue "string", "FACEBOOK_APP_ID", FACEBOOK_APP_ID
then rebuild your project (Android Studio -> Build -> Rebuild Project).
The two commands both produce generated values - consisting of Java constants in the first case, and Android resources in the second - during project builds, but the second method will generate a string resource value that can be accessed using the #string/FACEBOOK_APP_ID syntax. This means it can be used in the manifest as well as in code.
Another way to access Gradle Build Config values from your AndroidManifest.xml is through placeholders like this:
android {
defaultConfig {
manifestPlaceholders = [ facebookAppId:"someId..."]
}
productFlavors {
flavor1 {
}
flavor2 {
manifestPlaceholders = [ facebookAppId:"anotherId..." ]
}
}
}
and then in your manifest:
<meta-data android:name="com.facebook.sdk.ApplicationId" android:value="${facebookAppId}"/>
See more details here: https://developer.android.com/studio/build/manifest-build-variables.html
(Old link just for reference: http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger)
note: when you use resValue the value can accidentally be overridden by the strings resource file (e.g. for another language)
To get a true constant value that you can use in the manifest and in java-code, use both manifestPlaceholders and buildConfigField: e.g.
android {
defaultConfig {
def addConstant = {constantName, constantValue ->
manifestPlaceholders += [ (constantName):constantValue]
buildConfigField "String", "${constantName}", "\"${constantValue}\""
}
addConstant("FACEBOOK_APP_ID", "xxxxx")
}
access in the manifest file:
<meta-data android:name="com.facebook.sdk.ApplicationId" android:value="${FACEBOOK_APP_ID}"/>
from java:
BuildConfig.FACEBOOK_APP_ID
If the constant value needs to be buildType-specific, the helper addConstant needs to be tweaked (to work with groovy closure semantics), e.g.,
buildTypes {
def addConstantTo = {target, constantName, constantValue ->
target.manifestPlaceholders += [ (constantName):constantValue]
target.buildConfigField "String", "${constantName}", "\"${constantValue}\""
}
debug {
addConstantTo(owner,"FACEBOOK_APP_ID", "xxxxx-debug")
}
release {
addConstantTo(owner,"FACEBOOK_APP_ID", "xxxxx-release")
}
Access build.gradle properties in your manifest as in following example:
For example you have a property "applicationId" in your build.gradle and you want to access that in your AndroidManifest:
Access "applicationId" in AndroidManifest:
<receiver
android:name="com.google.android.gms.gcm.GcmReceiver"
android:exported="true"
android:permission="com.google.android.c2dm.permission.SEND">
<intent-filter>
<action android:name="com.google.android.c2dm.intent.RECEIVE" />
<category android:name="${applicationId}" />
</intent-filter>
</receiver>
Similarly, we can create string resources for other constants and access them in code files as simple as:
context.getString(R.string.GCM_SENDER_ID);
#stkent is good but forgets to add that you need to rebuild your project afterwards
Replace
buildConfigField "long", "FACEBOOK_APP_ID", FACEBOOK_APP_ID
with
resValue "string", "FACEBOOK_APP_ID", FACEBOOK_APP_ID
then
Android Studio -> Build -> Rebuild Project
This will allow android generate the string resource accessible via
R.string.FACEBOOK_APP_ID
Another option: use a different string resource file to replace all Flavor-dependent values:
Step 1:
Create a new folder in the "src" folder with the name of your flavor, im my case "stage"
Step 2:
Create resource files for all files that are dependent on the flavor
for example:
Step 3:
I am also using different icons, so you see the mipmap folders as well. For this quetion, only the "strings.xml" is important. Now you can overwrite all important string resources. You only need to include the ones you want to override, all others will be used from the main "strings.xml", it will show up in Android Studio like this:
Step 4:
Use the string resources in your project and relax:
You can use long value as below
buildConfigField 'long', 'FLAVOR_LONG', '11500L'
I am trying to figure out a way to be able to change my application's app name per build type in gradle.
For instance, I would like the debug version to have <APP_NAME>-debug and the qa version to have <APP-NAME>-QA.
I am familiar with:
debug {
applicationIdSuffix '.debug'
versionNameSuffix '-DEBUG'
}
However, I can't seem to find a gradle command to apply the change of the app when in the launcher.
If by "app name", you mean android:label on <application>, the simplest solution is to have that point at a string resource (e.g., android:label="#string/app_name"), then have a different version of that string resource in a src/debug/ sourceset.
You can see that in this sample project, where I have a replacement for app_name in src/debug/res/values/strings.xml, which will be applied for debug builds. release builds will use the version of app_name in src/main/.
You can use something like this
buildTypes {
debug {
applicationIdSuffix '.debug'
versionNameSuffix '-DEBUG'
resValue "string", "app_name", "AppName debug"
}
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
zipAlignEnabled true
resValue "string", "app_name", "AppName"
}
}
You can use #string/app_name in AndroidManifest.xml files.
Make sure you remove app_name from values/ folder (no entry by this name).
You can do this with gradle:
android {
buildTypes {
release {
manifestPlaceholders = [appName: "My Standard App Name"]
}
debug {
manifestPlaceholders = [appName: "Debug"]
}
}
}
Then in your AndroidManifest.xml put:
<application
android:label="${appName}"/>
<activity
android:label="${appName}">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
Note: it also works with productFlavors.
To support translations make this:
1. remove string "app_name"
2. add to gradle
buildTypes {
admin {
resValue "string", "app_name", "#string/app_name_admin"
}
release {
resValue "string", "app_name", "#string/app_name_release"
}
debug {
resValue "string", "app_name", "#string/app_name_debug"
}
}
3. Set app name in Manifest as "#string/app_name"
4. Add to strings.xml values
<string name="app_name_admin">App Admin</string>
<string name="app_name_release">App release</string>
<string name="app_name_debug">App debug</string>
The app name is user-visible, and that's why Google encourages you to keep it in your strings.xml file. You can define a separate string resource file that contains strings that are specific to your buildTypes. It sounds like you might have a custom qa buildType. If that's not true, ignore the qa part below.
└── src
├── debug
│ └── res
│ └── buildtype_strings.xml
├── release
│ └── res
│ └── buildtype_strings.xml
└── qa
└── res
└── buildtype_strings.xml
We need a solution to support app name with localization (for multi language).
I have tested with #Nick Unuchek solution, but building is failed (not found #string/) . a little bit change to fix this bug:
build.gradle file:
android {
ext{
APP_NAME = "#string/app_name_default"
APP_NAME_DEV = "#string/app_name_dev"
}
productFlavors{
prod{
manifestPlaceholders = [ applicationLabel: APP_NAME]
}
dev{
manifestPlaceholders = [ applicationLabel: APP_NAME_DEV ]
}
}
values\strings.xml:
<resources>
<string name="app_name_default">AAA prod</string>
<string name="app_name_dev">AAA dev</string>
</resources>
values-en\strings.xml:
<resources>
<string name="app_name_default">AAA prod en</string>
<string name="app_name_dev">AAA dev en</string>
</resources>
Manifest.xml:
<application
android:label="${applicationLabel}" >
</application>
For a more dynamic gradle based solution (e.g. set a base Application name in main's strings.xml once, and avoid repeating yourself in each flavor / build type combination's strings.xml), see my answer here: https://stackoverflow.com/a/32220436/1128600
There are multiple ways you can do.
you can create manifestPlaceholders OR resValue in app level build.gradle. e.g.
buildTypes {
release {
...
manifestPlaceholders = [appLabel: "My App"]
//resValue "string", "appLabel", '"My App"'
}
debug {
...
manifestPlaceholders = [appLabel: "My App - Debug"]
//resValue "string", "appLabel", '"My App - Debug"'
}
}
OR
If you have productFlavors, you can create there
flavorDimensions "env"
productFlavors {
dev {
dimension "env"
...
manifestPlaceholders = [appLabel: "My App - Development"]
//resValue "string", "appLabel", '"My App - Development"'
}
prod {
dimension "env"
...
manifestPlaceholders = [appLabel: "My Awesome App"]
//resValue "string", "appLabel", '"My Awesome App"'
}
}
Then in AndroidManifest.xml if you are using manifestPlaceholders, just change android:label="${appLabel}" as below OR if you are using resValue, just change android:label=#string/appLabel
<application
...
android:label="${appLabel}"> //OR `android:label=#string/appLabel`
<activity
...
android:label="${appLable}">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
NOTE: Make sure to change android:lable as well in <activity> of LAUNCHER category. If it doesn't require to use android:label in <activity>, just remove this.
If you do not want to add in build.gradle directly, you can add in values/string.xml of selected ProductFlavors. e.g.
Add
<string name="appLabel">My App - Development</string>
in app/src/dev/res/values/string.xml
and
<string name="appLabel">My Awesome App</string>
in app/src/prod/res/values/string.xml
You can use strings.xml in different folders, see Android separate string values for release and debug builds.
So, create this file:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="app_name">Your app name</string>
</resources>
Then paste it to app\src\debug\res\values\ and app\src\release\res\values\ folders. Replace "Your app name" in debug and release files. Remove app_name item from strings.xml in app\src\main\res\values\ folder.
In AndroidManifest you will have the same
<application
android:label="#string/app_name"
...
No changes at all. Even if you added a library with it's AndroidManifest file and strings.xml.
As author asks to do this in Gradle, we can assume he want to do it in the script and not in the configuration files. Since both Android Studio and Gradle has been heavily updated and modified in the last year (~2018) all other answers above, seem overly contorted. The easy-peasy way, is to add the following to your app/build.gradle:
android {
...
buildTypes {
...
// Rename/Set default APK name prefix (app*.apk --> AwesomeApp*.apk)
android.applicationVariants.all { variant ->
variant.outputs.all { output ->
def appName = "AwesomeApp"
outputFileName = appName+"-${output.baseName}-${variant.versionName}.apk"
}
}
}
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://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Types
My build.gradle file looks like this:
...
android
{
...
buildTypes
{
debug
{
packageNameSuffix ".debug"
versionNameSuffix " debug"
}
}
}
Everything works fine until I start using a ContentProvider in my app. I get:
Failure [INSTALL_FAILED_CONFLICTING_PROVIDER]
I understand that this happens because two apps (release and debug) are registering same ContentProvider authority.
I see one possibility to solve this. If I understand correctly, you should be able to specify different files to use when building. Then I should be able to put different authorities in different resource files (and from Manifest set authority as string resource) and tell Gradle to use different resource for debug build. Is that possible? If yes then any hints on how to achieve that would be awesome!
Or maybe it's possible to directly modify Manifest using Gradle? Any other solution on how to run same app with ContentProvider on one device is always welcome.
None of existing answers satisfied me, however Liberty was close. So this is how am I doing it.
First of all at the moment I am working with:
Android Studio Beta 0.8.2
Gradle plugin 0.12.+
Gradle 1.12
My goal is to run Debug version along with Release version on the same device using the same ContentProvider.
In build.gradle of your app set suffix for Debug build:
buildTypes {
debug {
applicationIdSuffix ".debug"
}
}
In AndroidManifest.xml file set android:authorities property of your ContentProvider:
<provider
android:name="com.example.app.YourProvider"
android:authorities="${applicationId}.provider"
android:enabled="true"
android:exported="false" >
</provider>
In your code set AUTHORITY property that can be used wherever needed in your implementation:
public static final String AUTHORITY = BuildConfig.APPLICATION_ID + ".provider";
Tip: Before it was BuildConfig.PACKAGE_NAME
That's it! It will work like a charm. Keep reading if you use SyncAdapter!
Update for SyncAdapter (14.11.2014)
Once again I will start with my current setup:
Android Studio Beta 0.9.2
Gradle plugin 0.14.1
Gradle 2.1
Basically, if you need to customise some values for different builds you can do it from the build.gradle file:
use buildConfigField to access it from the BuildConfig.java class
use resValue to access it from resources e.g. #string/your_value
As an alternative for resources, you can create separate buildType or flavour directories and override XMLs or values within them. However, I am not going to use it in example below.
Example
In build.gradle file add the following:
defaultConfig {
resValue "string", "your_authorities", applicationId + '.provider'
resValue "string", "account_type", "your.syncadapter.type"
buildConfigField "String", "ACCOUNT_TYPE", '"your.syncadapter.type"'
}
buildTypes {
debug {
applicationIdSuffix ".debug"
resValue "string", "your_authorities", defaultConfig.applicationId + '.debug.provider'
resValue "string", "account_type", "your.syncadapter.type.debug"
buildConfigField "String", "ACCOUNT_TYPE", '"your.syncadapter.type.debug"'
}
}
You will see results in BuildConfig.java class
public static final String ACCOUNT_TYPE = "your.syncadapter.type.debug";
and in build/generated/res/generated/debug/values/generated.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
<!-- Automatically generated file. DO NOT MODIFY -->
<!-- Values from default config. -->
<item name="account_type" type="string">your.syncadapter.type.debug</item>
<item name="authorities" type="string">com.example.app.provider</item>
</resources>
In your authenticator.xml use resource specified in build.gradle file
<?xml version="1.0" encoding="utf-8"?>
<account-authenticator xmlns:android="http://schemas.android.com/apk/res/android"
android:accountType="#string/account_type"
android:icon="#drawable/ic_launcher"
android:smallIcon="#drawable/ic_launcher"
android:label="#string/app_name"
/>
In your syncadapter.xml use the same resource again and #string/authorities too
<?xml version="1.0" encoding="utf-8"?>
<sync-adapter xmlns:android="http://schemas.android.com/apk/res/android"
android:contentAuthority="#string/authorities"
android:accountType="#string/account_type"
android:userVisible="true"
android:supportsUploading="false"
android:allowParallelSyncs="false"
android:isAlwaysSyncable="true"
/>
Tip: autocompletion(Ctrl+Space) does not work for these generated resource so you have to type them manually
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
While Cyril's example works great if you only have a few build types, it quickly gets complicated if you have many build types and/or product flavors as you need to maintain lots of different AndroidManifest.xml's.
Our project consists of 3 different build types and 6 flavors totaling 18 build variants, so instead we added support for ".res-auto" in ContentProvider authorities, which expand to the current packagename and removes the need to maintain different AndroidManifest.xml
/**
* Version 1.1.
*
* Add support for installing multiple variants of the same app which have a
* content provider. Do this by overriding occurrences of ".res-auto" in
* android:authorities with the current package name (which should be unique)
*
* V1.0 : Initial version
* V1.1 : Support for ".res-auto" in strings added,
* eg. use "<string name="auth">.res-auto.path.to.provider</string>"
*
*/
def overrideProviderAuthority(buildVariant) {
def flavor = buildVariant.productFlavors.get(0).name
def buildType = buildVariant.buildType.name
def pathToManifest = "${buildDir}/manifests/${flavor}/${buildType}/AndroidManifest.xml"
def ns = new groovy.xml.Namespace("http://schemas.android.com/apk/res/android", "android")
def xml = new XmlParser().parse(pathToManifest)
def variantPackageName = xml.#package
// Update all content providers
xml.application.provider.each { provider ->
def newAuthorities = provider.attribute(ns.authorities).replaceAll('.res-auto', variantPackageName)
provider.attributes().put(ns.authorities, newAuthorities)
}
// Save modified AndroidManifest back into build dir
saveXML(pathToManifest, xml)
// Also make sure that all strings with ".res-auto" are expanded automagically
def pathToValues = "${buildDir}/res/all/${flavor}/${buildType}/values/values.xml"
xml = new XmlParser().parse(pathToValues)
xml.findAll{it.name() == 'string'}.each{item ->
if (!item.value().isEmpty() && item.value()[0].startsWith(".res-auto")) {
item.value()[0] = item.value()[0].replace(".res-auto", variantPackageName)
}
}
saveXML(pathToValues, xml)
}
def saveXML(pathToFile, xml) {
def writer = new FileWriter(pathToFile)
def printer = new XmlNodePrinter(new PrintWriter(writer))
printer.preserveWhitespace = true
printer.print(xml)
}
// Post processing of AndroidManifest.xml for supporting provider authorities
// across build variants.
android.applicationVariants.all { variant ->
variant.processManifest.doLast {
overrideProviderAuthority(variant)
}
}
Example code can be found here: https://gist.github.com/cmelchior/6988275
Since the plugin version 0.8.3 (actually 0.8.1 but it wasn't working properly) you can define resources within the build file so this could be a cleaner solution because you don't need to create strings files nor additional debug/release folders.
build.gradle
android {
buildTypes {
debug{
resValue "string", "authority", "com.yourpackage.debug.provider"
}
release {
resValue "string", "authority", "com.yourpackage.provider"
}
}
}
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.yourpackage"
android:versionCode="1"
android:versionName="1">
<application>
<provider
android:name=".provider.Provider1"
android:authorities="#string/authority"
android:exported="false" />
</application>
</manifest>
I don't know if anybody mention it. Actually after android gradle plugin 0.10+, the manifest merger will provide the official support for this function:
http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger
In AndroidManifest.xml, you can use ${packageName} like this:
<provider
android:name=".provider.DatabasesProvider"
android:authorities="${packageName}.databasesprovider"
android:exported="true"
android:multiprocess="true" />
And in your build.gradle you can have:
productFlavors {
free {
packageName "org.pkg1"
}
pro {
packageName "org.pkg2"
}
}
See full example here:
https://code.google.com/p/anymemo/source/browse/AndroidManifest.xml#152
and here:
https://code.google.com/p/anymemo/source/browse/build.gradle#41
Use ${applicationId} placeholders in xml and BuildConfig.APPLICATION_ID in code.
You will need to extend the build script to enable placeholders in xml files other than the manifest. You could use a source directory per build variant to provide different versions of the xml files but maintenance will become cumbersome very quickly.
AndroidManifest.xml
You can use the applicationId placeholder out of the box in the manifest. Declare your provider like this:
<provider
android:name=".provider.DatabaseProvider"
android:authorities="${applicationId}.DatabaseProvider"
android:exported="false" />
Note the ${applicationId} bit. This is replaced at build time with the actual applicationId for the build variant that is being built.
In code
Your ContentProvider needs to construct the authority string in code. It can use the BuildConfig class.
public class DatabaseContract {
/** The authority for the database provider */
public static final String AUTHORITY = BuildConfig.APPLICATION_ID + ".DatabaseProvider";
// ...
}
Note the BuildConfig.APPLICATION_ID bit. It is a generated class with the actual applicationId for the build variant being built.
res/xml/ files, e.g. syncadapter.xml, accountauthenticator.xml
If you want to use a Sync Adapter you will need to provide meta-data for the ContentProvider and AccountManager in xml files in the res/xml/ directory. The applicationId placeholder is not supported here. But you can extend the build script yourself to hack it in.
<sync-adapter xmlns:android="http://schemas.android.com/apk/res/android"
android:accountType="${applicationId}"
android:allowParallelSyncs="false"
android:contentAuthority="${applicationId}.DatabaseProvider"
android:isAlwaysSyncable="true"
android:supportsUploading="true"
android:userVisible="true" />
<account-authenticator xmlns:android="http://schemas.android.com/apk/res/android"
android:accountType="${applicationId}"
android:icon="#drawable/ic_launcher"
android:label="#string/account_authenticator_label"
android:smallIcon="#drawable/ic_launcher" />
Again, note the ${applicationId}. This only works if you add the below gradle script to the root of your module and apply it from build.gradle.
build.gradle
Apply the extra build script from the module build.gradle script. A good place is below the Android gradle plugin.
apply plugin: 'com.android.application'
apply from: './build-processApplicationId.gradle'
android {
compileSdkVersion 21
// etc.
build-processApplicationId.gradle
Below is working source for a res/xml/ placeholder build script. A better documented version is available on github. Improvements and extensions are welcome.
def replace(File file, String target, String replacement) {
def result = false;
def reader = new FileReader(file)
def lines = reader.readLines()
reader.close()
def writer = new FileWriter(file)
lines.each { line ->
String replacedLine = line.replace(target, replacement)
writer.write(replacedLine)
writer.write("\n")
result = result || !replacedLine.equals(line)
}
writer.close()
return result
}
def processXmlFile(File file, String applicationId) {
if (replace(file, "\${applicationId}", applicationId)) {
logger.info("Processed \${applicationId} in $file")
}
}
def processXmlDir(File dir, String applicationId) {
dir.list().each { entry ->
File file = new File(dir, entry)
if (file.isFile()) {
processXmlFile(file, applicationId)
}
}
}
android.applicationVariants.all { variant ->
variant.mergeResources.doLast {
def applicationId = variant.mergedFlavor.applicationId + (variant.buildType.applicationIdSuffix == null ? "" : variant.buildType.applicationIdSuffix)
def path = "${buildDir}/intermediates/res/${variant.dirName}/xml/"
processXmlDir(new File(path), applicationId)
}
}
Strings.xml
In my opinion there is no need to add placeholder support for resource strings. For the above use case at least it is not needed. However you could easily change the script to not only replace placeholders in the res/xml/ directory, but also in the res/values/ directory.
I would rather prefer a mixture between Cyril and rciovati. I think is more simplier, you only have two modifications.
The build.gradle looks like:
android {
...
productFlavors {
production {
packageName "package.name.production"
resValue "string", "authority", "package.name.production.provider"
buildConfigField "String", "AUTHORITY", "package.name.production.provider"
}
testing {
packageName "package.name.debug"
resValue "string", "authority", "package.name.debug.provider"
buildConfigField "String", "AUTHORITY", "package.name.debug.provider"
}
}
...
}
And the AndroidManifest.xml:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="package.name" >
<application
...>
<provider android:name=".contentprovider.Provider" android:authorities="#string/authority" />
</application>
</manifest>
gradle.build
android {
compileSdkVersion 23
buildToolsVersion "23.0.1"
defaultConfig {
applicationId "com.example.awsomeapp"
minSdkVersion 9
targetSdkVersion 23
versionCode 1
versionName "1.0.0"
}
productFlavors
{
prod {
applicationId = "com.example.awsomeapp"
}
demo {
applicationId = "com.example.awsomeapp.demo"
versionName = defaultConfig.versionName + ".DEMO"
}
}
buildTypes {
release {
signingConfig signingConfigs.release
debuggable false
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
}
debug {
applicationIdSuffix ".debug"
versionNameSuffix = ".DEBUG"
debuggable true
}
}
applicationVariants.all { variant ->
variant.outputs.each { output ->
// rename the apk
def file = output.outputFile;
def newName;
newName = file.name.replace(".apk", "-" + defaultConfig.versionName + ".apk");
newName = newName.replace(project.name, "awsomeapp");
output.outputFile = new File(file.parent, newName);
}
//Generate values Content Authority and Account Type used in Sync Adapter, Content Provider, Authenticator
def valueAccountType = applicationId + '.account'
def valueContentAuthority = applicationId + '.authority'
//generate fields in Resource string file generated.xml
resValue "string", "content_authority", valueContentAuthority
resValue "string", "account_type", valueAccountType
//generate fields in BuildConfig class
buildConfigField "String", "ACCOUNT_TYPE", '"'+valueAccountType+'"'
buildConfigField "String", "CONTENT_AUTHORITY", '"'+valueContentAuthority+'"'
//replace field ${valueContentAuthority} in AndroidManifest.xml
mergedFlavor.manifestPlaceholders = [ valueContentAuthority: valueContentAuthority ]
}
}
authenticator.xml
<?xml version="1.0" encoding="utf-8"?>
<account-authenticator xmlns:android="http://schemas.android.com/apk/res/android"
android:accountType="#string/account_type"
android:icon="#drawable/ic_launcher"
android:label="#string/app_name"
android:smallIcon="#drawable/ic_launcher" />
sync_adapter.xml
<?xml version="1.0" encoding="utf-8"?>
<sync-adapter xmlns:android="http://schemas.android.com/apk/res/android"
android:contentAuthority="#string/content_authority"
android:accountType="#string/account_type"
android:userVisible="true"
android:allowParallelSyncs="false"
android:isAlwaysSyncable="true"
android:supportsUploading="true"/>
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0.0" package="com.example.awsomeapp">
<uses-permission android:name="android.permission.GET_ACCOUNTS"/><!-- SyncAdapter and GCM requires a Google account. -->
<uses-permission android:name="android.permission.AUTHENTICATE_ACCOUNTS"/>
<uses-permission android:name="android.permission.USE_CREDENTIALS"/>
<!-- GCM Creates a custom permission so only this app can receive its messages. -->
<permission android:name="${applicationId}.permission.C2D_MESSAGE" android:protectionLevel="signature"/>
<uses-permission android:name="${applicationId}.permission.C2D_MESSAGE"/>
<application....
.......
<!-- Stub Authenticator -->
<service
android:name="com.example.awsomeapp.service.authenticator.CAuthenticatorService"
android:exported="true">
<intent-filter>
<action android:name="android.accounts.AccountAuthenticator"/>
</intent-filter>
<meta-data android:name="android.accounts.AccountAuthenticator" android:resource="#xml/authenticator"/>
</service>
<!-- -->
<!-- Sync Adapter -->
<service
android:name="com.example.awsomeapp.service.sync.CSyncService"
android:exported="true"
android:process=":sync">
<intent-filter>
<action android:name="android.content.SyncAdapter"/>
</intent-filter>
<meta-data android:name="android.content.SyncAdapter" android:resource="#xml/sync_adapter" />
</service>
<!-- -->
<!-- Content Provider -->
<provider android:authorities="${valueContentAuthority}"
android:exported="false"
android:name="com.example.awsomeapp.database.contentprovider.CProvider">
</provider>
<!-- -->
</application>
</manifest>
Code:
public static final String CONTENT_AUTHORITY = BuildConfig.CONTENT_AUTHORITY;
public static final String ACCOUNT_TYPE = BuildConfig.ACCOUNT_TYPE;
Based on the sample by #ChristianMelchior, here's my solution, which fixes two issues in the previous solutions:
solutions that change values.xml in the build directory cause a full rebuild of resources (including aapt of all drawables)
for an unknown reason, IntelliJ (and probably Android Studio) do not reliably process the resources, causing the build to contain un-replaced .res-auto provider authorities
This new solution does things more the Gradle way by creating a new task and allows for incremental builds by defining input and output files.
create a file (in the example I put it in a variants directory), formatted like a resource xml file, which contains string resources. These will be merged into the app's resources, and any occurrence of .res-auto in the values will be replaced with the variant's package name, for example <string name="search_provider">.res-auto.MySearchProvider</string>
add the build_extras.gradle file from this gist to your project and reference it from the main build.gradle by adding apply from: './build_extras.gradle' somewhere above the android block
make sure you set a default package name by adding it to the android.defaultConfig block of build.gradle
in AndroidManifest.xml and other configuration files (such as xml/searchable.xml for auto-completion search providers), reference the provider (for example #string/search_provider)
if you need to get the same name, you can use the BuildConfig.PACKAGE_NAME variable, for example BuildConfig.PACKAGE_NAME + ".MySearchProvider"
https://gist.github.com/paour/9189462
Update: this method only works on Android 2.2.1 and later. For earlier platforms, see this answer, which has its own set of problems, since the new manifest merger is still very rough around the edges…
I've written a blogpost with Github sample project that tackles this problem (and other similar problems) in a slightly different way than Cyril's.
http://brad-android.blogspot.com/2013/08/android-gradle-building-unique-build.html
Unfortunately, the current version (0.4.1) of the android plugin doesn't seem to provide a good solution for this. I haven't had time to try this yet, but a possible workaround for this problem would be to use a string resource #string/provider_authority, and use that in the manifest: android:authority="#string/provider_authority". You then have a res/values/provider.xml in the res folder of each build type that should override the authority, in your case this would be src/debug/res
I've looked into generating the xml file on the fly, but again, there doesn't seem to be any good hooks for it in the current version of the plugin. I'd recommend putting in a feature request though, I can imagine more people will run into this same issue.
The answer in this post works for me.
http://www.kevinrschultz.com/blog/2014/03/23/using-android-content-providers-with-multiple-package-names/
I use 3 different flavours so I create 3 manifest with content provider in each flavour as kevinrschultz said:
productFlavors {
free {
packageName "your.package.name.free"
}
paid {
packageName "your.package.name.paid"
}
other {
packageName "your.package.name.other"
}
}
Your main Manifest not include providers:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" >
<!-- Permissions -->
<application>
<!-- Nothing about Content Providers at all -->
<!-- Activities -->
...
<!-- Services -->
...
</application>
And your manifest in your each flavour including provider.
Free:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" >
<application>
<!-- Content Providers -->
<provider
android:name="your.package.name.Provider"
android:authorities="your.package.name.free"
android:exported="false" >
</provider>
</application>
</manifest>
Paid:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" >
<application>
<!-- Content Providers -->
<provider
android:name="your.package.name.Provider"
android:authorities="your.package.name.paid"
android:exported="false" >
</provider>
</application>
</manifest>
Other:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" >
<application>
<!-- Content Providers -->
<provider
android:name="your.package.name.Provider"
android:authorities="your.package.name.other"
android:exported="false" >
</provider>
</application>
</manifest>
Why not just add this?
type.packageNameSuffix = ".$type.name"
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.