If I set a property in my gradle.properties file using the command line like so:
gradle build -Dproperty=myString
and in my Android project have a configuration.properties in my resources directory, how can I get configuration.properties to read the new property from the gradle.properties file?
I've tried the following setup:
gradle.properties
property=defaultString
anotherProperty=defaultBoolean
configuration.properties
myProperty=#property#
POTENTIAL SOLUTION 1
Using a configuration.properties file for each flavor.
The per-flavor resources sounded like a great idea, but I wanted to have a default list in main, and only override the properties needed. I have a lot of properties, and some flavors would only need to override one. So this does work, but is not ideal.
POTENTIAL SOLUTION 2
Using buildConfigField to pass what I need to the Java code.
The problem here is that I have two modules: app and api - where api is a dependency of app. Setting a buildConfigField in the app build.gradle lets me access them in the app code, but I would also need to access it from the api module.
To vary property values per flavor, you can use per-flavor resource files. For more information, check the Android Gradle plugin docs.
PS: If the property values are only used to activate different parts of the codebase, consider using per-flavor code instead.
Related
Short question:
How can I change the package name for debug or release build type in a library module?
Context:
In an Android project with MVP + Clean architecture, we have the repository pattern in a library module. We want to include Firebase on that library with two environments (development and production).
I already created the project in Firebase (com.example.com and com.example.com.dev) and then downloaded the respective google-services.json to src/main and src/debug folders.
Gradle google-services plugin validates the module package name with the client ID defined in the google-services.json, but Android restrict to change the applicationId in a library (I can't find the technical reason why)
Things that I tried:
Have two AndroidManifest.xml with different package property. com.example.com in the src/main and com.example.com.dev in src/debug/ but the second one it is just ignored
Set manifest.srcFile in Gradle sourceSets. The file is in the list when I run ./gradlew sourceSets but the package name doesn't change
Two different flavors in the library module and set different manifests for each one. The package anyway doesn't change.
At this moment I have just two suitable solutions:
1. Keep the Firebase setup and implementation in the app module outside of the repository.
2. Have only one environment for Firebase.
Thanks a lot for any help or advice.
EDIT:
Consider that I need to modify the package in a module (library), not in the app. For some weird reason Gradle shows this error when I try to use applicationIdSuffix or applicationId in a module:
ERROR: Library projects cannot set applicationIdSuffix.
Library projects cannot set applicationId.
This is the designed behaviour of Android Library project.
Two different flavors in the library module and set different
manifests for each one. The package anyway doesn't change.
Probably you need to change your Build Variants to that particular flavor/buildtype then you can see the updated package name taking effect.
See below screenshot.
I spent some time investigating and trying different alternatives to achieve two different package name per flavor or build type in a library module, and my short answer is: You can't, at least without doing something tricky and dirty.
Some guys that recommend using the parameter applicationIdSuffix or applicationId, that option doesn't work because of the design of library modules restricts those parameters to the app module. In a library, the package must be defined in the manifest.
That restriction delimits options to flavors, but, the package attribute in the manifest isn't merged, and you get an error when having different package name for the scr/main/AndroidManifest.xml and src/flavor/AndroidManifest.xml.
A tricky solution is to get the currently selected flavor form the task name and then change the main manifest in the sourceSets.
sourceSets {
main {
manifest.srcFile "src/$flavor_name/AndroidManifest.xml"
}
}
This hack works but in general is a bad idea, and I prefer to change the design of my architecture and implement the repository for both Firebase variants in a different way.
Gradle plugin: 3.2.0
I have an app with more than a few buildFlavors and three different buildTypes.
I generate the signed apks from Build -> Generate Signed APK.... (Unless there is no other go I'd like to continue using the wizard and not create a script, because i have a constantly increasing set of apps and do not want to modify the script every time.)
The generated apks are named in the following pattern:
app-flavorName-buildType.apk
How can i change the naming pattern to something like this:
app_flavorName_buildType_versionCode.apk
Changes I want to make:
Suffix file name with versionCode
Replace hyphens with underscores
I used to do it in ant using task, but not sure how to do it with gradle.
Trying to figure a solution to create the name straight away in the new pattern rather than trying to rename it once it is generated. Is that possible?
I tried looking under Settings -> Gradle but did not find anything. Any other place i should be looking?
It is not exactly what you are looking for.
You can use your build.gradle to set this attribute:
android {
//...
defaultConfig {
//...
project.ext.set("archivesBaseName", "app_"+ defaultConfig.versionCode);
}
}
Assigning the archivesBaseName you will obtain something like:
app_0.9.6-flavorName-buildType.apk
This attribute requires the gradle-plugin 1.3.1 or higher.
Otherwise you have to use a task to rename the apk after building.
Is it possible to use a Gradle Rule (Or more than a single one) to replace values in resources?
I'm aware that this is something that flavors would do well but I need to have lots of values that must be changed as a build configuration and i though that Gradle rules would solve this issue.
You cannot modify the contents of resources readily through anything currently in Gradle for Android.
You can use product flavors or build types to replace resources by means of having the replacement resources in the appropriate sourceset (e.g., in src/debug/ for the debug build type).
You are also welcome to attempt to write a Gradle plugin or otherwise create a Gradle task that you insert into the build sequence that modifies some intermediates copy of the resources and ensures that this copy is what is included in the actual build.
I have an old maven project which I'm trying to migrate over to gradle for practice. It uses a configurations.properties file to configure different apks. For example, I would use it set a boolean for the target marketplace, and would do this from the command line like so:
mvn install -DexampleFlag=true
There are a few of these flags, and they are used at various points throughout the app. Is there a way to create this file using gradle?
Or, of course, if you have a better solution I'd be happy to hear that too.
EDIT
Okay, so I've got flavors, and I'm adding values to fields in the generated BuildConfig class like so:
android {
flavor1 {
buildConfigField 'boolean', 'EXAMPLE_FLAG', 'true'
}
}
And that works for the main app subproject. However, I also have an api subproject which needs to be able to access the flags too - which it can't, as the app subproject is the one with the flavors. If it helps, the api subproject is a dependency of app.
Any help here is appreciated.
Usually, this wouldn't be managed using flags but by defining multiple application flavors. For more information on flavors, see the Android Gradle plugin docs.
I am using android studio 0.45 with gradle build to build my project. (gradle version 1.9). In my test folder I creating an extra activity that I don't want to be part of my release code. Where do I specify this activity in the Android Manifest. The gradle setup only allows for one AndroidManifest file as far as I can tell.
I am also using extra permissions in the test project to simulate phone calls that I don't need in my release code. How do I setup the manifest file so as to add permissions on a build specific mechanism...
It sounds like you should set up a product flavor for your test type, that includes the extra activity, and extra permissions in your AndroidManifest file. A flavor lets you have source files that are specific only to that flavor, and properties in the manifest that get merged together with the main manifest at build time.
Read the docs at http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors and give it a shot.