Wikimedia Apps/Team/Android/Release process

This page documents the release process for the Android team.

Alpha releases
Alpha APKs are built automatically after patches get merged to master every 15 minutes and are available at android-builds.wmflabs.org.

Technical information
$ ssh android-builder.mobile.eqiad.wmflabs $ sudo -s $ sudo -u android-build /bin/bash $ cd /srv/builds
 * Web server backend login:
 * Gerrit repository that contains the web page that serves the Alpha download link, and the shell script that copies the latest Alpha from the CI server to the web server. After committing a change to this repo, log on to the android-builder server, and do a git pull on.

Beta releases
 Announce on 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. (Or wherever you keep the all-apks.sh file.) This script is confidential because some partners wish to maintain anonymity. However, it looks something like this: When the script finishes, all of the built APKs will be placed in the  directory. You'll notice that each flavor of the build has five APKs associated with it, one for each platform that we support: When distributing the APK manually (whether for a partner, user testing, etc.) always use the universal build. The non-universal builds 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 on an API 19 device. For extra 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> To install the APK programmatically onto multiple connected devices: </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> Go to the Google Play Store console, and create a new Alpha release for the Wikipedia app with 100% rollout. Upload the four platform-specific (non-universal)  APKs to it, and use the release notes from the Etherpad.</li> Also in the Play Store console, create a new Production release for the Wikipedia Beta app with 100% rollout. Upload the four platform-specific (non-universal)  APKs to it, and use the release notes from the Etherpad.</li> Push the tags. </li> Upload the built APKs to releases.wikimedia.org. </li>  Upload the APKs to Google Drive (i.e. into a new folder accessible by QA and TSG). Sending apk URLs to QA and TSG </li> Review the Alpha pre-launch test results in the Play Store console. </li> Create a new "Upcoming" version of the app in the Amazon Appstore and upload the -amazon- universal APK to it.</li> Add the release to Mobile/Release_history under the Android section's "Release notes".</li> Optionally end email to, cc  , and bcc volunteer contributors. Don't forget to call out volunteers!</li> Send email to QA and/or TSG to start regression testing.</li> </ol>
 * arm64-v8a - used in most modern higher-end devices.
 * armeabi-v7a - used in older and lower-end devices.
 * x86 - used in some older and lower-end tablets.
 * x86_64 - used in some newer and higher-end tablets.
 * universal - combination of all above platforms, but much larger APK size.

Production releases
Production releases are simply promotions from Beta by the product owner. <ol> Go to the Google Play Store console and promote the current Alpha release to Production. (Optionally perform a staged rollout, i.e. less than 100% to begin, then ratchet up to 100% when completely ready.)</li> Go to the Amazon Appstore and hit the Submit button to submit the current "upcoming" version of the app for review and deployment.</li> <li>Send email to, cc  , and bcc volunteer contributors. Don't forget to call out volunteers!</li> </ol>

Post-release
<ol> <li>Rejoice</li> <li>Monitor for any new crashes in HockeyApp. Remember: since we have APKs for four different platforms, there are four different version codes organized by 10xxx, 20xxx, 30xxx, and 40xxx, with "xxx" being the actual versionCode of the APK. You should check all four of these in HockeyApp, although 10xxx and 20xxx should be the most important since these are the most widely used (armv7a and armv8a).</li> <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> <li>Monitor the ANR rate in the Play Store, as well as the other performance metrics that the console provides. This can expose performance bottlenecks or UI slowdowns which should be investigated.</li> </ol>