Android releases
How a change to the Android app travels from a merged pull request to internal testers, the beta, and production, and how to build a signed release yourself.
Every merged pull request ships to internal testers right away. Every week, the latest build goes to the open beta. When a beta is stable, a maintainer promotes it to production. This page describes that path, and how to build a signed release on your own machine.
When a pull request is merged into main, CI builds the release versions and publishes them to the internal testing track on the Play Store. Internal testers get every change immediately. The app does a lot, so they can't test every feature on every build.
APKs of every commit on main are also attached to the On Push workflow runs.
Every Sunday at 04:00 UTC (Saturday evening in the Americas), CI tags a new version, creates a GitHub pre-release with the APKs, and promotes the latest main build to the open beta. Before that cutoff, the in-app changelog in ChangelogContent.kt should list the new features and backward-incompatible changes of the week.
Anyone can join the beta on Google Play. Beta users find the problems that tests and internal testers can't.
Google reviews every build that goes to the open beta. How long that takes varies, and it can be more than a week. When the next weekly beta comes in while the previous one is still in review, the previous one is dropped. This doesn't block anything, but it is worth knowing when you wonder why a beta is late.
A maintainer promotes the beta to production when it is stable, and it reaches everyone who installs the app from Google Play.
Before promoting:
- Wait a few days after the beta release, so beta users can find regressions.
- Check that the in-app changelog in
app/src/main/kotlin/io/homeassistant/companion/android/changelog/ChangelogContent.ktcovers what ships. - Check Sentry for an unusual number of issues in the beta.
- Check the Google Play Console for crashes, ANRs, and other anomalies.
- Prepare a pull request in the companion documentation that removes the beta labels of the features in this release.
To promote:
- Edit the latest beta release on GitHub. Keep the generated list of commits, and add a Highlights of this release section on top that matches
ChangelogContent.kt. See 2026.6.1 for an example. - Clear the pre-release checkbox, and set it as the latest release.
That starts release.yml, which uses Fastlane to promote the beta track to production for the phone, Wear OS, and Automotive apps. Google reviews the release first, which usually takes a few days. Nothing needs to happen during that review.
The Play Store only covers the full flavor. After a release:
- Send the
minimalAutomotive app to the Harman Ignite store. - Submit the release for review in the Amazon developer console. The APK and changelog were already uploaded when the beta was built, by the
prep_amazonFastlane lane inonPush.yml. - Release the
minimalapp on the Meta Quest store. - F-Droid builds the release on its own, a few days later. See F-Droid.
- Merge the documentation pull request that removes the beta labels.
- If the release fixes security issues since the last production release, add a Disclosed security advisories section to the GitHub release notes, after the highlights, with a link to each advisory.
- For a release with a major change or a great new feature, ask the community manager to help promote it, like with a blog post or on social media.
You only need this if you publish your own build. A release build must be signed.
Keep your keystore and its passwords safe, and never commit them.
-
Create a keystore in Android Studio with Build > Generate Signed App Bundle or APK, or use an existing one. Remember the passwords and the key alias.
-
Name it
release_keystore.keystoreand put it in each app module you build:app/,wear/, orautomotive/. Or setKEYSTORE_PATHto its location. -
Set the signing variables:
KEYSTORE_PASSWORDKEYSTORE_ALIASKEYSTORE_ALIAS_PASSWORDKEYSTORE_PATH, if the keystore is somewhere else
The signing configuration that reads them lives in
build-logic/convention/src/main/kotlin/AndroidApplicationConventionPlugin.kt. -
Build APKs or app bundles, for all apps or for one module:
# APKs
./gradlew assembleRelease
./gradlew :app:assembleRelease
# App bundles
./gradlew bundleRelease
./gradlew :wear:bundleReleaseYou can also build from Android Studio, with Build > Generate Signed App Bundle or APK.