Google Sunsets the APK Format for New Android Apps
C. Scott Brown (via Hacker News):
Starting in August 2021, Google will require all new Android APKs to land on the Play Store as App Bundles instead.
This will invariably result in smaller file sizes and other boons for the end-user.
[…]
However, there are two significant issues with AABs. The first is that developers who want their apps to appear in other distribution channels — such as the Amazon App Store or Huawei’s App Gallery — will need to manually export APK versions of their apps.
[…]
The other issue is that developers will need to give Google their app signing key to export an AAB app as an APK.
The good: .aab can be optimized by the Play store for the device that is requesting them (for example stripping resources that don’t apply to a particular device)
The bad: it will be more difficult for non-Google app distribution storefronts to jump-start their catalog by grabbing APKs from the Play Store, because they won’t be able to get one neat APK per listing via some APK downloader. (For apps that do want to get listed on those storefronts, life won’t be very different.)
The ugly: APK distribution is a “zero-trust” model which allows the developer and the user to not have to trust the store not to make any changes to the application. In fact that’s what prevents the kinds of “good” optimizations mentioned above: Google can’t reach into an APK to strip resources that are irrelevant to a particular device, because doing so would invalidate the APK’s signature. By forcing apps to be deployed with keys under Google’s control, this trust model is broken. The Play Store no longer guarantees through cryptography that APKs haven’t been tampered with between the developer’s build system and the recipient device.
A lot of developers seem to be upset by this last bit, though from an Apple developer’s perspective, Apple already has all the keys, anyway (since it generates them for you); and apps from the store get re-signed by Apple’s key, so that users can’t see whether it was signed by the developer.
Previously:
Update (2021-07-02): For Apple developers, the keys are generated locally, and the private key stays on your Mac. Only the public key is given to Apple. Also, I agree with commenter Jean-Daniel that zero-trust is of limited value because you have to trust the platform, anyway.
Developers can keep a local copy of the signing key they upload to Google, allowing them to generate valid updates that can be installed over Google Play versions. Developers can also download signed “Distribution APKs” from the Google Play Developer Console, which are old-school universal APKs that can be uploaded to other app stores. If you’re concerned about Google changing your app without your consent, Google says an optional new “code transparency“ feature will let developers verify that the hashes on downloaded app code match what they uploaded.
[…]
For Google, Android App Bundles are a big deal. At Google I/O 2018, the company said that if every app switched to bundles, Google would save 10 petabytes of bandwidth per day, which is an incredible number, indicating the scale the Play Store operates at.
2 Comments RSS · Twitter
If I unterstand this is only necessary for backwards compatibility. Google wants to serve stripped down apks to old Android versions.
Otherwise they could just change the signature mechanism to verify individual AAB parts. Or they could just add their own "Google Store key" as a trusted re-signing key.
All those talks about Google owning the key and so being able to alter the apps is pointless as you already trust Android (and so Google) to enforce the signature on the end device at install time, and Google can already do whatever they want at runtime anyway.
And the reality is that most app tampering is performed before the developer signed it in the first place (by the mean of corrupted toolchain or build machine).
And finally, the cost to losing the signing key is so high, that anyone who is serious about its app should already have switch to Google Signing.