Changes in cffe004: updated Android mobile apps build/promote instructions in Wiki

				wiki/info/landscape/building-and-deploying.md
			
          @@ -91,7 +91,7 @@ When working with Hyperspace to prepare the creation of the actual Azure Pipelin

           The pipeline configuration is produced as a [Github pull request](https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/pull/1) for the Git repository used for Hyperspace onboarding. In particular, it contains a "Fastlane" configuration under ``fastlane/Fastfile`` and the actual pipeline configuration in ``azure-pipelines/mail.yml``. The fastlane config in ``fastlane/Fastfile`` we could slighly adjust and simplify because we only build ``.apk`` files, no ``.aab`` libraries. Furthermore, we need adjustments for the location of the ``gradle.properties`` file into which a git-based technical version identifier shall be generated during the build process. Later more on the details of this.

          -In the ``azure-pipelines/main.yml`` file under the ``trigger:`` property we configure which Git branches and/or tags shall trigger a pipeline execution. The core part then is defined by a reference to the pipeline's template, and specific adjustments can then be made to the template pipeline in the ``extends:`` section. The ``isRelease`` boolean property controls whether the build shall be a release build that triggers code signing, in particular. The ``productiveBranchName`` property controls for buils of which branch all scanning and test tasks shall be performed. We required special adjustments of the ``jdkVersion`` property to ``11`` and the ``androidVersion`` to ``33`` for our Gradle app build to work. Furthermore, the MoMa Assembly ID must be configured in the ``momaAssemblyId`` property. Each app folder now has its own ``files2sign.json`` file in its app folder under ``mobile/`` because this allows us to limit the build output to files under the app's own folder.

          +In the ``azure-pipelines/main.yml`` file under the ``trigger:`` property we configure which Git branches and/or tags shall trigger a pipeline execution. The core part then is defined by a reference to the pipeline's template, and specific adjustments can then be made to the template pipeline in the ``extends:`` section. The ``isRelease`` boolean property controls whether the build shall be a release build that triggers code signing, in particular. The ``productiveBranchName`` property controls for buils of which branch all scanning and test tasks shall be performed. We required special adjustments of the ``jdkVersion`` property to ``17`` and the ``androidVersion`` to ``35`` for our Gradle app build to work. Furthermore, the MoMa Assembly ID must be configured in the ``momaAssemblyId`` property. Each app folder now has its own ``files2sign.json`` file in its app folder under ``mobile/`` because this allows us to limit the build output to files under the app's own folder.

           Since we want to build and release two apps out of one Git repo and ideally with one pipeline, we work with Git branches, one per app that we want to release, as follows:

          @@ -123,7 +123,7 @@ Our points of contact for the Hyperspace / Azure Pipeline migration are Marc Bor

           ### Running a Build / Release / Promote Cycle

          -To release the apps, go to the MoMa records of the two apps ([https://moma.mo.sap.corp/#/apps/124](https://moma.mo.sap.corp/#/apps/124) and [https://moma.mo.sap.corp/#/apps/123](https://moma.mo.sap.corp/#/apps/123)) and from there into the Assembly-Data and press the "Add Release" button. Make sure the "Build System" is set to "free - Hyperspace Azure Pipelines". Then run the ``configuration/releaseAndroidApps.sh`` script, like this:

          +To release the apps, go to the MoMa records of the two apps ([https://moma.mo.sap.corp/#/apps/124](https://moma.mo.sap.corp/#/apps/124) and [https://moma.mo.sap.corp/#/apps/123](https://moma.mo.sap.corp/#/apps/123)) and from there into the Assembly-Data and press the "Add Release" button. Make sure the "Build System" is set to "free - Hyperspace Azure Pipelines". Make sure you set the "Is this build to be uploaded to Google Play Store (after manual approval)?" field to "Yes - directly to Google Play (General Availability)" in case you have tested you apps already and are sure they can be uploaded to the public store. Otherwise, select "Yes - but to Google Closed Track first (with option for GA afterwards)" which will upload to the Google Closed Track store first, so you can test the apps once more prior to publication. In this case you'll have to resume or reject the "Manual Validation" step (GP Prod Deploy?) after your tests. Then run the ``configuration/releaseAndroidApps.sh`` script, like this:

           ```

                   ./configuration/releaseAndroidApps.sh

          @@ -139,6 +139,8 @@ Additional options:

           It starts with checking out the ``hyperspace`` branch, then increments the minor version number by one in all relevant files, in particular the ``files2sign.json`` files and the ``gradle.properties`` files in the app directories. It then commits these changes to the ``hyperspace`` branch and checks out each release branch one after another, merges the ``hyperspace`` branch with the version number updates and all other functional changes into the release branch and pushes it. This triggers the release build pipeline execution including code signing in Azure DevOps. The pipeline executions including their logs can be observed [here](https://dev.azure.com/hyperspace-mobile/SAP-Sailing-Analytics/_build?definitionId=496).

          -When the release pipelines ran successfully, they will have updated the MoMa assembly metadata for the respective apps, including the version numbers and the staging repositories used. Furthermore, a "Build Release Pipeline Project Link" is generated, such as [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/) for the SAP Sailing Buoy Pinger app, and [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/) for the SAP Sailing Race Manager app. Before using these pipelines, go to the MoMa Google Play Metadata section for each app you'd like to release and click on "Add Release" there, too. You will have to make a few adjustments to some fields, such as that you're only releasing a "Patch" with specific release notes which you then have to submit to naming@sap.com for approval before you can send them to LXLabs using the respective button on the Google Play Metadata page in MoMa.

          +When the release pipelines ran successfully, they will have updated the MoMa assembly metadata for the respective apps, including the version numbers and the staging repositories used.

          -Only once you have all approvals in place, use the "Build Release Pipeline Project Link" for the app you'd like to release and run a build there. Note that these builds have interactive steps that pause and ask you to confirm the promotion to the Play Store. Your released app(s) should then show in the Google Play Store after a few hours.

          \ No newline at end of file

          +(In previous pipeline versions, a "Build Release Pipeline Project Link" was generated, such as [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/) for the SAP Sailing Buoy Pinger app, and [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/) for the SAP Sailing Race Manager app. Before using these pipelines, we would go to the MoMa Google Play Metadata section for each app you'd like to release and click on "Add Release" there, too. You will have to make a few adjustments to some fields, such as that you're only releasing a "Patch" with specific release notes which you then have to submit to naming@sap.com for approval before you can send them to LXLabs using the respective button on the Google Play Metadata page in MoMa. Only once you have all approvals in place, use the "Build Release Pipeline Project Link" for the app you'd like to release and run a build there. Note that these builds have interactive steps that pause and ask you to confirm the promotion to the Play Store. Your released app(s) should then show in the Google Play Store after a few hours.)

          +

          +Now (2026-01-23) the "NAAS Promote" step in the Azure build pipeline will upload the readily-built apps to the Google Play store (supposedly after a human-in-the-loop confirmation). We haven't completed this process yet because we are currently still in the transition. NAAS, however, 

          \ No newline at end of file

...	...	@@ -91,7 +91,7 @@ When working with Hyperspace to prepare the creation of the actual Azure Pipelin
91	91
92	92	The pipeline configuration is produced as a [Github pull request](https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/pull/1) for the Git repository used for Hyperspace onboarding. In particular, it contains a "Fastlane" configuration under ``fastlane/Fastfile`` and the actual pipeline configuration in ``azure-pipelines/mail.yml``. The fastlane config in ``fastlane/Fastfile`` we could slighly adjust and simplify because we only build ``.apk`` files, no ``.aab`` libraries. Furthermore, we need adjustments for the location of the ``gradle.properties`` file into which a git-based technical version identifier shall be generated during the build process. Later more on the details of this.
93	93
94		-In the ``azure-pipelines/main.yml`` file under the ``trigger:`` property we configure which Git branches and/or tags shall trigger a pipeline execution. The core part then is defined by a reference to the pipeline's template, and specific adjustments can then be made to the template pipeline in the ``extends:`` section. The ``isRelease`` boolean property controls whether the build shall be a release build that triggers code signing, in particular. The ``productiveBranchName`` property controls for buils of which branch all scanning and test tasks shall be performed. We required special adjustments of the ``jdkVersion`` property to ``11`` and the ``androidVersion`` to ``33`` for our Gradle app build to work. Furthermore, the MoMa Assembly ID must be configured in the ``momaAssemblyId`` property. Each app folder now has its own ``files2sign.json`` file in its app folder under ``mobile/`` because this allows us to limit the build output to files under the app's own folder.
	94	+In the ``azure-pipelines/main.yml`` file under the ``trigger:`` property we configure which Git branches and/or tags shall trigger a pipeline execution. The core part then is defined by a reference to the pipeline's template, and specific adjustments can then be made to the template pipeline in the ``extends:`` section. The ``isRelease`` boolean property controls whether the build shall be a release build that triggers code signing, in particular. The ``productiveBranchName`` property controls for buils of which branch all scanning and test tasks shall be performed. We required special adjustments of the ``jdkVersion`` property to ``17`` and the ``androidVersion`` to ``35`` for our Gradle app build to work. Furthermore, the MoMa Assembly ID must be configured in the ``momaAssemblyId`` property. Each app folder now has its own ``files2sign.json`` file in its app folder under ``mobile/`` because this allows us to limit the build output to files under the app's own folder.
95	95
96	96	Since we want to build and release two apps out of one Git repo and ideally with one pipeline, we work with Git branches, one per app that we want to release, as follows:
97	97
...	...	@@ -123,7 +123,7 @@ Our points of contact for the Hyperspace / Azure Pipeline migration are Marc Bor
123	123
124	124	### Running a Build / Release / Promote Cycle
125	125
126		-To release the apps, go to the MoMa records of the two apps ([https://moma.mo.sap.corp/#/apps/124](https://moma.mo.sap.corp/#/apps/124) and [https://moma.mo.sap.corp/#/apps/123](https://moma.mo.sap.corp/#/apps/123)) and from there into the Assembly-Data and press the "Add Release" button. Make sure the "Build System" is set to "free - Hyperspace Azure Pipelines". Then run the ``configuration/releaseAndroidApps.sh`` script, like this:
	126	+To release the apps, go to the MoMa records of the two apps ([https://moma.mo.sap.corp/#/apps/124](https://moma.mo.sap.corp/#/apps/124) and [https://moma.mo.sap.corp/#/apps/123](https://moma.mo.sap.corp/#/apps/123)) and from there into the Assembly-Data and press the "Add Release" button. Make sure the "Build System" is set to "free - Hyperspace Azure Pipelines". Make sure you set the "Is this build to be uploaded to Google Play Store (after manual approval)?" field to "Yes - directly to Google Play (General Availability)" in case you have tested you apps already and are sure they can be uploaded to the public store. Otherwise, select "Yes - but to Google Closed Track first (with option for GA afterwards)" which will upload to the Google Closed Track store first, so you can test the apps once more prior to publication. In this case you'll have to resume or reject the "Manual Validation" step (GP Prod Deploy?) after your tests. Then run the ``configuration/releaseAndroidApps.sh`` script, like this:
127	127
128	128	```
129	129	./configuration/releaseAndroidApps.sh
...	...	@@ -139,6 +139,8 @@ Additional options:
139	139
140	140	It starts with checking out the ``hyperspace`` branch, then increments the minor version number by one in all relevant files, in particular the ``files2sign.json`` files and the ``gradle.properties`` files in the app directories. It then commits these changes to the ``hyperspace`` branch and checks out each release branch one after another, merges the ``hyperspace`` branch with the version number updates and all other functional changes into the release branch and pushes it. This triggers the release build pipeline execution including code signing in Azure DevOps. The pipeline executions including their logs can be observed [here](https://dev.azure.com/hyperspace-mobile/SAP-Sailing-Analytics/_build?definitionId=496).
141	141
142		-When the release pipelines ran successfully, they will have updated the MoMa assembly metadata for the respective apps, including the version numbers and the staging repositories used. Furthermore, a "Build Release Pipeline Project Link" is generated, such as [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/) for the SAP Sailing Buoy Pinger app, and [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/) for the SAP Sailing Race Manager app. Before using these pipelines, go to the MoMa Google Play Metadata section for each app you'd like to release and click on "Add Release" there, too. You will have to make a few adjustments to some fields, such as that you're only releasing a "Patch" with specific release notes which you then have to submit to naming@sap.com for approval before you can send them to LXLabs using the respective button on the Google Play Metadata page in MoMa.
	142	+When the release pipelines ran successfully, they will have updated the MoMa assembly metadata for the respective apps, including the version numbers and the staging repositories used.
143	143
144		-Only once you have all approvals in place, use the "Build Release Pipeline Project Link" for the app you'd like to release and run a build there. Note that these builds have interactive steps that pause and ask you to confirm the promotion to the Play Store. Your released app(s) should then show in the Google Play Store after a few hours.
...	...	\ No newline at end of file
	0	+(In previous pipeline versions, a "Build Release Pipeline Project Link" was generated, such as [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.android.buoy.positioning.app-android/) for the SAP Sailing Buoy Pinger app, and [https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/](https://gkemobilepipelines.jaas-gcp.cloud.sap.corp/job/NAAS%20-%20Mobile%20Freestyle/job/com.sap.sailing.racecommittee.app-android/) for the SAP Sailing Race Manager app. Before using these pipelines, we would go to the MoMa Google Play Metadata section for each app you'd like to release and click on "Add Release" there, too. You will have to make a few adjustments to some fields, such as that you're only releasing a "Patch" with specific release notes which you then have to submit to naming@sap.com for approval before you can send them to LXLabs using the respective button on the Google Play Metadata page in MoMa. Only once you have all approvals in place, use the "Build Release Pipeline Project Link" for the app you'd like to release and run a build there. Note that these builds have interactive steps that pause and ask you to confirm the promotion to the Play Store. Your released app(s) should then show in the Google Play Store after a few hours.)
	1	+
	2	+Now (2026-01-23) the "NAAS Promote" step in the Azure build pipeline will upload the readily-built apps to the Google Play store (supposedly after a human-in-the-loop confirmation). We haven't completed this process yet because we are currently still in the transition. NAAS, however,
...	...	\ No newline at end of file