Starting in August, Google will require that they sign apps, not you
twitter.com
twitter.com
Certainly, they now have the option of trying to force google into delivering modified apps to certain people. This situation changes the trust model for e.g. signal from "do you trust the app developer" to "do you trust google" against the pressures of hacking and legal requirement of cooperation. The fact that reproducible builds become _that much_ more difficult with this is extra bad. It takes away a rather effective "after the fact" detection mechanism for these kinds of abuses.
It seems obvious to me there are plenty of important app developers (like signal) that are less likely to bow before the long arm of the US than the google play store. Also because for a principled developer, their app is likely 100% of their business. Whereas for google, any app is only a small part of their business. Google simply has much less incentive to defend the users of a single app that the developer.
Hence, it seems to me that this situation is realistically going to lead to more ways for law enforcement to access secret data on your devices. Whether this is part of the motivation for this change or not, the effect seems unavoidable.
Regards pre-Snowden, the situation was far more than an "open secret", there were multiple documented projects and methods employed. Among them:
- 2013: Hemisphere, an AT&T call records database dating to the 1980s accessible by the US DEA. (This was publicised near-simultaneously with Snowden's own 2013 disclosures.) https://www.eff.org/cases/hemisphere
- 2006: Mark Klein and the Room 641A revelations concerning AT&T's beam splitters: https://en.wikipedia.org/wiki/Room_641A
- 2005, William Binney and J. Kirk Wiebe, NSA whistleblower, warrantless surveillance. https://en.wikipedia.org/wiki/William_Binney_(intelligence_o...
- 2004, Russell Tice, NSA surveillance including of congressional members. https://slate.com/news-and-politics/2006/01/why-nsa-whistle-...
There were very strong suspicions around the TIA (total information awareness) and USA PATRIOT ACT (2003, 2001). I recall much chatter about this at the time, and the related FISA court, though little by way of specific details of technological measures and methods involved.
Carnivore, a WinNT workstation-based tool, disclosed ~2000. https://en.wikipedia.org/wiki/Carnivore_(software)
There are telephnic data retention programmes, including MAINWAY (revealed in 2006), containing an estimated over 1.9 trillion call-detail records, and
https://en.wikipedia.org/wiki/MAINWAY
Project ECHELON, with disclosures of varying aspects from 1972 -- 2000. https://en.wikipedia.org/wiki/ECHELON
There are earlier periods, notably addressed by the FBI's own COINTELPRO archives (https://vault.fbi.gov/cointel-pro), though for my purposes I'm considering "modern" projects to be circa 1990 onwards. (COINTELPRO and the Church Committee hearings resulted in substantial changes, at least publically, to US domestic surveillance).
And I've compiled a long list of pre-1990 references of concerns regarding significant technologists who'd warned of the risks of information technology as a tool of surveillance and control, largely as no such list seemed extant: https://toot.cat/@dredmorbius/105074933053020193
I'm well aware that documentation of clandestine and national security issues is difficult to come by, see the TK case for one reason why that is.
But that's also why specific documentation is so valuable and why I'd requested that.
Of course whoever controls the OS and app stores can already access all device data. They don’t need to fiddle with the apps to do that.
Who signs what doesn’t change the threat models.
Signing gives some semblance of control between the untrusted developer and the trusted App Store. It doesn’t do more that stop 3rd party app stores on the link between store and phone.
Sure, but if they lied about that isn't it an open-and-shut case of fraud? What they're doing here instead is obfuscating away everything behind an announcement, so there is no legal recourse for the consumer against their bullshit. The best we can do is hope an anti-trust suit is brought against Google (I have approximately zero hope of it happening because of this, though).
It might be helpful to consider a simpler situation, where an FBI agent pretends to have a shipment of drugs which a drug dealer attempts to buy. If the dealer hands over money and doesn't receive the drugs, my non-expert understanding is that they can't then sue the government for fraud, presumably because of qualified or sovereign immunity.
The reason the government won't give back the money is that it will initially be evidence, and then subject to civil asset forfeiture. I don't believe that it matters that the item being bought was illegal, as if property law doesn't apply to illegal goods, since, in theory, if one drug dealer stole drugs from another drug dealer, the government could prosecute the perpetrator for both the theft and the possession of the drugs.
https://arstechnica.com/tech-policy/2018/07/judge-slams-fbi-...
People have this notion that the court system just blindly agrees with three lettered agencies, when in reality they tend to hate each other.
The Android system one that comes from the OEM? Or have they compromised the Java installation I have?
The latter being very difficult for Google alone to make output incorrect results.
Really? They wrote the code for a part of it, sure. But that code was compiled by my OEM, and modified to put the OEM's extra little bit of sauce on there. Besides, the certificates aren't shown to me. They are used by the OS itself to verify updates to the app.
Currently, signing gives control between a trusted developer of an app and any updates reaching my phone. This is enforced at the OS level. That means that the app store cannot just ship my phone false updates. At least, unless they can exploit the currently installed OS.
Hence, google play store cannot just give my an updated backdoored version of signal or whatsapp unless they can get those developers to sign it. With this new system google could unilaterally decide to push such an update. Either to everyone, or just to a few select people.
> Who signs what doesn’t change the threat models.
It very VERY much does. He who signs is he who is able to modify code. If it did not, what value do signatures even have? It seems you are arguing that, since google already controls android, they already control this data anyway. Thing is, the OS on my phone is already on there. Updates need to go through the manufacturer, and are hard to target. The play-store itself cannot read my signal messages.
Hence, for google to read my signal messages, right now, they would need to have a pre-existing backdoor in android, or run an exploit through the play-store. With the new system, they could just push an update to my signal app. (If signal were to use the new system). That, in my opinion, warrants changing the threat model quite a bit.
Sure, just like how if you let's say own Google Play Store and own those updating keys, you can change it (selectively most likely) to skip checking the signed updates.
They own the full pipeline so if they want, you really stand no chance unless you're running your own OS.
The ENTIRE POINT, of this scare is that currently, google does not have access to those keys, developers do. And the signatures on these apps are checked by the OS, not the play store.
Notably, google can't change the OS on my phone at their whim. They'd need to release a new version and get Samsung (and maybe my carrier) to ship that OS to me.
It's a verification made by the OS itself. F-Droid themselves compile and signs the binaries offered by their repository, which everyone seems to be fine with. I believe they're also working towards reproducible builds to let others independently verify the compilation matches the source code.
Apps that currently provide reproducible builds: Signal, Threema, Telegram. (Probably others as well.)
[1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.
This is the same process that package maintainers (e.g. Debian, Mozilla, Tor) go through to produce reproducible (i.e. verifiable, deterministic) binary packages: they enable arbitrary users to run a copy of the packaging + distribution infrastructure on their own machine, such that they can watch it all go and see that it spits out the same thing the remote server does.
However, it also makes developer signing harder (so google decided to eliminate it) because every app bundle is going to be a different file. As a side effect, this also kills 'reproducible builds', unless the bundling process by google is itself reproducible.
> This means that Google can (or can be forced to) distribute backdoored versions of popular apps to targeted people. The app you are downloading may be different from the app your neighbour is downloading. And the app signature will be perfectly valid for both of them.
Google already controls the operating system, the installer, and the SDKs you used to develop your Android app in the first place. If they wanted to backdoor your app there are already plenty of opportunities to do so at multiple levels throughout this chain. Retaining your own signing keys does not eliminate this potential threat, so you still have to trust them. If you don't, then you should avoid using Android entirely.
They really really don't need to touch your APK to get any user or app data. If you don't realize that, you may have been thinking of wrong threat models.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
If it's bound by the OS permission system and doesn't have full root, it might be able to replace apps with another version that is signed by a different key (using the "programmatic app installing" permission). However, that would wipe the app data and break app updates. Not even adb can replace an app with one that is signed by a different key without data loss (adb install -r). And I'm sure a lot of developers ask for this feature.
(I haven't actually tried whether you can really successfully switch signatures on an APK that way without losing all user data, tough)
Additionally, starting from Android 10 it seems that there is a new official feature allowing data to be kept after uninstallation if an app opts-in (https://stackoverflow.com/questions/58750567/how-to-enable-o...).
I think you have far too much confidence in this. How exactly would the average Android developer check to see if the SDK they downloaded from Android Studio doesn't have a targeted exploit in it? Or Android Studio itself for that matter?
Or perhaps it makes more sense to not consider the developer of your operating system to be adversarial.
Yes, I've stripped, patched and re-signed apps and verified that installing them as an update failed.
For various reasons I think it's reasonable to assume it's more difficult to be running a phone with a compromised OS (particularly given the bootloader is unlockable and you can install a 100% OSS ROM) than to assume the Play store is not serving something malicious.
Besides, the worry is not "Google Evil". The worry is "Google might be coerced into compromising a specific user". For that usecase, presuming google is _not_ evil and has not backdoored pre-existing android installs, signed updates to apps actually help a lot.
As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app. This is not about "protecting ourselves from Google". This is about making it as hard as possible for google to do bad things, so it is harder for outsiders to influence Google.
I think that, for the argument you are making, the play-store is the strongest point. I am unsure of how deep the privileges of the play-store run, but it has more control than most apps, and is easily google controlled. I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.
But that is the whole point. People are apparently concerned about a backdoor using one channel and not in another, which makes little sense. Either you trust Google or you don't. "It would be a little trickier to ship a bad OS version / WebView implementation / GMS implementation" isn't an especially meaningful approach.
> As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app.
I don't believe there is any evidence for this.
> I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.
If you are specifically worried about Signal then this change does not affect you because this is only a requirement for new apps. This is one reason why I find the argument that this is all a backdoor for the NSA so ridiculous. People seem to be claiming that the NSA has the strength to strongarm Google to implement a feature like this and roll it out for years (App Bundles have been around for a long time as an option) and is willing to wait for basically the entire market to turnover so that privacy-critical apps are all using this feature but can't force a change at the OS level that works universally.
It's less straightforward to backdoor the OS/sdk because it's open source and built by various vendors. AFAIK the play store doesn't have a custom installer to handle installs, that's handled by the operating system itself. The play store has special permissions to install apps programmatically, but AFAIK it doesn't have ability to bypass the signature check, which is why this change is being made in the first place.
As it stands if you buy a normal android phone, then you must trust Google.
1. you still need way more parties involved (eg. OEMs, chipset makers), unlike google which probably has acesss 95+% of the non-chinese android phones.
2. backdoors involving the SDK/OS are far less discriminate and therefore has higher risk of detection by third party researchers. (eg. https://www.xda-developers.com/mediatek-su-rootkit-exploit/)
If you wanted to add the exploit to the kernel, there are plenty of hooks to do so that would not require the kernel to be recompiled (e.g. a loadable module, or BPF). Again, these could be targeted at specific individuals, or groups of individuals.
Still, Google is extremely unlikely to add any backdoor willingly, and unlikely to add one in general. And more to the point, controlling the signing keys for a specific App does not make it easier to backdoor someones phone.
Open source doesn't protect you at all against Google.
edit: Actually I don't even know that the App Store has permission to uninstall apps. If it doesn't, then it can only update apps that are signed with developer keys.
As for backups, apps have control over which data can be backed up. Google cannot access app data if the app doesn't consent to it, assuming the Android OS itself is not somehow compromised.
https://developer.android.com/reference/android/Manifest.per...
Skimming the permissions file shipped with opengapps suggests that play store has it.
<privapp-permissions package="com.android.vending">
[...]
<permission name="android.permission.DELETE_PACKAGES" />AFAIK the OS has checks to prevent "updating" to an APK with different signature.
>The Play Services have silent permissions to backup and restore app data.
It looks like apps can opt out of it. https://developer.android.com/guide/topics/data/autobackup#E... It's unclear whether this is enforced by the OS or google play services.
Not for devices running Google Play Services. If your device is running AOSP with absolutely zero Google services then maybe that's the case (although I'm not even sure that's true at the firmware/driver level), but if you'll never use the Play Store then Play Store restrictions don't really affect you in the first place.
I also think you're seriously underestimating or misunderstanding the potential attack vectors here. You don't need to deliver a blatantly obvious backdoor that can be easily found in the AOSP source code. Consider the history of 0-day RCE exploits on the Android platform and then consider the fact that such exploits can be subtly introduced in a non-obvious way that gives you plausible deniability if discovered. Now consider that you have your own closed-source and privileged code running on billions of Android devices that could take advantage of the 0-days you introduced yourself.
Compare that to if google has the signing keys for updates to whatsapp. Then the national security letter could just state "hey, here is an update to whatsapp, please sign it with the appropriate keys". That is so much harder for Google to refuse.
I have a lot more faith that google would not comply with the first national security letter than with the second.
It seems to me that if one approach is so politically unacceptable as to be quite unlikely, and the other approach is so politically acceptable as to be feasible, that is highly relevant.
In the first scenario, this is just a hypothetical attack google could do if they were evil. In the second scenario this is a realistic attack we need to consider could happen. The difference between "hypothetical" and "realistic" matters quite a bit.
The second case was apparently feasible enough that the FBI thought it was worth trying in open court. I don't think the first case is that dissimilar. And I think there is a decent chance that the NSA/CIA has stronger pressure methods than what the FBI tried in the San-bernedino case.
And if not, it seems quite a bit more feasible for new legislation to be written that could be used to force google to cooperate with malicious update signing. It certainly fits with the theme of recent "we should be allowed to read your messages" legislation attempts. Heck, I think it would be one of the more reasonable ways to implement such legislation.
Hypothetical new legislation could require you to download a NSA rootkit on all of your devices too. Nothing about this feature is uniquely weak to arbitrary legislation.
By that I mean, would it be possible that 2 different people download the app from the Play store, one of them gets an unmodified version of the app and the other (perhaps based on the user's race, country of origin, etc.) gets an on-the-fly modified version of the app.
The developer - and likely 99+% of all users - would never know or even be able to tell because most copies of the app in existence are 100% what the developer created. But, for a few rare birds, backdoors are aplenty.
Regardless, I'm 100% against this. But, my thinking above is this is possibly far worse than I initially imagined.
Apple calls this approach "app thinning".
Also remember that Google Play Store could serve whichever APK it liked right now - the signing keys aren't surfaced in UI on Android (or iOS for that matter).
Remember, Microsoft got in trouble for just pre installing internet explorer. There was no blockage or anything preventing you from installing any other browser and use it without any limitations.
I am curious what are good solutions to this problem? Compile your OS (and any other software) from source?
You have to rely on a distribution that has a many-eyes review policy and has security conscious users.
That's blatantly understating how many packages are reproducible.
Multiple people can grab the sources from the developer, review and apply the patches, build the package and publish the resulting hash. With reproducible builds, all people end up with the same hash, which should also be the same for the pre-built package in the repository.
In other words, instead of trusting one single person (the maintainer) you split the trust across multiple people. This is definitely an improvement thanks to reproducible builds.
And, there are large tech firms doing this already.
With the upcoming change, we loose this verification when using Google's app store.
Developers can still create key pairs themselves and upload them to Google. So they can still publish their public key if they want and you can be certain that APKs distributed from somewhere other than Play were definitely signed by the developer.
I think this is exactly the bit people don't like. I don't want them to "own" my operating system.
In the case of Apple, I agree. It doesn't make sense to use their ecosystem without trusting them fully.
However, in the case of Android / Google Play, right now the developers have the option to choose between APKs and App Bundles. Why take away that choice? If App Bundles are superior, then developers will choose that option freely. (Google Play is already really pushy when recommending to use App Bundles.)
Upstream can sign or otherwise indicate integrity (e.g., Git revision checksums) of all individual source files. This ... becomes tedious to check, but can be checked against Debian sources to identify where any changes might reside. Note that this still applies only to sources rather than builds, though it's an option. It's likely not an option in wide use.
Debian also ships sources rather than builds, which can be built directly on your own systems (or within your own build-and-distribution network). Debian's had a "reproducible builds" initiative for some years (https://wiki.debian.org/ReproducibleBuilds), and this covers a fair number of packages (I don't have a count offhand), though there are notable exceptions of packages which are simply too complex to build reproducibly. I think the September 2020 summit notes are the best current overview of status, tools, and issues: https://reproducible-builds.org/reports/2020-09/
And, unlike Google Play, it's possible to download from any arbitrary Debian mirror without authentication. Authentication-prior-to-download could lead to branching logic for user-specific modified packages being delivered. Another option of course being for a generically-modified package that targets a single user or specified set of narrow criteria.
With Google the entire process is completely opaque, they do everything behind closed doors, and can hand different users different blobs on demand.
Ultimately with Google, you only have Google's word for what they're doing, and you know they have the capability to provide different versions to different users on demand of an NSL. With Debian, they have no way to attack a specific user, and you fully have the ability to "check their work."
I wonder if internally they either have this ability or this constraint is only required for non Google app developers?
AFAIK, no, it doesn't; the component which has root is part of the operating system image, and the Play Store merely has the permissions to tell that component to silently install or upgrade a package. However, when upgrading a package, that component will only allow the upgrade if the package is signed by the same key as the previous release. This has more than once led to a package no longer being able to be updated, because the developer was not careful enough with backups and lost the private key.
Not if you want customers.
For apps not enrolled in the Play Store signing scheme, the phone actually verifies directly against the publisher's key, that Google now wants to relegate just as an "upload key". I am saddened by Google's efforts to undermine this fundamental OS security feature. The ultimate goal is clearly to kill off any chance of competing app stores, as developers of new apps distributed through Play Store can now actually never access the key that's supposed to show they control the app, no matter what channel it was delivered through (e.g. Play Store vs. F-Droid.. Really bad for new Open Source apps!)
I do know a bit about PKI. And one option might be that the workflow be something like:
Dev signs bundle => Google signs bundle (including dev signature) => User/Client verifies both signatures.
Google are still signing here, but if the dev signature doesn't verify (or isn't present), there's a post-build modification occurring, which is the principle issue raised in the tweet thread.
While APK backups aren't officially supported and therefore might not factor into the decision making, curiously enough Google itself only recently added a feature to the Play Store which apparently allows direct sharing of APKs between nearby devices. Split APKs however mean that you can only sensibly share apps with devices having the same screen density, language, etc. as your own device, somewhat devaluating that feature again.
It seems this is only required for "Android App Bundles", whatever the hell that is, and not apps.
"Android requires that all APKs be digitally signed with a certificate before they are installed on a device or updated. If you use Android App Bundles, you need to sign only your app bundle before you upload it to the Play Console, and Play App Signing takes care of the rest. However, you can also manually sign your app for upload to Google Play and other app stores."
"And, because app bundles defer building and signing APKs to the Google Play Store, you need to opt in to Play App Signing before you upload your app bundle."
https://developer.android.com/distribute/play-policies#Requi...
"Android App Bundle requirement for new apps and games"
"After August 2021, all new apps and games will be required to publish with the Android App Bundle format. New apps and games must use Play Asset Delivery or Play Feature Delivery to deliver assets or features that exceed a download size of 150MB."
That does make kind of sense, because once you hand over your key and the first user installs your app, you need to use the same key or the user wouldn't be able to update the app. Opting out of Google-side app signing would be kind of useless because Google can keep the keys and sign malicious code in your name regardless, unless you're willing to wipe out your entire install base through a new app.
[1] https://developer.android.com/studio/publish/app-signing#opt...
Maybe they can release a tool to create APKs from App Bundles locally (maybe call it, idk, 'bundletool' or something like that). They could also make it so the Google Play Console allows developers to choose between uploading APKs or an App Bundle, and communicating the pros/cons of both methods. That way, a developer (not Google) can choose which option is best for their business and their customers!
Sound good to me at least (although to be fair, I don't have an ulterior motives or bad intentions)
I dare you to close your eyes and install a random free app on the Play Store or Apple App Store. Chances are high you'll download some malware.
We can have openness and still be thinking of the children. /s
There are two possibilities here: Malice or Incompetence. We'll take Hanlon's razor and assume Incompetence, but it is gross incompetence. It is unacceptable.
> It changes from "We guarantee we will distribute your app unmodified" to ... well, I don't know what you are promising, but it's not that.
The closest analogy would be a universe in which UPS insists you delegate the packaging of your product to them. Your product remains unchanged, but it's packaged with UPS's packaging which (for the sake of this example) may come with better assurance guarantees relative to your own packaging of the product you're shipping.
Point being: (edit: assuming no malicious supply chain interference; I'll get to this) the app is unmodified. Even with Google doing the signing.
I don't inherently see anything wrong with this, though I also don't think any physical carriers have tried this. Anyone have any examples? Even from other subdomains within logistics?
---
Edit: with supply chain interference (compromising build pipelines, etc), who signs the app doesn't really matter; the app is still tampered before it gets to Google's marketplace. The trade with Google compelling their own signing infrastructure is that it reduces the risk of compromised keys for individual development shops enabling malicious actors to sign builds on behalf of the developers.
---
Edit 2: Some pretty great answers and counterpoints here, such as FBA and the resulting uptick in counterfeit goods. Unexpected but good food for thought.
Which to drive it home, if Bob included a signed photo with each of his items I would know if I got the item from Bob or someone else.
It is fraud in two ways: It misrepresents the seller, and it misrepresent the origin.
That it misrepresents the seller is simple: You don't know who provided you the inventory that Amazon is shipping you. You will often get inventory provided by company B when you receipt says company C. When and if you get a defective product, you have a legal case for compensation against company C, but when they didn't provide the product in the first place (company B did), the waters get muddied. You still have a legal case against company C (They're the seller of record, and you got a faulty product). Company C has a legal case against Amazon (they sent a faulty product on behalf of Company C), and Amazon has a legal case against Company B (They were provided a product that was misrepresented)
There's an alternate line of legal reasoning: Make Amazon the seller of record. This cuts the gordian knot quite nicely, but Amazon has repeatedly rejected it, because:
Sending you commingled product is fraud when the product is not represented correctly: When you buy a "Genuine Apple Charger" and you get a cheap piece of junk in similar packaging, you are being defrauded. Whenever Amazon commingles a non-genuine product with a genuine product and sends it on to the consumer, that's fraud.
This is a legal monty-hall problem. If you lay it all out and examine all of the branches individually, it is quite clear: At some point down each of the lines, Amazon has committed fraud. Either fraud against the consumer, or fraud against it's partners, but regardless: Harm has been done to the consumer and that harm was introduced by Amazon. The harm was introduced when Amazon bucketed the faulty products with the non-faulty products, and thereby destroyed the chain of custody of where it came from. IFF Amazon took careful notes and marked each item with it's origin, then they could pass the blame on to Company B (Where it really belongs), but they didn't, and as such are liable for Company B's misdeeds that they have laundered.
Problem: you have no way to prove it. Nobody can prove it.
That’s what developer signing proves - that is hasn't been modified.
The difference is that you used to be able to verify that Google didn’t modify the app. They simply couldn’t make a change while keeping the signature intact.
Now they can, they just say they won’t and expect you to trust their word.
In theory this can be verified by the developer though? Signing an app shouldn't (I haven't checked this in Google's case) change any integrity values for the app code itself, so the developer (though no one else) is still able to ensure Google wouldn't have tampered anything.
But your point makes sense.
So it is working as intended if what is installed on some device is not what the Dev built.
There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped.
But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys).
I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.
I used to do J2ME app development back in the day. It wasn’t unusual for our apps to have 200+ builds. These weren’t just different assets, they also included workarounds for device specific bugs (j2me phones were buggy as hell, especially Samsung phones). In some cases we even had multiple builds for one phone, because carriers liked messing with the firmware. Vodafone was notorious for this.
When Android and iOS took over we finally could leave that behind, at least for a while, then Android started fragmenting like crazy and now we’re almost back to square one.
I think you are underestimating the number of versions.
And why would developers want to do this? This adds a huge pain in the ass to all deployments.
> Google could come up with a new app format whereupon there were a signed manifest of files
They could. But this wouldn't be backwards compatible. So you are stuck waiting like eight years for the ecosystem to all adopt the new OS versions.
This is true and "too cumbersome" is worth expanding on. Without specific targeting what is delivered to the device, 100s of MB of storage can be wasted after the APK is uncompressed. The data that is unused can't be deleted but is unusable or unneeded on that device.
When specifically targeting a single device you have multiple axes to target:
* 4 native CPU architectures: [x86, x86_64, armeabi-v7a, arm64-v8a]
* resource DPIs: [ldpi, mdpi, hdpi, xhdpi, xxhdpi]
* 6+ SDK targetSdks with meaningful feature variances (basically potential features enabled/disable every year for the last 7-8 years).
* 80+ individual languages
If the goal is to exactly match the device/user in question, you'd need to generate and apply appropriate versionCodes for: 4 * 7 * 6 * 80 = 13440 individually, versioned, signed and uploaded APKs.
Of additional note, the versionCodes must be precisely ordered to ensure the right version is selected. A device will get the highest version which is compatible with the device. So if an x86 version is higher than x86_64 a 64 bit device that can handle both will still get the x86 instead of the x86_64 version. Same goes for DPI ordering and SDK ordering.
Think the worry is google (and perhaps certain US agencies) will use this new requirement to do essentially the same approach with certain apps.