Wikimedia Apps/Team/Android/Release process

This page documents the technical release process for the Android team. The release engineer should remain cognizant of the detailed non-technical steps when creating and releasing to both beta and production.

Alpha releases[edit]

Alpha APKs are built automatically by GitHub Actions. Simply download the APK from the "latest" release, which is updated with every merged pull request: https://github.com/wikimedia/apps-android-wikipedia/releases/tag/latest

Beta releases[edit]

Announce on the Slack #android channel that a new beta build is in progress and that any merging should be paused until it's done.

Prepare your workspace. Ideally you should checkout a fresh copy of the repo into an empty directory, to avoid any unintended artifacts from Android Studio, gradle, etc.

git clone git@github.com:wikimedia/apps-android-wikipedia.git
cd apps-android-wikipedia

# Checkout submodule for Image Recommendation assets if needed.
# git submodule update --init --recursive

Increment the patch version code. Consider updating the minor number. Please notice that you may need to create the bumpVersionCode branch before running the script.
```
scripts/bump-version-code.py
```
Create a Pull Request for it, and merge it.

For cherry-pickin' hotfix releases:

git checkout [tag of previous production release]
git cherry-pick ...
git cherry-pick ...
git cherry-pick ...
git cherry-pick [version-bump patch]

Start the release notes Etherpad cooking. Here are some helpful commands to look through the commit history, while filtering out uninteresting commits:

git log --pretty=format:"%h | %cr | %s" --abbrev-commit --no-merges `git tag --list beta/* | tail -1`.. | grep -Ev 'Hygiene:|Localisation updates from https://translatewiki.net.'

echo 'Volunteer contributor patches:'
git log --pretty=format:"%h | %an | %cr | %s" --abbrev-commit --no-merges `git tag --list beta/* | tail -1`..|grep -Evi 'Dmitry Brant|Sharvani Haran|Cooltey Feng|Translation updater bot'

Confirm the version-bump patch has merged, and update your local repo with it.
Perform the actual build of the beta, production, and partner flavors.
```
./build-all.sh
```
When the script finishes, all of the built APKs and AABs will be placed in the /releases directory. You'll notice that each flavor of the build has a universal APK and a corresponding AAB, which an app "bundle". When distributing the APK manually (whether for a partner, user testing, etc.) always use the universal build. The AAB bundles are intended only for uploading to the Google Play Store.
Load the built APK onto the device and install/run it and see if everything functions as expected, as a sanity check. For bonus points, try it with a Kindle Fire device. For super bonus points, on one of the devices enable the "Don't keep activities" developer option, and make sure nothing breaks.
Do some light manual testing, including search, saved pages, reading lists, talk page, watchlist, history, beta-only and prod-only features, light/dark/black themes, upgrade from a previous version, and new features and churn areas identified when generating release notes.
In the Google Play Store console, create a new Production release for the Wikipedia Beta app with 100% rollout. Upload the built AAB file to it, and use the release notes from the Etherpad. In the Publishing overview page, please make sure to click the button to send the change for review in order to complete the publishing process.
Create and push a new Beta tag:
```
scripts/make-release.py --beta --push
```

Upload the built APKs to releases.wikimedia.org.

./upload-all.sh

This will make the APKs available in these locations:

Stable:
https://releases.wikimedia.org/mobile/android/wikipedia/stable/

Beta:
https://releases.wikimedia.org/mobile/android/wikipedia/betas/

Send a note to QA and/or TSG to start regression testing.
Create a ticket for the regression test and move it to the QA column.
If the released feature requires data QA, follow the data QA document and provide a dev-release version apk, link to the schema-doc and stream url for the feature.

Production releases[edit]

When ready to release to production:

Checkout the latest Beta tag, and push a new Prod tag:

scripts/make-release.py --prod --push

Follow these steps to release to all the respective app stores:

Google Play Store[edit]

Go to the Google Play Store console and create a new Production release of the stable app (not Beta).
Drag in the latest AAB file (app bundle), not the APK, and make sure to "retain" the old APK that's compatible with API 19.
Roll it out to 100%. (Optionally perform a staged rollout, i.e. less than 100% to begin, then ratchet up to 100% when completely ready.)

Amazon app store[edit]

Go to the "App list" in the Amazon developer console and select our app.
Select "Add Upcoming Version" from the menu on the left.
Click on the "APK files" tab, then scroll to the bottom and click "Edit".
Inside the "Existing APK" box, click the "Replace APK" link and drag in the latest -amazon- APK.
Verify that the "Ver Code" stated in the "Uploaded APKs" box corresponds to the latest version.
Scroll to the bottom and click "Save".
Click on the "Description" tab, then scroll to the bottom and click "Edit".
Enter the latest release notes in the "Release notes" field. Copy the notes over to the other language tabs. (It's OK if all the notes are in English.)
Scroll to the bottom and click "Save".
Click the "Submit App" button

Samsung app store[edit]

Log on to the Galaxy Store, using the shared credentials in 1Password.
Select our app in the console.
Click the red "Update" button.
In the left menu, click "Binary", then click "Add more binary".
For "Resolution(s)", select "Check all".
For "Google Mobile Service", select "No".
Before uploading, rename the -samsung- APK so that it doesn't contain any period . characters. Just remove the major and minor version number, and leave the version code in the name.
Click "Upload" and select the latest -samsung- APK, then click "Save".
Back in the "Binary" screen, remove the previous APK by clicking the "X" button next to the old binary.
Verify that only the most recent binary (with the latest version code) is remaining.
In the left menu, click "Publication".
Under "Start Publication" select "Publish Automatically", then click "Save" at the bottom.
Scroll to the top, and click the red "Submit" button, and click "Yes" to confirm.

Huawei app store[edit]

Log on to the Huawei AppGallery, using personal WMF email to log in. Otherwise, using the shared credentials in 1Password.
Click the "Console" link near the top-right, then click "AppGallery Connect", then click "My Apps".
Click the "Update" link next to our app in the list.
Click the "Upgrade" button near the top-right.
Leave the "Country/Region for release" as it is (make sure "Chinese mainland" is not selected).
Scroll down to "App version" and click "Manage app packages".
Click the "Upload" button, and drag in the latest -huawei- APK.
Verify that the "Released package" now has the latest version code in it.
Click the "Submit" button at the top right, and click "OK" to confirm.

F-Droid[edit]

The F-Droid build system automatically detects new -r- production tags that we push to the repository, and creates their own builds based on these tags. There should not be any additional steps from our end.

Post-release[edit]

Rejoice.
After the updated app has propagated through the Play Store (i.e. after a few hours), send an email to mobile-l@ (cc android@), if there were significant updates that were worth evangelizing.
Go to team board and close tickets in Ready for release
Monitor for any new crashes in AppCenter. When looking at crashes, make sure to filter them by the specific latest version of the app. And make sure to sort them by the number of users impacted, to get a sense of which issues are the most widespread.
Monitor for any new crashes in the Play Store console. These are much less likely than crashes in HockeyApp, since these crashes would imply a system-level crash before the app even loads. Nevertheless, they are possible and should be checked.