ankidroid / ankidroid/Anki-Android

Switch AnkiDroid publishing from APK-first to AAB-first

Open
#9,259 8 comments 0 reactions 0 assignees View on GitHub
Dev Keep Open
Dominant language
Kotlin
Stars
11.8k
Forks
2.9k
Avg merge
2d 3h
Merged PRs (30d)
171

Description

APK files are deprecated by Google for publishing, for good reason.

APK Cons:
- space optimization is manual (different builds for different CPU architectures, screen sizes etc)
- signing key vulnerabilities (no way to rotate a signing key if compromised, like our CodeCov issue)

APK Pros:
- ?

AAB Cons:
- you have to generate an APK for other markets anyway (Amazon AppStore, Huawei AppGallery)

AAB Pros:
- Google can rotate the signing key for new installs while maintaining the old key for old installs
- Google can manage architecture-specific build splitting
- Google is pushing everyone to do this so it's actually inevitable

So our main benefits here are: key rotation on Google Play Store, elimination of architecture-specific builds, and forward-porting**

High-level context is that our publishing infrastructure uses these main components:
- AnkiDroid/build.gradle to build/version
- 1 universal APK and 4 architecture-specific APKs for assemblePlayRelease target - the universal build is uploaded to GitHub Releases page as well as Huawei AppGallery, the architecture-specific builds are uploaded to Google Play and GitHub releases
- 1 universal build for assembleAmazonRelease
- AnkiDroid/build.gradle use of the Triple-T play store publishing plugin and Amazon App Store publishing plugin
- tools/release.sh that automates the release process, as well as the upload to Google/Amazon/GitHub-releases
- .github/workflows/publish.yml that integrates github repository secrets and tools/release.sh to drive it automaticallly
- manual upload to Huawei AppGallery (pending #6677), and manual release of production builds on Amazon + Google
- F-Droid builds from source

Action plan:
- opt-in on google for application bundles vs apk uploads, enroll our current signing key, generate a new upload key in our release keystore and upload that into the github repository as an updated secret
- alter tools/release.sh to also call assemblePlayBundleRelease (I think) in the pre-google-publish build phase - should work with updated keystore
- **study** moving versionCode to the next value above the current highest architecture-specific versionCode range (so the Play Store won't have versionCode overlap) and see if we can have a single versionCode stream using only the AAB file for Google and the universal build for everywhere else
- alter AnkiDroid/build.gradle to use the .aab file for Triple-T uploads once versionCode behavior has been studied + agreed on
- alter AnkiDroid/build.gradle tools/release.sh to remove the architecture-specific build + github releases upload
- publish an alpha AAB to google play store + universal APK to github releases with a single versionCode stream
- **study** if we can have google rotate the signing key they use for new installs

Should work?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.