1

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:

  1. What's the best practice when it comes to managing AndroidManifest.xml for a Gluon project?
  2. 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?
  3. Are there any pitfalls to managing the AndroidManifest.xml outside the gluonfx:package command?
José Pereda
  • 44,311
  • 7
  • 104
  • 132
Tim Gustafson
  • 177
  • 1
  • 11

1 Answers1

2

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 }}
...
José Pereda
  • 44,311
  • 7
  • 104
  • 132
  • Just to clarify: you're saying if I create a src/android/AndroidManifest.xml file as a copy of target/gluonfx/aarch64-android/gensrc/android/AndroidManifest.xml, the mvn:gluonfx:package command will update the appropriate values in src/main/android/AndroidManifest.xml? – Tim Gustafson Feb 28 '22 at 14:06
  • 1
    Yes, but only for these three I mentioned (in case you are interested, this is done in [Substrate](https://github.com/gluonhq/substrate/blob/master/src/main/java/com/gluonhq/substrate/target/AndroidTargetConfiguration.java#L555)). – José Pereda Feb 28 '22 at 14:09
  • I note that the code you linked to in Substrate is using string replacement rather than loading the document into a DOM and making changes that way. This broke for me because I was using double quotes (") instead of single quotets (') in my AndroidManifest.xml. It might be a nice improvement to change that code to use proper DOM parsing instead of string replacement. – Tim Gustafson Feb 28 '22 at 15:00
  • It is actually using [javax.xml.parsers.DocumentBuilder](https://github.com/gluonhq/substrate/blob/master/src/main/java/com/gluonhq/substrate/util/FileOps.java#L429) for it. In any case, can you file an issue [here](https://github.com/gluonhq/substrate/issues)? – José Pereda Feb 28 '22 at 15:04
  • Done: https://github.com/gluonhq/substrate/issues/1124 – Tim Gustafson Feb 28 '22 at 15:21