Switch AnkiDroid publishing from APK-first to AAB-first

[mikehardy]

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?

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[mikehardy]

Yep - this is still important especially while I still remember how to set up AAB from the last app I just built 😅

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[mikehardy]

Going to pin it

[mikehardy]

10027 made me realize that if we allow users to switch locale, but ABB means that Google only ships optimized APKs including the device locale and the default locale resources, then users will not be able to access their preferred locale string translations if the preferred locale is different than the device locale.

It looks like this requirement (decouple locale resource installation from device locale) has been added to the core play library APIs so could be handled without too much trouble for ABB / play store builds: https://android-developers.googleblog.com/2019/03/the-latest-android-app-bundle-updates.html

[mrudultora]

@mikehardy We can disable the generation of APKs from AAB file, based on device locale (particularly region specific languages). This would be the most easiest way to overcome the issue that you mentioned in the previous comment.

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

According to me, AAB pros outcast cons.

To solve the device locale issue:

bundle {
    language {
        // To support all the languages in app bundle
        enableSplit false
    }
}

Also, if we want to split the AAB completely, we can use core play library APIs, as suggested by Mike. At runtime, if the user changes the language from settings, that particular locale-resources can be downloaded.

[mikehardy]

To be clear, AAB is the future, I just want to make sure we don't have regressions. One of the issues with the play core libraries is that they are non-free, so they would not be valid in an F-Droid context for instance. There is no avoiding the continuation of APK generation (with or without splits / locale selection) unfortunately, which is why it is just an issue to switch to AAB-first, not "switch to ABB completely"

[BrayanDSO]

If I understood the local e packaging right and only the device languages are downloaded, this means that we can't have extinct language like Gothic anymore because no devices will have them.

If extinct languages are removed, probably we will be able to add the new Android 13 app language picker as well