ankidroid / ankidroid/Anki-Android
Switch AnkiDroid publishing from APK-first to AAB-first
- 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
Assessment
This issue has not been assessed yet.