feat: Upload universal APK rather than AAB to Google Play

[gmaclennan]

Currently we upload an .aab bundle to Google Play Store, and the Play Store then generates separate APKs for each architecture (arm7, arm64, x86, x64), which reduces the download size for people installing from the Play Store.

Unfortunately for p2p updates, this means that each device only has the code (APK) for its own architecture, so an arm7 device would not be able to share an update with an arm64 device.

This PR changes the Google Play Store upload to use a "Universal" APK, which should ensure that users installing from the Play Store receive an APK that supports all architectures. Unfortunately this means that the install/download size is about 3-4 times as big, but with the flexibility of offline p2p updates.

Question: Should we perhaps separate 2 APKs: arm7 + arm64 in one, and x86 + x64 in the other? Very few phones run on Intel (although it is more common for Chromebooks). This would mean that if someone with an Intel device installs from the Play Store, they would not be able to share a p2p update with an Arm device, and vice-versa. But an Arm7 device would be able to share with an Arm64 device.

[hackergrrl]

Qs that might shed some light on this:

• How many users of ours do we estimate use an intel phone? (We could estimate by looking at what phones from the last ~5 years are Intel-based and see how popular they are relative to the arm devices)
• How many users of ours do we estimate are using chromebooks for Mapeo Mobile? (Any?)
• Which communities are downloading Mapeo from the internet? Can we estimate their download speed / do Programs folx already know? (This could tell us whether 90mb matters much vs 45mb.)
• How do these build sizes compare to most apps? Odds are, if they're used to downloading other apps from the Play Store, they'd probably be ok downloading Mapeo if it was comparable in size to most apps.

[gmaclennan]

Qs that might shed some light on this:

• How many users of ours do we estimate use an intel phone? (We could estimate by looking at what phones from the last ~5 years are Intel-based and see how popular they are relative to the arm devices)

From this Stackoverflow post, the answer seems to be that x86 phones are very rare.

• How many users of ours do we estimate are using chromebooks for Mapeo Mobile? (Any?)

I don't imagine anyone is using a chrome book at this time, not even sure it will work. Chromebooks don't normally have a GPS, so not sure how useful it would be. I would imagine that anyone with a chromebook or laptop is more likely to have access to internet than someone with a phone.

• Which communities are downloading Mapeo from the internet? Can we estimate their download speed / do Programs folx already know? (This could tell us whether 90mb matters much vs 45mb.)

I checked our actual sizes:

• Single arch (arm64): 42.4 MB
• Dual arm arch (arm7 + arm64): 62.6 MB
• All arch (arm7 + arm64 + x86 + x64): 111.5 MB

I think we need to consider future users who would be downloading via a (paid) cellular data connection. Many users in countries where Mapeo is used will not have easy access to wifi at home, and will rely on cellular data. Android guidelines used to consider 100Mb as too big to download over cellular (not sure if that has changed) and apps for low-powered devices are targeted for 10 MB.

Mapeo is big because we are bundling the Node binary, and this unfortunately got a bit bigger in Node v12. Node and LevelDB binaries are replicated for each arch.

• How do these build sizes compare to most apps? Odds are, if they're used to downloading other apps from the Play Store, they'd probably be ok downloading Mapeo if it was comparable in size to most apps.

Some popular apps:

• Tiktok: 75 Mb
• WhatsApp: 27 MB
• PayPal: 28 MB
• Amazon: 47 MB
• Twitter: 26 MB
• Facebook Messenger: 41 MB

My conclusion: supporting p2p updates for x86 devices comes at too great a cost (APK size, both in terms of download size and space on phone) for the majority of users who will not benefit from it.

Therefore: have a separate APK for x86/64 devices, so anyone on a x86 device would need to offline update with another x86 device, or use the internet.