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
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
 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.  Increment the patch version code. Consider updating the minor number. Please notice that you may need to create the  branch before running the script.  Push the version increment patch.

 Create a Pull Request for it, and merge it. For cherry-pickin' hotfix releases:  Start the release notes Etherpad cooking. Here are some helpful commands to look through the commit history, while filtering out uninteresting commits:  Confirm the version-bump patch has merged, and update your local repo with it.</li> Perform the actual build of the beta, production, and partner flavors. When the script finishes, all of the built APKs and AABs will be placed in the  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. </li> 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.</li> Do some light manual testing, including search, saved pages, reading lists, history, nearby, 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.</li> 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.</li> Push the tags. </li> Upload the built APKs to releases.wikimedia.org. This will make the APKs available in these locations: </li> Optionally end email to, cc  , and bcc volunteer contributors. Don't forget to call out volunteers!</li> Send a note to QA and/or TSG to start regression testing.</li> </ol>

Production releases
When ready to release to production, follow these steps to release to all the respective app stores:

Google Play Store

 * 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

 * 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  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

 * 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  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  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.

Create a new release of the app in the Samsung app store. (use shared credentials in 1Password) Create a new release of the app in the Huawei app store. (use shared credentials in 1Password) After the updated app has propagated through the Play Store (i.e. after a few hours), send an email to, cc  , and bcc volunteer contributors. Don't forget to call out volunteers!

Post-release
<ol> Rejoice.</li> 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.</li> 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.</li> </ol>