Gradle gives the ability to set some manifest attributes pretty simply like:
targetSdkVersion and minSdkVersion
Is there any way to add the android:testOnly application attribute with gradle without touching the manifest by hand
https://developer.android.com/guide/topics/manifest/application-element.html#testOnly
You can create a custom resource value with Gradle. E.g. in your app module's build.gradle under android -> defaultConfig
resValue("bool", "test_only", "true")
And then in your AndroidManifest.xml
android:testOnly="#bool/test_only"
E.g. you can set this to different values for different flavors
Related
We have multiple projects, depending on a many Android lib modules.
To avoid duplicated xml tags in the apps manifests, we put the relevant receivers, services and activities in their respective modules.
Till today, we used:
Android Studio: 2.2.1
gradle: 2.1.3
buildToolsVersion: 23.0.3
Today we've updated to:
Android Studio: 2.3
gradle: 2.3.0
buildToolsVersion: 25.0.0
Up until this update, everything worked just fine and the manifests were merged, we had conflicts and we fixed them. As of the update we've done, the manifests will not merge, at all!!
--- Update 1 ---
We've used the Merged Manifest view, and saw that it just doesn't include the manifests in the merge, the only thing it does merge from the modules manifest is the permissions, so for example, if I add a new permission to a modules manifest it would ONLY merge it and not the rest of the elements!
I guarantee there are a lot of stuff to merge!
--- Update 2 ---
It seems that everything outside the application tag it merges into the main manifest, and everything within the application tag, it doesn't.
--- Update 3 ---
Module that doesn't merge:
Gradle:
apply plugin: 'com.android.library'
android {
compileSdkVersion 23
buildToolsVersion '25.0.0'
defaultConfig {
minSdkVersion 16
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
jniDebuggable true
}
}
}
dependencies {
compile project(path: ':android-infra')
compile 'com.google.android.gms:play-services-gcm:9.0.0'
compile project(path: ':engine-core-server')
compile project(path: ':engine-core-aneeda')
}
Manifest:
<manifest package="com.sensiya.voip.managers.gcm"
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<uses-permission android:name="com.google.android.c2dm.permission.KAKI"/>
<application
tools:node="replace">
<service
android:enabled="true"
android:name="com.sensiya.voip.managers.gcm.GcmIntentService"/>
<receiver android:name="com.sensiya.voip.managers.gcm.GcmBroadcastReceiver"
android:permission="com.google.android.c2dm.permission.SEND">
<intent-filter>
<action android:name="com.google.android.c2dm.intent.RECEIVE"/>
<category android:name="com.iamplus.onenumber.device"/>
</intent-filter>
</receiver>
</application>
</manifest>
Module that will merge:
Gradle:
apply plugin: 'com.android.library'
android {
compileSdkVersion 23
buildToolsVersion '25.0.0'
defaultConfig {
minSdkVersion 16
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
jniDebuggable true
}
}
}
dependencies {
compile project(path: ':android-infra')
compile 'com.sensiya:sense-services-client:1.24.2#aar'
compile project(path: ':engine-core-server')
compile project(path: ':engine-core-aneeda')
}
Manifest:
<manifest package="com.iamplus.android.senseServices"
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application
tools:node="replace">
<service
android:name="com.iamplus.senseServices.ContextualEventService"
android:enabled="true"/>
<service
android:name="com.iamplus.senseServices.Serv"
android:enabled="true"/>
<service
android:name="com.iamplus.senseServices.Serv1"
android:enabled="true"/>
</application>
</manifest>
Any suggestions?
It could be many things.Since you didn't provide code, I will guess you are using default merge behavior. For more information, see: Merge conflict heuristics
You can use Merged Manifest view to preview the results of your merged manifest and find conflict errors.
In general, merge by default should work. Then just use Merged Manifest view to see how & where you lost values during merging. Using Merge rule markers would help you to manage merge by assigning rules markers.
If there is no merge at all. so it's probably a dependency issue between modules.
Note that dependency order plays a crucial role with modules which have the same priority level, such as libraries.
--- Update 5.April.2017 ---
Here are some useful tips:
Try to update and rebuild other libs as much as you can.
Remove all dependencies and then clean project, then add them again. and
check if you import them properly. that could be done by build the project without issues.
Note that since gradle 2.2.0 assets from modules won't be accessible
in app.
Check you manifest if merge process is not disabled exciplicitly by attribute:
tools:node=”remove" or tools:node="removeAll" or in gradle( see
this Disable Manifest Merger in Android Gradle Build)
Try to create a demo with a module and track merging. and then match
outputs to your projects. This will make it clear that is not
configuration issue but Android Studio 2.3 ( so then re-install fresh
version )
--- Update(2) 5.April.2017 ---
After you had added code, I could see that you are using Attribute
tools:node="replace"
Under application element in your modules (and probably in app's manifest too). I think that is the reason why you didn't get any manifest merged from imported modules merged to your app's manifest. See tools:node="replace" under Node markers.
Replace the lower-priority element completely. That is, if there is a
matching element in the lower-priority manifest, ignore it and use
this element exactly as it appears in this manifest.
That means both modules above will never get any thing merged with manifest from:
android-infra
com.sensiya:sense-services-client:1.24.2
engine-core-server
engine-core-aneeda
So get rid of that attribute and clean and rebuild modules. then rebuild whole project.
If you are getting manifest merge conflicts you have two options.
1) find all the manifest files included in your project including the ones in libraries that you have as dependencies, and ensure there are no conflicting configurations.
or 2) add some merge resolution rules to your Manifests to dictate how each conflict should be resolved.
There is a great page on that here with many details.
https://developer.android.com/studio/build/manifest-merge.html
From Android Studio
Build ---> Clean project
then
Build --> Make Project
This should help fix
I had a similar problem for Unity. I was able to solve it by going on the SDK Manager and removing the latest android api. Then I installed a slightly older api and it worked (API 21 or 22 I think)
What the SDK Manager looks like
I recently have same problem in my production code.
Having one libraries into app module exists also in other Gradle Dependency causes the duplicate entries.
We need to exclude such module or libraries from conflicted one.
For that we must know number of libraries used by a particular Gadle dependency.
Consider a case where I using "bolts-android-1.2.0.jar" in my app gradle.
In same gradle I m using facebookSDK as below.
compile('com.facebook.android:facebook-android-sdk:4.5.0')
So I have to exclude "bolts-android" as below
compile('com.facebook.android:facebook-android-sdk:4.5.0') {
exclude module: 'bolts-android'
}
So how to know that facebookSDK uses "bolts-android"
Here you can use plugin Android Method Count
Seems like the problem is from using tools:node="replace" in the application element. From the documentation:
...if there is a matching element in the lower-priority manifest, ignore it and use this element exactly as it appears in this manifest.
What you actually want to use is tools:node="merge" which is the default behavior.
Merge all attributes in this tag and all nested elements when there are no conflicts using the merge conflict heuristics. This is the default behavior for elements.
I just discovered something weird about Android studio: it has some configuration options in the build.gradle file that override what is specified in the AndroidManifest.xml file.
For instance, I had the following lines in build.gradle:
android {
compileSdkVersion 18
buildToolsVersion "18.1.1"
defaultConfig {
minSdkVersion 10
targetSdkVersion 10
}
...
}
which was overriding the corresponding tag in AndroidManifest.xml:
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="8"/>
I don't really like to have the same settings spread in two different files, so I am wondering if I can safely remove it either from build.gradle or AndroidManifest.xml and where it makes more sense to keep it.
Gradle overrides the manifest values, and I prefer to update the build.gradle file rather than the manifest. Probably this is the right way using Gradle. Gradle supports product flavours which can be controlled via an IDE and those product flavors can change many things in our Manifest like package name, version code, version name, target SDK and many other. Then by one click in Android Studio you can change many properties and generate another apk.
You can leave the manifest as it is and do all configuration in build.gradle. You can safely remove
<uses-sdk></uses-sdk>
from manifest as well as version codes.
From the Android docs:
Note: If your app defines the app version directly in the element, the version values in the Gradle build file will override the settings in the manifest. Additionally, defining these settings in the Gradle build files allows you to specify different values for different versions of your app. For greater flexibility and to avoid potential overwriting when the manifest is merged, you should remove these attributes from the element and define your version settings in the Gradle build files instead.
https://developer.android.com/studio/publish/versioning.html#appversioning
Existing system (Maven)
I have an Android project which has two modules: app and api.
Currently, I use Maven to build it, and I have a configuration.properties in the app resources directory which has properties in it such as exampleProperty=${property}
I use the command line for my various builds like so mvn clean install -Dproperty=customString, and this swaps out the correct property so that it is exampleProperty=customString.
This property is read from by both app and api modules - and works fine.
New system (Gradle)
The Question: Can I use defaultConfig to set a property in my configuration.properties file?
I'm trying to use the defaultConfig (and eventually productFlavors) to create a setup where the build.gradle swaps out the properties instead of using the command line.
I've tried a number of ways to make changes to the gradle.properties file from the defaultConfig closure in the build.gradle file like so:
android {
compileSdkVersion 19
buildToolsVersion "19.0.0"
defaultConfig {
applicationId "com.example.editconfigproperties"
minSdkVersion 9
targetSdkVersion 19
versionCode 1
versionName "1.0"
System.setProperty('exampleProperty', 'customString')
project.properties['exampleProperty']='customString'
extensions.add('exampleProperty', 'customString')
ext.exampleProperty = 'customString' // This one seems to work
}
}
I think the last one adds it to the gradle.properties file, but I can't figure out how to make the configuration.properties file read from it (or if that's even possible). I tried setting exampleProperty=#exampleProperty# in the `configuration.properties' file, but to no avail.
I just imported build.grade file of the facebook module in android studio and it contain below code:
defaultConfig {
minSdkVersion Integer.parseInt(project.ANDROID_BUILD_MIN_SDK_VERSION)
targetSdkVersion Integer.parseInt(project.ANDROID_BUILD_TARGET_SDK_VERSION)
}
My question is Which file does 'project' point to ?
In the root of your project you should have a gradle.properties file. In there you should see (or can set yourself) these attributes.
ANDROID_BUILD_MIN_SDK_VERSION=19
ANDROID_BUILD_TARGET_SDK_VERSION=19
If you need to use a version number like 19.0.2 instead of 19, you need to quote the value.
ANDROID_BUILD_MIN_SDK_VERSION="19.0.2"
ANDROID_BUILD_TARGET_SDK_VERSION="19.0.2"
I just discovered something weird about Android studio: it has some configuration options in the build.gradle file that override what is specified in the AndroidManifest.xml file.
For instance, I had the following lines in build.gradle:
android {
compileSdkVersion 18
buildToolsVersion "18.1.1"
defaultConfig {
minSdkVersion 10
targetSdkVersion 10
}
...
}
which was overriding the corresponding tag in AndroidManifest.xml:
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="8"/>
I don't really like to have the same settings spread in two different files, so I am wondering if I can safely remove it either from build.gradle or AndroidManifest.xml and where it makes more sense to keep it.
Gradle overrides the manifest values, and I prefer to update the build.gradle file rather than the manifest. Probably this is the right way using Gradle. Gradle supports product flavours which can be controlled via an IDE and those product flavors can change many things in our Manifest like package name, version code, version name, target SDK and many other. Then by one click in Android Studio you can change many properties and generate another apk.
You can leave the manifest as it is and do all configuration in build.gradle. You can safely remove
<uses-sdk></uses-sdk>
from manifest as well as version codes.
From the Android docs:
Note: If your app defines the app version directly in the element, the version values in the Gradle build file will override the settings in the manifest. Additionally, defining these settings in the Gradle build files allows you to specify different values for different versions of your app. For greater flexibility and to avoid potential overwriting when the manifest is merged, you should remove these attributes from the element and define your version settings in the Gradle build files instead.
https://developer.android.com/studio/publish/versioning.html#appversioning