ankidroid / ankidroid/Anki-Android

Switch AnkiDroid publishing from APK-first to AAB-first

Abierto
#9,259 8 comentarios 0 reacciones 0 asignados Ver en GitHub
Dev Keep Open
Lenguaje dominante
Kotlin
Estrellas
11.8k
Forks
2.9k
Merge medio
2 d 3 h
PR fusionados (30 d)
171

Descripción

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?

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.