Google sunsets the APK format for new Android apps(androidauthority.com)
androidauthority.com
Google sunsets the APK format for new Android apps
https://www.androidauthority.com/android-apks-sunset-1636829/
117 comments
I had six apps on Google Playstore several years back. They were free, no adverts or in-app tricks... Google removed them, since I didnt keep creating new versions. Oh well. But the API churn has become explicit neo-monoploy strategy. Google and Apple should be broken up. Two companies control all mobile software distribution - and restrict and block independent developers using all the classic tricks of monopolists. It's just nuts. No other industry is this concentrated. There is no innovation happening here. 15% smaller size? So what. This whole exercise is to maintain and extend control. Regardless of where one sits on the political spectrum, this is just "company store" monopolist tricksterism, and the solution is to dust off the old Anti-Trust laws and break this abusive entity into three or four seperate companies. "Trust Busting" is something both the Right and the Left can agree on. Break Google up. If - as a developer - you want to distribute your code as an .APK, then you and your customers should be able to make that choice. This current economic model is not only bogus - it is actually contrary to black-letter US law.
Genuine question: why not distribute them yourself (e.g. on GitHub)? If more and more developers do this, it will be like pc software. We don't have to accept a storefront (on Android at least).
It has been established that distributing APK anywhere else (Github, etc.) other than the Play store would have a drastic impact on the exposure and discoverability of the app, which will lessen user engagement and revenue stream.
Disclaimer: I'm not an app developer, but works in PR and marketing.
Disclaimer: I'm not an app developer, but works in PR and marketing.
I think you answered the question of "why distribute on the Play store", not the question of "why not distribute on GitHub". Presumably you could do both?
We had an app in the store and a download on our product page.
Months in, a new update and Google banned the app forever with no recourse.
You can distribute it but not as you. T&C violation.
We had to create a new app and remove the download.
Months in, a new update and Google banned the app forever with no recourse.
You can distribute it but not as you. T&C violation.
We had to create a new app and remove the download.
The heck. Thanks for sharing that. How is that even legal? Do you happen to remember what clause it violates?
I had to go look it up, the clause was:
Issue: Violation of Malicious Behavior policy
With this as the explanation: Potentially malicious external APKs within the App.
The App had a link to our website on it's dashboard, our website had a download for all installers (we're cross-platform) and it was the same APK but because of potential for it being malicious, they suspended the app with no recourse. (We did remove the APK download, but couldn't update the App to remove the link to the website)
This was in 2018 and we had been in the store for about a year at that point. It was a patch update that triggered it.
With this as the explanation: Potentially malicious external APKs within the App.
The App had a link to our website on it's dashboard, our website had a download for all installers (we're cross-platform) and it was the same APK but because of potential for it being malicious, they suspended the app with no recourse. (We did remove the APK download, but couldn't update the App to remove the link to the website)
This was in 2018 and we had been in the store for about a year at that point. It was a patch update that triggered it.
I would love an alternative Android store that's curated to filter out the 90% of crApps that show up for me these days in the Play store. Along with a checkbox to exclude those with ads, in-app purchases and other such tricks.
Apps on F-Droid/IzzyOnDroid are FOSS and usually pretty good. As for things from Google Play, Aurora Store has some filter capabilities, although the app has some glitchiness.
Theres always https://www.apkmirror.com/
Established by whom? Many people host their apps on Google Play just so they don't subject their users to warnings about "installing apps from unknown sources" and for convenient updating.
> user engagement and revenue stream
Well, if you're making an app for the sole purpose of making charts go up...
> user engagement and revenue stream
Well, if you're making an app for the sole purpose of making charts go up...
A sizeable portion of Android users are not technology savvy, the "installing apps from unknown sources" message will deter some of them.
>Well, if you're making an app for the sole purpose of making charts go up...
Unless the app is a hobby project, most people would put maximizing their potential revenue stream and marketability of their product as a high priority.
>Well, if you're making an app for the sole purpose of making charts go up...
Unless the app is a hobby project, most people would put maximizing their potential revenue stream and marketability of their product as a high priority.
Depends on your motive. Some people just make useful apps with no motivation beyond that.
Discussions about the old Internet made me go back to developing and using the web like its 1999. It's quite liberating.
If the tool is good it doesn't need the crap stores to hoist it up. I could care less about the tech unsavy.
Discussions about the old Internet made me go back to developing and using the web like its 1999. It's quite liberating.
If the tool is good it doesn't need the crap stores to hoist it up. I could care less about the tech unsavy.
That's a valid insight in general, but I don't see how that is relevant to apps that are free and have "no adverts or in-app tricks".
Some free apps don't mind being niche, for others having lots of users is more important.
There are benefits to both.
API churn seems to kill both, but if you can support your app properly having lots of users will certainly alert you to issues more quickly.
There are benefits to both.
API churn seems to kill both, but if you can support your app properly having lots of users will certainly alert you to issues more quickly.
Not having the APK available anywhere has an even more drastic impact.
It doesn't reach users.
On iOS, that's not even an option. On Android, that's hidden behind some scary checkboxes that state they're only for developers.
Side-loading apps like this is advertised as "insecure" and "dangerous" so as to discourage people form doing so.
On iOS, that's not even an option. On Android, that's hidden behind some scary checkboxes that state they're only for developers.
Side-loading apps like this is advertised as "insecure" and "dangerous" so as to discourage people form doing so.
This is not entirely true anymore. I can whitelist apps to install apps instead of making it on a per app level. So I can simply add stores and only confirm the 'danger' message once
You also wouldn't be able to use push notifications, and modern Androids heavily restricts background app running.
So it turns out the original "disruptors", using scorched-earth business techniques, and despite adhering to the mantras of open-source software, have become uncontrollable monsters?
It should make you think a little about how things are done in Silicon Valley.
It should make you think a little about how things are done in Silicon Valley.
We just need new disruptors.
A little tougher now that the current companies have the government on their side.
A little tougher now that the current companies have the government on their side.
Same here. I've build web things 10 years ago that still have happy visitors to this day. Every app I built (only 3) was removed within a year.
I don't feel crazy enough to waste time in things that can't exist without me permanently touching it for no reason
I don't feel crazy enough to waste time in things that can't exist without me permanently touching it for no reason
After nearly a decade of mobile development I have stopped developing for Android & iOS as well.
Apple had(has?) two years policy for app removal if not updated, I feel that's fair considering quality & security.
But Apple did me real good when overnight it moved my arcade type game from Arcade category to some other generic category because it named its game store as 'Arcade'.
That was the beginning of the series of events ending with semi-mandatory vaccine apps being available only these platforms (no web) to put bad taste in my mouth. Now I've gone back to web development for my products.
The only reason an average app publisher want their app to not be on web is because it cannot steal as much private data(or users can easily protect themselves) .
Apple had(has?) two years policy for app removal if not updated, I feel that's fair considering quality & security.
But Apple did me real good when overnight it moved my arcade type game from Arcade category to some other generic category because it named its game store as 'Arcade'.
That was the beginning of the series of events ending with semi-mandatory vaccine apps being available only these platforms (no web) to put bad taste in my mouth. Now I've gone back to web development for my products.
The only reason an average app publisher want their app to not be on web is because it cannot steal as much private data(or users can easily protect themselves) .
There are so many arguments for Progressive Web Apps (PWAs). Independence from FAANG is only one of them.
Yes, there are but in iOS even PWAs are at the mercy of Apple as they anti competitively don't allow any competing browser engines.
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.
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.
I do not find "The ugly" very compelling since most developers are not very good at keeping their signing keys secure.
At least they give you the signing certificate so you can verify the end user is using a Play Store build and not something potentially malicious. Testing release builds requires a round-trip through the Play Store, though, and apparently AOT-compiling is only triggered when the Play Store installs its blessed version of the app.
Users trust Google more than they do random app devs in many / most cases
This isn't about trusting the app dev at all, this is about trusting that Google didn't tamper anything. Whether or not trust a dev, you can't trust that you are getting what the dev intended. If you download a version of Signal Google silently changed to include a backdoor, it doesn't matter whether you trust Signal or not: Google will get all of your data.
I would not be surprised if Google force-monetised apps like they did with YouTube videos.
Totally agreed. However for the few cases where it matters, IMO it's a regression
About the last point, I am not familiar about the key distribution there...
Say Google wanted to create an eavesdropping Facebook Messenger, couldn't it hide the real one and replace it with an app of the same name, signed by an entity named "Facebook Inc [random invisible unicode character]" and essentially do the same thing?
I always assumed that the APK security model did not protect against a compromised Google Store?
Say Google wanted to create an eavesdropping Facebook Messenger, couldn't it hide the real one and replace it with an app of the same name, signed by an entity named "Facebook Inc [random invisible unicode character]" and essentially do the same thing?
I always assumed that the APK security model did not protect against a compromised Google Store?
If my understanding is correct, it wouldnt protect new installations of the app in your hypothetical, however any attempt to update existing users would fail.
That is correct. An APK is signed with its developer's key. When you first install an app, the system trusts that key. If you later update it (by installing an APK with the same package id on top of the existing one), the key must be exactly the same for the update to succeed. The only way to install an app with the same package ID but a different signature is to uninstall the existing one first. This is done to protect the potentially sensitive data the app stores in its dedicated directory under /data/data/.
What happens if your key is compromised? Is there a way to continue with a new key or does everyone have to reinstall your app?
V3 signatures do support key rotation iirc, but they're only supported by several latest Android releases. Their existence wasn't even officially announced by Google yet. So, yeah, as of right now, everyone would have to reinstall the app.
That seems like a very interesting attack vector. Compromise a key, have a replacement/fake ready. In the ensuing confusion you trick people to install your app.
It sort of does. The new app in your case would be signed by a different key and so wouldn't have access to the existing app's data. It would boil down to a phishing attack - the new app would have to impersonate the UI of the old one and get users to log in again.
Hence my concern with this part of the article:
"While it’s unlikely Google would ever do so, it is possible that it could sign apps on behalf of a developer"
Actually given the trend the company has been on over the past 6 years I'd say it's very likely Google would do this ...
Hence my concern with this part of the article:
"While it’s unlikely Google would ever do so, it is possible that it could sign apps on behalf of a developer"
Actually given the trend the company has been on over the past 6 years I'd say it's very likely Google would do this ...
I don't think the "ugly" point is completely true, there's another optional level of signing that uses keys under control of the developer alone, approximating the APK model: https://developer.android.com/guide/app-bundle/code-transpar...
From the linked documentation:
> The code transparency file does not verify resources, assets, the Android Manifest, or any other files that are not DEX files or native libraries contained in the lib/ folder.
> Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs.
Do I understand it right that it basically means user's device doesn't care about this signature at all? Wouldn't that make it pretty easy to supply modified versions of app to specific devices without them noticing, unless users decide to check signatures by themselves?
> The code transparency file does not verify resources, assets, the Android Manifest, or any other files that are not DEX files or native libraries contained in the lib/ folder.
> Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs.
Do I understand it right that it basically means user's device doesn't care about this signature at all? Wouldn't that make it pretty easy to supply modified versions of app to specific devices without them noticing, unless users decide to check signatures by themselves?
Right, it's not checked by the device. Its purpose seems to be more forensic: say an app version turned out malicious, and the developer said it wasn't me, Google was pwn3d and used my keys to sign malware. Code transparency would allow a developer to prove that tampering had occurred between their build of the app bundle and the user installation. It looks more like an accountability mechanism in case of failure than a protection.
That's right, the transparency signature is not checked during installation. If you think somebody at Google might be out to get you and has all those powers and resources, there are many ways other than serving bespoke bundles, even with good old APK. Since they control the store and the system software that goes with it, they could download and save the original APK to give you some false sense of security, but apply a patch before extraction or code compilation. Or they could just crack the developer's signing key by using spare processing resources across their fleet, at least for anything comparable to RSA-1024 or lower. Those three attacks are theoretically feasible, but, I think, all equally hard to pull off without detection inside or outside the company.
As side note, this is how Windows Store (the old one) used to work, a cloud compiler generated native code specific for the device.
The whole JIT/AOT infrastructure from Android 5 onwards, Microsoft did it on the cloud instead.
Hence why Windows Phone always tended to be snappier than similar Android devices.
https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-an...
https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native
Also how iOS and watchOS apps, since app thinning and bitcode were introduced as packaging format.
The whole JIT/AOT infrastructure from Android 5 onwards, Microsoft did it on the cloud instead.
Hence why Windows Phone always tended to be snappier than similar Android devices.
https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-an...
https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native
Also how iOS and watchOS apps, since app thinning and bitcode were introduced as packaging format.
Idk about Windows but yes the App Store has been doing it this way from the start. I suspect this is a case of Apple envy.
Unfortunely the Apple envy doesn't go as far as providing proper C++ tooling instead of NDK pain, modern 3D frameworks with GPGPU debugging instead of cloning Vulkan github repos, SIMD frameworks instead of low level neon intrisics + NDK pain, a modern language that actually supports value types (they don't care about Java anyway), a proper real audio API that is part of the NDK instead of yet another github repo to clone, a mostly useless watchOS, .....
Yep Apple envy could do some good to the development experience on Android.
Yep Apple envy could do some good to the development experience on Android.
> "The other issue is that developers will need to give Google their app signing key to export an AAB app as an APK. This gives Google quite a bit of power."
I can't even.
I can't even.
This is insane. What is the point of even having a developer signing key if people other than the developer have access to it? Why don't they just sign the APKs with Google's own keys from here on out?
Can't wait to hear Moxie's response on this. One of his (many) reasons for refusing to support FDroid was because it didn't allow developers to sign their own apps, and thus users had to trust that FDroid did not modify the app. Now FDroid has addressed that, but Google has not only removed that feature, but is demanding that developers allow Google to impersonate them.
Can't wait to hear Moxie's response on this. One of his (many) reasons for refusing to support FDroid was because it didn't allow developers to sign their own apps, and thus users had to trust that FDroid did not modify the app. Now FDroid has addressed that, but Google has not only removed that feature, but is demanding that developers allow Google to impersonate them.
Iirc they're switching to that model (google uses it's own key) but they need the developers' keys for older apps because android won't allow changing the key when an already installed app is upgraded.
Except Google maintains the code that performs those checks. Rolling out changes to key checking will result in a longer transition, but it is more legitimate than demanding developers hand over private signing keys. And in the meanwhile Google Play store knows which phones have been updated, so it can provided the slimmed-down Google-signed APKs to them, and the universal developer-signed APKs to everyone else.
> Now FDroid has addressed that
Out of loop, what changed?
Out of loop, what changed?
> Out of loop, what changed?
https://f-droid.org/en/docs/Reproducible_Builds/
https://f-droid.org/en/docs/Reproducible_Builds/
I'm confused; why do developers need Google to export an APK for them? Can they no longer generate APKs (locally) themselves and distribute them however they like?
Based on the blog post's FAQ my impression is you can still do that. My impression is it's only for apps in the play store (and the corresponding export play store AAB to APK feature) that you are required to giving your keys to Google.
https://android-developers.googleblog.com/2021/06/the-future...
https://android-developers.googleblog.com/2021/06/the-future...
That is to allow existing apps to update to AAB distribution. New apps do not get access to the signing key, only the certificate.
when i saw the headline, I knew google would use it as a pretext to do something disgusting. Everything they do has some dark pattern to it somewhere. AMP is a great example.
You should never, ever give your signing key to anyone. Especially not google. you might think of google "they wouldn't" but in fact they can, they have, and they will again.
You should never, ever give your signing key to anyone. Especially not google. you might think of google "they wouldn't" but in fact they can, they have, and they will again.
Note that new apps don't provide the Play Store with the key, they just verify against the first certificate they receive.
Not the point.
This turns the trust model of the ecosystem on its head.
When I install an app like Signal today - I have cryptographic certainty that it was the code the Signal team intended me to have with 0 tampering.
In the new model - I have to trust that Google, it's employees and processes have not been subverted by another actor.
It is a fundamentally weaker model. I hope Google budgeted some legal time responding to government court orders to spin custom targeted versions of apps for persons of interest. It might also be a tempting honeypot to identify employees that have been compromised by nation-state actors.
It would be interesting to hear what things would have looked like if changing the trust model was off the table. Surely it must have had at least some discussion.
This turns the trust model of the ecosystem on its head.
When I install an app like Signal today - I have cryptographic certainty that it was the code the Signal team intended me to have with 0 tampering.
In the new model - I have to trust that Google, it's employees and processes have not been subverted by another actor.
It is a fundamentally weaker model. I hope Google budgeted some legal time responding to government court orders to spin custom targeted versions of apps for persons of interest. It might also be a tempting honeypot to identify employees that have been compromised by nation-state actors.
It would be interesting to hear what things would have looked like if changing the trust model was off the table. Surely it must have had at least some discussion.
While I completely agree with what you say, I feel it must be pointed out that in the use case of using the bundled Play store application on the device, you have no way of being certain that it is delivering you the correct APK.
It might just as well pull a modified version (there are caveats such as that the device can't already have a valid version of the application setup for this to go unnoticed).
Pulling the apk from Play using something like Raccoon would allow you to verify the signature.
It might just as well pull a modified version (there are caveats such as that the device can't already have a valid version of the application setup for this to go unnoticed).
Pulling the apk from Play using something like Raccoon would allow you to verify the signature.
No one cares about your signing key.
Google can create a key on their own servers if you want (you can't export this key so can't use it to sign apps for multiple stores) but u can keep your own keys secret
Google can create a key on their own servers if you want (you can't export this key so can't use it to sign apps for multiple stores) but u can keep your own keys secret
You're cleverly ignoring the main use of signing, knowing the app wasn't tampered with before installation.
You're also incorrect, if people have apps signed with your signing key then you must provide it to Google.
You're also incorrect, if people have apps signed with your signing key then you must provide it to Google.
Very disappointing. Normalizing sharing private keys? I expect better from Google.
None of the user facing benefits of the new format apps are predicated on throwing away the trust model of the app ecosystem. It is easier to implement and optimize the publish flow sure. Google is one of the few companies with the skills and resources to do it the right way.
Say it ain't so!
None of the user facing benefits of the new format apps are predicated on throwing away the trust model of the app ecosystem. It is easier to implement and optimize the publish flow sure. Google is one of the few companies with the skills and resources to do it the right way.
Say it ain't so!
The walled garden's walls heighten. However, sideloading will still function with other avenues. But still, this barely adds anything, and even though it can be more optimized for devices, that's not much compared to the large ramifications.
Just wait, Google will probably remove that in an upcoming Android version soon.
So what's this mean, effectively, to other app stores on Android? I'm pretty sure most developers won't bother making APK's for third party app stores with very small user bases. And what's this mean to Microsoft who is bringing APK's to Windows? Existing APK apps sure, but can Microsoft use the new format as well or no?
From my reading of the windows 11 coverage, they're relying on APK sideloading or the Amazon app store for distribution. So no, Microsoft will likely not be able to use the new AAB format (although I'm sure there's some ongoing negotiations around this. Never say never...)
AABs are built, and APKs extracted, with bundletool, part of the open-source Android SDK. There is nothing technical preventing Amazon or F-Droid from accepting AABs and providing APKs on-demand.
If the dev wants to release their app on another app store, they would just export the apk. Pirate app stores that share apks without the dev's permission would probably need to write their own aab to apk converter and sign the apks with a key owned by the pirate app store. So this probably isn't a big deal for regular devs, but will reduce the security of apks downloaded from pirate app stores since it would be harder to verify the code integrity of the derived apps.
Seems like devices still deal with apks. Apks remain a core part of development. The biggest hurdle to 3rd party app stores is the API, not making an apk.
https://android-developers.googleblog.com/2021/06/the-future...
> If I use app bundles, can I still publish through multiple distribution channels/app stores?
> Yes, there are multiple ways to achieve this. You can either use the same app signing key everywhere or use unique app signing keys for different channels, including a unique app signing key for Google Play. You can either build and sign artifacts for all distribution channels locally or you can download distribution APKs from Google Play for use on other channels. Distribution APKs downloaded from Google Play, either via the app bundle explorer in Play Console or via the Play Developer API, are signed with the same key used by Play App Signing.
> If I use app bundles, can I still publish through multiple distribution channels/app stores?
> Yes, there are multiple ways to achieve this. You can either use the same app signing key everywhere or use unique app signing keys for different channels, including a unique app signing key for Google Play. You can either build and sign artifacts for all distribution channels locally or you can download distribution APKs from Google Play for use on other channels. Distribution APKs downloaded from Google Play, either via the app bundle explorer in Play Console or via the Play Developer API, are signed with the same key used by Play App Signing.
I've started deploying a new app under testing (public testing) a few days ago (it's still under review).
I've also made similar flow for iOS (test flight).
I already had few apps on Play for years now but didn't need to update them within the past 2 years.
The AppStore and Play Store feels now much similar than before:
- bundles / bitcode - The AppStore get modules they can repackage on "your behalf"
- review - for a year or more it takes a few days for your app to be reviewed. Even just for testing (public beta)
- signed by store, that's the major difference now (which as stated required for bundles)
Iiuc, that was always the case with Amazon AppStore (noted by commonsware https://news.ycombinator.com/item?id=27651983)
Personally I'm more concerned when/if a private certificate won't be allowed at all (eg iDevices).
I've also made similar flow for iOS (test flight).
I already had few apps on Play for years now but didn't need to update them within the past 2 years.
The AppStore and Play Store feels now much similar than before:
- bundles / bitcode - The AppStore get modules they can repackage on "your behalf"
- review - for a year or more it takes a few days for your app to be reviewed. Even just for testing (public beta)
- signed by store, that's the major difference now (which as stated required for bundles)
Iiuc, that was always the case with Amazon AppStore (noted by commonsware https://news.ycombinator.com/item?id=27651983)
Personally I'm more concerned when/if a private certificate won't be allowed at all (eg iDevices).
> An Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play.
> Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app.[1]
So a unique .apk is generated for each device configuration on demand? Goodbye to the days when a single (or a couple) .apk worked on all devices, which was easy to rehost, redistribute etc.
Is the toolchain needed for compiling AAB -> APKs open source atleast? And will Google Play let end-users download the source .aab file?
1: https://developer.android.com/guide/app-bundle
> Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app.[1]
So a unique .apk is generated for each device configuration on demand? Goodbye to the days when a single (or a couple) .apk worked on all devices, which was easy to rehost, redistribute etc.
Is the toolchain needed for compiling AAB -> APKs open source atleast? And will Google Play let end-users download the source .aab file?
1: https://developer.android.com/guide/app-bundle
IIRC, an AAB is basically a set of APK "dimensions" (base, screen size, screen density, ISA, and so on), so you end up downloading one APK per dimension and install them as one transaction.
This is also possible to do through both the CLI (adb shell) and Java APIs. However, it does indeed make sideloading more troublesome (the regular graphical installer has no idea about how to do multi-APK transactions). However, you can still distribute monolithic APKs for that purpose...
This is also possible to do through both the CLI (adb shell) and Java APIs. However, it does indeed make sideloading more troublesome (the regular graphical installer has no idea about how to do multi-APK transactions). However, you can still distribute monolithic APKs for that purpose...
This is basically correct. An app can be loaded as one APK or as a set of multiple APKs - these are sometimes called "split APKs". For a while the Play Store has supported sending apps as a base APK plus a bunch of "config split" APKs. The base APK contains things like DEX code (Java bytecode).
The config split APKs are grouped by various device targeting dimensions (basically language, DPI, and architecture). As you can imagine, apps often have a different set of strings for each language, multiple versions of native libraries for different ARM / x86 ABIs, and assets for different DPIs.
When you create a bundle, Play will build split APKs for each possible value in each group (e.g. a low-dpi APK, a high-dpi APK, an English-language APK, a Korean-language APK, etc...).
When a device downloads the app, Play will send that device the base split APK and one config split APK from each group. So I will get the base DEX code, the arm64v8a native code APK, the XXHDPI APK, and the English strings APK. That means devices don't have to download or store potentially large amounts of app assets and native code that will never be used on that device.
EDIT: Older devices (IIRC L and below) don't support this. So Play will build standalone APKs for their configuration. I am not sure how many possible standalone APKs it will build.
The config split APKs are grouped by various device targeting dimensions (basically language, DPI, and architecture). As you can imagine, apps often have a different set of strings for each language, multiple versions of native libraries for different ARM / x86 ABIs, and assets for different DPIs.
When you create a bundle, Play will build split APKs for each possible value in each group (e.g. a low-dpi APK, a high-dpi APK, an English-language APK, a Korean-language APK, etc...).
When a device downloads the app, Play will send that device the base split APK and one config split APK from each group. So I will get the base DEX code, the arm64v8a native code APK, the XXHDPI APK, and the English strings APK. That means devices don't have to download or store potentially large amounts of app assets and native code that will never be used on that device.
EDIT: Older devices (IIRC L and below) don't support this. So Play will build standalone APKs for their configuration. I am not sure how many possible standalone APKs it will build.
App Bundles have been available and widely used for years. People are lamenting days that went away years ago but are just now complaining, which makes me think that the concerns are overblown.
Curiously enough, Google itself only recently introduced local app sharing ("Nearby Share" via Bluetooth/Wifi etc. – of course only for free apps) as an official built-in Play Store feature, while at the same time an increasing prevalence of app bundles will mean a suboptimal experience when sharing between devices with differing screen density, language, etc.
Is anyone using Aurora Store and worried about how it will affect them? For reference, Aurora anonymously retrieves APKs from the play store so you can use common apps like Zoom, Slack, et cetera.
Will we be able to do offline installation of the .aab files like we can for .apk? Sucks if the answer is no.
I suspect making that harder was one of the main motivations, since I highly doubt Google would actually care so much about app sizes in an ecosystem that was already insanely bloated from the beginning. (https://news.ycombinator.com/item?id=15442743)
Weakening adblocking in browsers and churning the web "standards" to the advantage of its browser, the increasingly "ignore the user's request" attitude of its search engine, and dumbing-down and hiding information in its products --- it has a technical argument for every single thing it does, but don't let that convince you to think that's the real reason it did that. Google is extremely good at rationalising otherwise anti-user decisions with a technical and positive spin --- it's an ad company, after all, and persuasion/reinterpretation of the truth is what marketing is all about.
Android is still comparatively open as far as mobile devices go, but with each change it makes I can see the walls are slowly rising around its garden.
Weakening adblocking in browsers and churning the web "standards" to the advantage of its browser, the increasingly "ignore the user's request" attitude of its search engine, and dumbing-down and hiding information in its products --- it has a technical argument for every single thing it does, but don't let that convince you to think that's the real reason it did that. Google is extremely good at rationalising otherwise anti-user decisions with a technical and positive spin --- it's an ad company, after all, and persuasion/reinterpretation of the truth is what marketing is all about.
Android is still comparatively open as far as mobile devices go, but with each change it makes I can see the walls are slowly rising around its garden.
> since I highly doubt Google would actually care so much about app sizes in an ecosystem that was already insanely bloated from the beginning. (https://news.ycombinator.com/item?id=15442743)
Isn't that logic backwards? Precisely because the ecosystem is bloated they're doing something about it in a place they can?
Isn't that logic backwards? Precisely because the ecosystem is bloated they're doing something about it in a place they can?
I have to agree. I don't like it either but Android's flexibility still is miles ahead of iOS so it is more of a case of choosing the worse between two bad choices. E.g. I heavily use Syncthing to keep data/media across various devices in sync (mostly Linux and Android); recently we purchased an iPhone so I thought of doing the same setup for managing photos/videos etc and basically, other than some hacky options, there is no clean and seamless solution. Google's walls are rising but I can still pretty easily hop over them compared to Apple's fortress.
I believe this is maybe the last step before a total removal of sideloading apps on Android. Sideloading is the main reason why I left iOS for Android 10 years ago. If it's off the table ... I might switch to a Linux phone... Or go back to iOS
People have been crying wolf about "ZOMG! GOOGS GON REMOVE SIDELOADS" for years now.
It's still present.
AOSP still exists and is still updated.
Pixel devices still have unlockable bootloaders.
Your fear is still unfounded.
It's still present.
AOSP still exists and is still updated.
Pixel devices still have unlockable bootloaders.
Your fear is still unfounded.
After SafetyNet, unlockable bootloaders are quite useless, you instantly lose access to a bunch of apps. It's a no-go for many.
While you lose access to some apps if you switch to many unofficial ROMs not based on stock firmware, which is problematic as it's almost always unnecessary unless a device is rooted or obviously compromised, this is far from the only use for unlockable bootloaders. Flashing updates more rapidly, region changes, bloatware removal, and other use cases are still possible with unlocked bootloaders while preserving safety certifications.
AOSP is neigh unusable in its own form without heavy modifications on a phone.
Going from "all phones" to "one brand and modified" is a significant barrier to sideloading.
Being concerned is valid given Google's history. It may not happen. It may happen. It may happen a long way now. But when has Google opened a service or product in a purely consumer friendly, community friendly way?
Going from "all phones" to "one brand and modified" is a significant barrier to sideloading.
Being concerned is valid given Google's history. It may not happen. It may happen. It may happen a long way now. But when has Google opened a service or product in a purely consumer friendly, community friendly way?
I am so glad I got out of the whole game, and stopped using a smartphone. I'm also glad I live in a country where it is somewhat viable, although in our post-Covid world, everywhere seems to need a crappy app to get anything done.
I absolutely do not believe in caring about flash space, all of the APKs from Google LLC are quite bloated. Google is likely targets users who are side-loading their apps, grabbing even more DRM power for themselves.
Wait, why can't other stores use AABs?
Pretty sure there's no technical reason they couldn't.
Google warned last year they were deprecating APKs on the play store. I didn't think much of it at the time as I had a much bigger problem when they insisted everything shift to 64 bit, a painful process if you have native libraries.
AAB files aren't suited to local installation like an APK though, they are more like everything google needs to build APKs themselves for installation on different devices. I think we will still build APKs for direct distribution.
AAB files aren't suited to local installation like an APK though, they are more like everything google needs to build APKs themselves for installation on different devices. I think we will still build APKs for direct distribution.
As others have asked though, how does this effect side-loading? What does the user end up downloading: an apk, or an aab? If it's an aab, can they archive it for later, like you can with apks? APK archive sites have saved my ass on numerous occasions when the developer decided to "improve" their app, forcing me to downgrade to get it back to a preferable state. And then of course there are apps that don't have the holy blessing of our Lord and Savior Google. Is it going to become impossible to load those at all without installing some weird homebrew OS? For now APKs still work on the phones themselves, but I imagine that will be stolen from us as well at some point.
> What does the user end up downloading: an apk, or an aab?
Your phone still downloads APKs from the Play Store, but it's no longer a single monolithic APK that covers all languages/screen sizes/CPU architectures [1] supported by that app. Instead you'll get a collection of APKs covering your specfic device configuration only.
> If it's an aab, can they archive it for later, like you can with apks?
You can archive the individual APKs, although installing them again is a bit more complicated, as you either need a third-party app like https://f-droid.org/packages/com.aefyr.sai.fdroid/, or else install them via the correct incantation on the command line.
As for APK archive sites, presumably coverage of languages/screen sizes/CPU architectures with few users might get worse, as one user uploading an individual APK version will no longer be enough to automatically cover all languages/screen dimensions/etc. and instead you need to grab separate APKs for each possible language/screen size etc.
Getting the APK with the correct CPU architecture (where applicable) will of course be critical, although in practice almost everybody is probably using ARM these days, so there's not much to go wrong here (although if you still have a 32-bit device then you can only run the 32-bit APK, whereas the other way round a 64-bit device can run both 32- and 64-bit native code).
As for language and screen density, my guess would be that Android can fall back to whatever language and screen density APK actually has been installed (since this should be the same situation as when a monolithic APK doesn't contain the correct resources for your preferred language/screen density), so you might get a degraded experience (wrong language, either blurry or unnecessarily-high-resolution graphics), but the app at least still runs.
[1] Although given the potentially large size of native libraries, separate APK versions for differing CPU architectures already aren't that uncommon.
Your phone still downloads APKs from the Play Store, but it's no longer a single monolithic APK that covers all languages/screen sizes/CPU architectures [1] supported by that app. Instead you'll get a collection of APKs covering your specfic device configuration only.
> If it's an aab, can they archive it for later, like you can with apks?
You can archive the individual APKs, although installing them again is a bit more complicated, as you either need a third-party app like https://f-droid.org/packages/com.aefyr.sai.fdroid/, or else install them via the correct incantation on the command line.
As for APK archive sites, presumably coverage of languages/screen sizes/CPU architectures with few users might get worse, as one user uploading an individual APK version will no longer be enough to automatically cover all languages/screen dimensions/etc. and instead you need to grab separate APKs for each possible language/screen size etc.
Getting the APK with the correct CPU architecture (where applicable) will of course be critical, although in practice almost everybody is probably using ARM these days, so there's not much to go wrong here (although if you still have a 32-bit device then you can only run the 32-bit APK, whereas the other way round a 64-bit device can run both 32- and 64-bit native code).
As for language and screen density, my guess would be that Android can fall back to whatever language and screen density APK actually has been installed (since this should be the same situation as when a monolithic APK doesn't contain the correct resources for your preferred language/screen density), so you might get a degraded experience (wrong language, either blurry or unnecessarily-high-resolution graphics), but the app at least still runs.
[1] Although given the potentially large size of native libraries, separate APK versions for differing CPU architectures already aren't that uncommon.
> As others have asked though, how does this effect side-loading?
It doesn't.
APKs are still the end format.
It doesn't.
APKs are still the end format.
As an app developer that does the release build and the uploading myself, having Apple and now (finally!) Google do the app thinning themselves saves me a ton of work. I'm also way more confident it's done the right way.
If you are worried about Google tampering the apps now that they sign the apps themselves, well I've got news for you: guess who owns the *OS* on which the apps run.
If you are worried about Google tampering the apps now that they sign the apps themselves, well I've got news for you: guess who owns the *OS* on which the apps run.
"The other issue is that developers will need to give Google their app signing key to export an AAB app as an APK. This gives Google quite a bit of power."
Does iOS have the same situation? This sounds so bad that I would switch. Although iOS being closed source I suppose it is just as bad or worse
Does iOS have the same situation? This sounds so bad that I would switch. Although iOS being closed source I suppose it is just as bad or worse
Yes, for quite some time.
Bitcode is signed by Apple Store for watchOS and tvOS applications.
Additionaly Google is now copying Application thinning that has existed for years on iOS.
By the way, UWP Apps on Windows Store work in a similar way.
Bitcode is signed by Apple Store for watchOS and tvOS applications.
Additionaly Google is now copying Application thinning that has existed for years on iOS.
By the way, UWP Apps on Windows Store work in a similar way.
This won't hinder app sideloading, right? RIGHT?
[deleted]
I was just trying to explain this the other day. Not sure whether to be disappointed in is this a regression?
No, bros, you may not just `repack it` and re-sign the package for me. That's not how it should work unless I trust their build server to sign for me; and I don't and we shouldn't. I'll just CC this here from https://westurner.github.io/hnlog/#comment-27410978 :
```
> Unfortunately all packages aren't necessarily signed either; "Which package managers require packages to be cryptographically signed?" is similar to "Which DNS clients can operate DNS resolvers that require DNSSEC signatures on DNS records to validate against the distributed trust anchors?".
> FWIW, `delv pkg.mirror.server.org` is how you can check DNSSEC:
> The TUF Overview explains some of the risks of asset signature systems; key compromise, there's one key for everything that we all share and can't log the revocation of in a CT (Certificate Transparency) log distributed like a DLT, https://theupdateframework.io/overview/
> Certificate Transparency: https://en.wikipedia.org/wiki/Certificate_Transparency
> Yeah, there's a channel to secure there at that layer of the software supply chain as well.
> "PEP 480 -- Surviving a Compromise of PyPI: End-to-end signing of packages" (2014-) https://www.python.org/dev/peps/pep-0480/
>> Proposed is an extension to PEP 458 that adds support for end-to-end signing and the maximum security model. End-to-end signing allows both PyPI and developers to sign for the distributions that are downloaded by clients. The minimum security model proposed by PEP 458 supports continuous delivery of distributions (because they are signed by online keys), but that model does not protect distributions in the event that PyPI is compromised. In the minimum security model, attackers who have compromised the signing keys stored on PyPI Infrastructure may sign for malicious distributions. The maximum security model, described in this PEP, retains the benefits of PEP 458 (e.g., immediate availability of distributions that are uploaded to PyPI), but additionally ensures that end-users are not at risk of installing forged software if PyPI is compromised.
> One W3C Linked Data way to handle https://schema.org/SoftwareApplication ( https://codemeta.github.io/user-guide/ ) cryptographic signatures of a JSON-LD manifest with per-file and whole package hashes would be with e.g. W3C ld-signatures/ld-proofs and W3C DID (Decentralized Identifiers) or x.509 certs in a CT log.
```
FWIU, the Fuschia team is building package signing on top of TUF.
```
> Unfortunately all packages aren't necessarily signed either; "Which package managers require packages to be cryptographically signed?" is similar to "Which DNS clients can operate DNS resolvers that require DNSSEC signatures on DNS records to validate against the distributed trust anchors?".
> FWIW, `delv pkg.mirror.server.org` is how you can check DNSSEC:
man systemd-resolved # nmcli
man delv
man dnssec-trust-anchors.d
delv pkg.mirror.server.org
> The TUF Overview explains some of the risks of asset signature systems; key compromise, there's one key for everything that we all share and can't log the revocation of in a CT (Certificate Transparency) log distributed like a DLT, https://theupdateframework.io/overview/
> Certificate Transparency: https://en.wikipedia.org/wiki/Certificate_Transparency
> Yeah, there's a channel to secure there at that layer of the software supply chain as well.
> "PEP 480 -- Surviving a Compromise of PyPI: End-to-end signing of packages" (2014-) https://www.python.org/dev/peps/pep-0480/
>> Proposed is an extension to PEP 458 that adds support for end-to-end signing and the maximum security model. End-to-end signing allows both PyPI and developers to sign for the distributions that are downloaded by clients. The minimum security model proposed by PEP 458 supports continuous delivery of distributions (because they are signed by online keys), but that model does not protect distributions in the event that PyPI is compromised. In the minimum security model, attackers who have compromised the signing keys stored on PyPI Infrastructure may sign for malicious distributions. The maximum security model, described in this PEP, retains the benefits of PEP 458 (e.g., immediate availability of distributions that are uploaded to PyPI), but additionally ensures that end-users are not at risk of installing forged software if PyPI is compromised.
> One W3C Linked Data way to handle https://schema.org/SoftwareApplication ( https://codemeta.github.io/user-guide/ ) cryptographic signatures of a JSON-LD manifest with per-file and whole package hashes would be with e.g. W3C ld-signatures/ld-proofs and W3C DID (Decentralized Identifiers) or x.509 certs in a CT log.
```
FWIU, the Fuschia team is building package signing on top of TUF.
Koiwai(2)
APK is an antiquated format that originates from Java Jar over two decades ago. It's basically a zip file with some internal structure for signing a manifest of hashes. Google already had to bastardize the APK format to move the signature to ZIP metadata, but there were still tons of problems around key rotation and distribution of large APKs.
This is a natural evolution of the format. It's good for the ecosystem. Whatever guarantees were supposedly provided by having developer (poorly) store their own signing keys are better handled by Google's own infrastructure.
This is a natural evolution of the format. It's good for the ecosystem. Whatever guarantees were supposedly provided by having developer (poorly) store their own signing keys are better handled by Google's own infrastructure.