Some customers want a custom APK, with their own logo and other build-time customizations.
In order to do keep these customizations private, we do not store customer-specific customizations in this repository.
We support fetching a "customization" directory from another git repository during build time.
In order to fetch from this repository, the following values must be set as environment variables or
in the local.properties file during Gradle configuration:
| Variable | Description |
|---|---|
| CUSTOM_REPOSITORY | URL to the Git repository that contains all customizations |
| GRGIT_USER | Git credentials: username for checking out the repository |
| GRGIT_PASSWORD | Git credentials: password for checking out the repository |
| CUSTOM_FOLDER | Name/path of the "customization root" directory. Represented below as "customizationRoot", but it can be whatever. |
| CLIENT_FOLDER | Name of the custom build directory within the "CUSTOM_FOLDER" |
Note
This CUSTOM_FOLDER and CLIENT_FOLDER were made to keep compatibility with the old Android app. It would make more sense to combine them in a single variable with the full path to the custom build. If someone is looking into refactoring stuff, this is one I'd change at some point.
When customizing a build, it is expected that a directory with the following structure exists:
-customizationRoot/
|-myCustomBuildA/
|-custom-reloaded.json
|-resources/
|-[optional - custom resources to overwrite src/res]
Everything in the default.json file can be
overwritten by the values in the custom-reloaded.json.
Both files must have the same exact format, and the custom-reloaded.json will have the
final say in which value will be bundled with the application.
Consider that the same property ("app_name") is defined in all possible places (i.e. both in
default and custom-reloaded files, and both within a flavor and for all flavors).
default.json:
{
"flavors": {
"prod": {
"app_name": "Wire - Prod Flavor"
}
},
"app_name": "Wire"
}custom-reloaded.json
{
"flavors": {
"prod": {
"app_name": "My Custom App - Prod Flavor"
}
},
"app_name": "My Custom App"
}When building the prod flavor, the value will be chosen based on the following priority order (
highest priority first):
| Priority | Value | Explanation |
|---|---|---|
| 1 - Highest | My Custom App - Prod Flavor | Custom build and specific flavor |
| 2 | My Custom App | Custom build |
| 3 | Wire - Prod Flavor | Specific flavor |
| 4 - Lowest | Wire | Generic |
These files will overwrite the Android Resources present in src/prod/res (or any other flavor).
During build time, these files will be copied into src/prod/res, src/beta/res, src/dev/res,
etc.
and will overwrite files in case of conflict.
This means that unlike the build flags and values, it is not possible to overwrite resources from a specific flavor. This use case was never needed, but it could be adapted for it.
Because of Resource Merging, this can be used to overwrite specific strings and other resources. For example, consider the following structure:
-app/src/main/
|-res/
|-mipmap/
| |-file1.png (picture of a cat)
|-values/
| |-all-strings.xml
-app/src/prod/
|-res/
|-mipmap/
| |-file1.png (picture of a monkey)
-custom/
|-resources/
|-mipmap/
| |-file1.png (picture of a dog)
|-values/
| |-custom-string-replacements.xml
Without the customization, the app would have a picture of a monkey as file1.png when building the
prod flavor, and a picture of a cat for the other flavors.
With the customization, the file1.png will be overwritten with the picture of a dog for all
flavors.
Consider that the all-strings.xml file contains two strings:
<resources>
<string name="buildType">Wire</string>
<string name="color">Red</string>
</resources>Consider that the custom-string-replacements.xml contains one string:
<resources>
<string name="buildType">Customized!</string>
</resources>Without Customization: the app displays "Wire" for the buildType string.
With Customization: the app displays "Customized!" for the buildType.
Again, thanks
to Resource Merging,
the color string doesn't need to be overwritten. Because the custom-string-replacements file
will be copied into the prod directory, the buildType will be chosen based on
the flavor over the generic one put in main.
Take a look into the customization files within buildSrc for more details on how it works.