Switch to Android App Bundle format for Play Store uploads

[gnprice]

This would be nice to do because it would probably make our app somewhat smaller to download. Major apps with lots of developers reportedly get 10-40% smaller. Our recent releases are about 11MB as APKs.

Also, I get a reminder about this every time I upload a new release to the Play Store, or promote a release to beta or production.

Some information here (including the figures I've summarized as "10-40%"), and links to more info:
https://developer.android.com/platform/technology/app-bundle

Relevant in particular for us:
https://developer.android.com/studio/build/building-cmdline#bundle_build_gradle

[gnprice]

Bumping up to P1, because adding 64-bit libraries (#3323) just now increased our APK size by quite a lot, and this will reverse that increase. A release build from yarn build:android-nokeys was 13.0MB just before that change (the increase from the 11MB I quoted above is perhaps from the RN v0.59 upgrade, #3399), and is 21.8MB after.

In fact, it should more than reverse it -- from inspecting the APK while working on #3323 , I just noticed that we're shipping not two, but four versions of all the native code. Here's a list of the biggest files within the APK, one that compresses to 21.8MB:

$ unzip -l android/app/build/outputs/apk/release/app-release.apk | sort -rn | head
 61028605                     858 files
  9599984  1980-00-00 00:00   lib/x86_64/libjsc.so
  8809472  1980-00-00 00:00   lib/arm64-v8a/libjsc.so
  7836488  1980-00-00 00:00   lib/x86/libjsc.so
  7054492  1980-00-00 00:00   classes.dex
  6901812  1980-00-00 00:00   lib/armeabi-v7a/libjsc.so
  3848596  1980-00-00 00:00   assets/index.android.bundle
  1120816  1980-00-00 00:00   lib/x86_64/libc++_shared.so
  1095476  1980-00-00 00:00   lib/x86/libc++_shared.so
  1055016  1980-00-00 00:00   lib/arm64-v8a/libc++_shared.so

The quoted sizes are uncompressed. Note the four different versions of libjsc.so, the JavaScript implementation. Note that in addition to two ARM architectures, we have them for x86 and x86_64... architectures which, much to Intel's chagrin, are all but nonexistent on mobile devices. (The Play Console -- this info is at "Release management > Device catalog", as a breadcrumb for my future self -- says they account for about 0.9% of our installs on active devices.) But all those ARM phones are downloading x86 versions of that and RN's other native libraries, on every update to our app, since forever.

At a rough estimate, if the app is still about 22MB before we take care of this, this means it should get reduced to 9-10MB -- well under half the size.

[rk-for-zulip]

This should be relatively easy to accomplish: we simply need to run :app:bundleRelease rather than :app:assembleRelease at release time, and upload the produced .aab file to Google Play.

I'm not sure about Sentry yet; they do appear to have some support for AABs, although we may need to upgrade. (But then, I half expect that'll be needed for #3585 as well.)

[gnprice]

I've made some changes in our release scripts to support AABs, and in our release-process documentation to make them the primary form for the release. I've run through that process for the upcoming v27.156, up to alpha stage, and everything seems to work. (Chat thread starts here.) So, closing this issue as done.

The resulting download-size savings seem to be in line with what we hoped. Our APKs have grown since the above comments (at least partly from RN upgrades; some investigation in chat), to 30.0 MB for v27.156. But the download size is estimated by the Play Console at 12.4 to 13.4 MB, and when I tried the download for my own main device it was 13.8 MB. That's a savings of a little over 16 MB or 54%, which makes it a little more in absolute terms and a little less in relative terms than we estimated earlier.