Google sunsets the APK format for new Android apps
androidauthority.com
androidauthority.com
Disclaimer: I'm not an app developer, but works in PR and marketing.
> user engagement and revenue stream
Well, if you're making an app for the sole purpose of making charts go up...
>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.
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.
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.
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.
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.
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.
Apple and Google can eat a d#%$
It should make you think a little about how things are done in Silicon Valley.
A little tougher now that the current companies have the government on their side.
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) .
I don't feel crazy enough to waste time in things that can't exist without me permanently touching it for no reason
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.
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?
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 ...
> 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 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.
Yep Apple envy could do some good to the development experience on Android.
I can't even.
https://android-developers.googleblog.com/2021/06/the-future...
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.
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.
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.
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 also incorrect, if people have apps signed with your signing key then you must provide it to Google.
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.
Out of loop, what changed?
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!
> 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 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).
> 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?
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...
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.
( for example spotify )
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.
Isn't that logic backwards? Precisely because the ecosystem is bloated they're doing something about it in a place they can?
It's still present.
AOSP still exists and is still updated.
Pixel devices still have unlockable bootloaders.
Your fear is still unfounded.
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?
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.
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.
It doesn't.
APKs are still the end format.
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.
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
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.
```
> 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.
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.