If I don't create a src/android/AndroidManifest.xml file in my Gluon project, then the mvn gluonfx:package command creates one for me with some relatively sensible defaults. However, I need to make some changes to the generated AndroidManifest.xml for my app (such as indicating support for multiple screen resolutions, and I need to add the BILLING permission).
If I copy the generated AndroidManifest.xml to src/android/AndroidManifest.xml as suggested during gluonfx:package, then Gluon no longer updates the version code and version name fields for me. I'm also not sure if there any any other side-effects to manually editing the AndroidManifest.xml file.
So my questions are:
- What's the best practice when it comes to managing AndroidManifest.xml for a Gluon project?
- How do folks deal with updating the version code and version name in a manually edited file as part of a CI/CD pipeline, where I don't want to have to manually edit AndroidManifest.xml for each build?
- Are there any pitfalls to managing the AndroidManifest.xml outside the gluonfx:package command?
CodePudding user response:
As documented here, you should use <releaseConfiguration/>
to define the values that are required or need to be updated for each new release.
For Android, besides the keystore signing properties, you can also define:
- version code
- version name
- app label
like:
<plugin>
<groupId>com.gluonhq</groupId>
<artifactId>gluonfx-maven-plugin</artifactId>
<version>${gluonfx.maven.plugin.version}</version>
<configuration>
<target>${gluonfx.target}</target>
<releaseConfiguration>
<versionCode>2</versionCode>
<versionName>3.0</versionName>
<appLabel>MyHelloFX</appLabel>
</releaseConfiguration>
...
So in case you need to add the AndroidManifest to src/Android
(the one that was generated in target/gluonfx/aarch64-android/gensrc/android/AndroidManifest.xml
), in order to add/modify part of it, it will be always updated for those three values, whenever you change them in the pom.
About CI/CD, have a look at the HelloGluon CI sample.
It doesn't have a custom manifest, but it shows how to deal with ReleaseConfiguration
and updating release values in a CI environment.
The pom defines some properties that are used by the releaseConfiguration block:
<properties>
...
<main.class>com.gluonhq.hello.HelloGluonApp</main.class>
<app.identifier>${main.class}</app.identifier>
<app.description>The HelloGluon app</app.description>
<version.code/>
<provided.keystore.path/>
</properties>
...
<plugin>
<groupId>com.gluonhq</groupId>
<artifactId>gluonfx-maven-plugin</artifactId>
<version>${gluonfx.maven.plugin.version}</version>
<configuration>
...
<releaseConfiguration>
<vendor>Gluon</vendor>
<description>${app.description}</description>
<packageType>${package.type}</packageType>
<!-- for macOS/iOS -->
<macAppStore>${mac.app.store}</macAppStore>
<bundleShortVersion>${bundle.short.version}</bundleShortVersion>
<bundleVersion>${bundle.version}</bundleVersion>
<!-- for Android -->
<versionCode>${version.code}</versionCode>
<providedKeyStorePath>${provided.keystore.path}</providedKeyStorePath>
...
These properties are ultimately defined for each profile:
<profile>
<id>android</id>
<properties>
<gluonfx.target>android</gluonfx.target>
<app.identifier>com.gluonhq.samples.hellogluon</app.identifier>
<version.code>${env.GITHUB_RUN_NUMBER}</version.code>
...
When running the Android job, the required variables and secrets are used:
- name: Gluon Build
run: mvn -Pandroid gluonfx:build gluonfx:package
env:
GLUON_ANDROID_KEYSTOREPATH: ${{ steps.android_keystore_file.outputs.filePath }}
...