The title is misleading on a technicality though - Android will continue to deploy applications via APKs. Developers will have to upload apps as AppBundles, which the Play Store service will repackage, resign and deliver to the devices as a set of APKs.
Which means: the devices will continue to be able to install APKs. The major massive difference is that the apps will now be signed by Google on servers and not by developers on their local machines.
I'm wondering why Google doesn't allow developers to build the optimizes APKs still - the Android build system does have that capability. Noone really used it, but it's there - there should be a way to opt out of signing key sharing.
Google has always been able to do that. Just alter and re-sign the APK with their own key(s), since Google's keys are trusted by Google Play Services (third party app stores also trust Google's signing keys for compatibility reasons).
The way the Play Store is currently designed, end users don't even have the ability to view the key-path before installing a package. So detecting if it is Google Vs. app developer's signing key is extremely unlikely without copying that APK off-device and inspecting it.
All users know is: Is this using a signing key trusted by Google? Yay/Nay.
That's true for new installs at least. But Android won't let you install an update to an existing app with a different signing key, it'll error out with something generic.
As an explanation as to why Google has gone down this design path, I think this makes sense. Basically it’s easier to maintain compatibility with existing devices this way.
From a security perspective I don’t think it makes the slightest difference. Google controls the logic that prevents updating apps with a different signing key.
There are so many conceivable ways that Google could inject arbitrary code into each process (e.g. silently cause a different “shadow” app bundle to be launched, play with LD_LIBRARY_PATH, play with the Dalvik VM, modify Java/system libraries, etc) or read processes’ memory, that it’s safe to assume that if Google wants (or is forced to) to modify your app’s behaviour or exfiltrate sensitive data from your device then it’s absolutely within their power to do that.
People are concerned about Google editing code, which would be detectable through the signed code section or just basic decompilation and would be a nightmare for PR. But people are apparently not concerned with
1. Nothing has ever prevented tampering with the signature before first install.
2. Google owns and writes the OS.
3. Libraries like WebView are both security critical and updated via ordinary app updates, and are provided by Google.
4. The dex bytecode isn't actually run on modern devices. Instead it is compiled into an executable by code owned by... Google.
5. The large majority of developers are using compilers and other tooling provided by Google.
This is why the concern over this change is ludicrous. When you installed Signal or whatever for the first time did you check the signature? Did it bother you that it was technically possible for Play to substitute code? No. Because you are using an Android phone and trusting the OS developer is a requirement for everything.
And there isn't a "total lack of chances to stop tampering", since the code section can still be signed with a different key.
So why is everybody suddenly claiming a conspiracy here?
The main threat model is that google is influenced into editing a specific app or few for certain users or locations, not that the company is going to turn the entire OS into a backdoor. So most of your bullet points aren't very relevant. This threat model isn't a "conspiracy" either.
> 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.
It's pretty much useless because no-fscking-body is going to build a service to gather signatures from a bunch of devices in hopes to catch Google in the act.
Yep. The end format is still APK. What is being dumped is the unnecessary libraries/APIs that are not relevant to the device that is receiving the APK.
How forbidding something that is not used makes sense?
They could still let the people who want to produce their own optimized APKs and sign them with their key just do it as before, while defaulting to whatever they plan to do now.
not just signed, but now googles app not your app. this breaks trust and if anyone was trying to market a play store alternative, this and amazons store gives great marketing gristle.
> 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.
This is like having checksums in a Readme. If nobody checks them (and that's the likely case, since the OS doesn't), it doesn't matter if they differ from the distributed files.
It's still the case that Google is taking over the code signing roles, so that the user's OS will no longer tell the difference between a developer signed update and a Google signed update. This is a negative for security and transparency, regardless of the size benefits and regardless of the fact that the Apple App Store has operated in this fashion since the beginning.
Moxie complained about F-Droid recompiling and resigning his stuff. And cited this as his reason to use only the Playstore. But I guess things were more about analytics and control after all.
You are trying to place events which happened in the past under a completely different set of circumstances into the circumstances of today and then are drawing a conclusion from that.
Yes. It is a nice natural experiment as to Moxies motivations and principles, because only a very select set of circumstances has changed: Software authors can no longer control their signatures on Android. That time has passed is not relevant, or at best relevant to explain some change of heart over time.
The argument about size savings is pretty weak too. Any developer who has an app with large native libraries has already been splitting it by CPU architecture since forever. The screen resolution isn't much relevant at all because who even uses bitmap graphics any more when there's VectorDrawable? The strings do take up space, and I was told that the resources.arsc file where they reside isn't compressed in an apk because that would result in Android having trouble reading it, but its size is still usually negligible compared to the rest of the apk.
The size savings though are real in actual apps and they are generally around 15%. People are really desperate here to find ways to make everything a bad thing. Apple does stuff like this regularly.
And the market seems to signal Google that Apple is doing the right thing though? IIRC iOS has passed 60% in USA these days and is repeatedly pushed as a "secure and malware free" OS on HN.
Android's worldwide marketshare is like 75%, though. These marketshare numbers haven't changed all that much for many years; and, to the extent to which they have, the more important battles were destroying all the non-duopoly competition. Even then, claiming that one's pet issue is clearly justified by marketshare is kind of nonsensical considering how complex these device ecosystems are... like, if I were to guess why iOS has better marketshare in the United States I would point to stuff like iTunes and Apple Stores, which might easily be so good in comparison to Play Music and [crickets] that even if they did everything else 100% wrong it might cause people to buy Apple over Samsung (which of course is the real competitor at this level, not Android really).
No, its because Apple is seen as a status symbol, has good brand reputation and locks users in the walled garden. General users don't know what happens behind the scenes.
> In the absence of a strategy to become the primary messaging service for [the] bulk of cell phone users, I am concerned [that] iMessage on Android would simply serve to remove an obstacle to iPhone families giving their kids Android phones.
I just want to add that this is a uniquely US problem. Over here in Russia no one sends SMS or MMS to another person. So, consequently, no one uses iMessage either.
I meant that on HN most people who advocate for Apple do it because they "like the UX" or because "Apple doesn't sell their data as opposed to Google". Yes in the general population iPhones are very much high quality high status gadgets.
Switching to AAB would mean 0.4% savings for my own app. Which already is only 3.4MB large.
I really don't understand why Google is trying to force me into this (even for existing apps, every time you open the console it's just bombarding you with warnings that you don't use AAB).
They could just add a sanity check, if less than 50kB are saved by switching to AAB, just don't recommend/force it.
But they don't want that. Apps created after august won't even let you download the signing key so you could sign non-play store apks yourself. The only way this makes sense is if they want to prevent off-playstore distribution and verification entirely.
You can't, but in my experience, for things like stretchable control backgrounds, a <layer-list> with a bunch of <shape>s does everything you could possibly want.
> The strings do take up space, and I was told that the resources.arsc file where they reside isn't compressed in an apk because that would result in Android having trouble reading it, but its size is still usually negligible compared to the rest of the apk.
If you've localized to lots of languages, it starts getting big. I may be misremembering, but I think it was about 8 MB of the 30ish MB apk at my last job (before some heroic work to move most of the strings outside the android framework)
Is there a community that's keeping the FOSS nature of Android? I'm not talking about fdroid, they are great.
I'm asking about a community/fourm that is discussing how Android can be separate from Google in the distopian future. Anyone know of a website where this is discussed?
The LineageOS folks are the main developers of a non-Google version of Android. For actually running it without Google services you'll need microG, which seems to be worked on by one lone German developer.
According to rumors, a big "extra benefit" Google receives is that Windows 11 will be able to directly run APKs. So, retire the universal APK so people on Windows get odd and incorrect experiences with incorrect feature mixes.
I don't understand how this change has anything to do with Windows 11 APK support? Hell, Microsoft didn't even work with Google, considering they're using the Amazon App Store, and this change is specific to Play Store. AFAIK Windows 11 runs APKs directly, app bundles play no role there.
I am not sure it is any way better right now. Is there even a way a user can check who signed the apk unless he has his unlocked android device hooked up to a PC with android dev. tools installed and a black belt in android development?
AFAIK you can't easily check keys, but current behavior is still much better:
1. Android only allow you to update existing apps with APK signed by the same key. Google can't just push you update that gonna steal app data.
2. After you installed an app through Google Play you can safely update it from different APK source and know that it signed by correct developer. This is helpful when app you being using through Google Play blocked in your country or something.
Re: 1 - Sure they can. The play store has the ability to both uninstall and install apps without direct user input. Even if the OS itself blocks updating an app with a different key, it doesn't block uninstalling and then reinstalling with a different key to my knowledge.
AABs are hardly required for Google to inject their own code into apps. And honestly, why would you even be concerned about them injecting code into third party apps? If they really wanted to be malicious they could use system apps that they fully control anyway.
I do have concerns with Google removing the ability for developers to sign apps but Google themselves acting maliciously isn't why.
I believe it's possible to keep an app's data on uninstall. It's not the default behavior, but that doesn't really matter in this case.
> Much harder for Google (or anyone legally mandating them) to get caught with AABs though.
Not really. And what does "legally mandating them" even mean? This is a policy change for the play store, it has nothing to do with legality.
> ... in addition to a bunch of security issues. Also makes it possible to do forced monetization, like YouTube has done.
The "security issues" exist regardless of this policy change - as I've already said, Google could easily do whatever they want with your phone anyway due to control over system apps and the OS. I have security concerns with Google being the sole owner of the signing keys, but that's not related to Google themselves acting maliciously.
As for "forced monetization", that's just reaching - if they were going to force monetization on apps that weren't their own then they just need to require it of developers on the play store. How does the ability to ship modified bundles make this any easier for them?
> I believe it's possible to keep an app's data on uninstall. It's not the default behavior, but that doesn't really matter in this case.
It's not and it does matter.
> And what does "legally mandating them" even mean?
Not sure how what's unclear about "legal mandate". If the law says, Google complies.
> The "security issues" exist regardless of this policy change - as I've already said.
They don't exist to the same extent, you repeating them doesn't make them more universal or true. Other vendors and forks exist, the simple existence of Google Play didn't mean every app is compromised by Google, now it will.
> Google could easily do whatever they want with your phone anyway due to control over system apps and the OS
Google doesn't control every vendor, controlling all signing keys is much easier than quite literally backdooring the OS for simply Google. There's a large difference in how visible any such malicious actions would be.
> As for "forced monetization", that's just reaching
Are YouTube's forced midroll ads "reaching" as well? There's no fundamental difference, they monetized someone else's content.
Controlling signing keys allows to simply patch the ads in. I'm not entirely sure why you don't see how it makes it easier for them.
I was mistaken - you're right that you can't keep app data. It still doesn't matter because they already have easier ways of running whatever code they want on phones with Google play.
> Not sure how what's unclear about "legal mandate". If the law says, Google complies.
I mean that I don't understand what your original statement was. Is it that governments can force google to hand over your signing keys? I agree that it is a concern, it just isn't the issue I was commenting on. I didn't mean to bring that into this - I just didn't understand your meaning.
> Google doesn't control every vendor
They don't need to. They already have system apps on every phone running Google play, which is the exact same list of devices that will be affected by this change. You're right that they don't control every (or even most) OS vendors for Android, but they don't need to.
> Are YouTube's forced midroll ads "reaching" as well? There's no fundamental difference, they monetized someone else's content.
I'm not debating whether midroll ads are right or wrong, I'm debating the technical merits of this incredibly roundabout method.
"Patching ads in" on an app-by-app basis is nonsense - why not just add it to some hooks in Google play services? Not to mention they'd have to make sure it doesn't break the apps themselves. Why waste the time and money? Hell, force app developers to insert code into their own apps by changing the policies on the store. I bet it's result in a lesser outcry than if they did it secretly. Signing keys as a conspiracy to show more ads is ridiculous when they have better vectors elsewhere.
So? Presumably you are going to continue to interact with the app.
> .. in addition to a bunch of security issues.
What security issues?
> Also makes it possible to do forced monetization, like YouTube has done.
Forced monetization is an even stupider conspiracy than NSA spying since it would require wide use rather than targeted changes. This would be plainly obvious since there are loads of people who decompile apps and the signature on the code section would be broken.
nit: Google doesn't get the source code. It gets essentially the contents of the APK (compiled DEX code, compiled native code, assets, and resources) along with some additional protobuf files that contain metadata. Google can then decide how to split that up into APKs, generate those, and sign them. In theory Google could add or alter things before signing them.
The alternative to this was called Multi-APK and hardly anyone used it. It required generating and uploading a large number of different APKs and then uploading gigabytes of mostly-redundant APKs to the Play Store. That allowed you to manage the signing and minimize install size, but it was such a pain to orchestrate that it wasn't practical in most cases.
That's a very narrow technical view of the thing. It's pretty much only a .zip after AAB. You're losing universality, signature checks, tamper-resistance which made apks apks.
From Google's perspective, it increases flexibility and the overall installation process for Google Play, and probably (speculating) cuts down on costs over the long-term.
From the broader perspective of the Android ecosystem, it's debatably monopolistic behavior. Google's defense by showing alternative app stores on Android gets slightly weaker.
Signatures are only checked for consistency on updates. From a technical perspective, this was always possible for first installs. If you are concerned about Google being malicious, don't use Android. This entire discussion is just bizarre.
Wellp, guess who's not distributing their game through the Play Store. It's open source but I thought I might put it on Play for a nominal price and invite those who want it free to compile it themselves. But now? It'll be F-Droid only for me.
For inclusion into their official repo F-Droid requires you to either make sure each build is verifiably reproducible, in which case they will let you sign that build yourself, or else they need to sign it just like Google will now be doing. They used to always require that they sign it, without offering the exception for reproducible builds. They also support publishing parallel versions with both their signing key and yours, to help with smoother upgrades for users with the app already installed.
They do allow you to make your own separate F-Droid binary repo which doesn't restrict your ability to use your own signing key, but then you have to get users to add your repo.
Which means: the devices will continue to be able to install APKs. The major massive difference is that the apps will now be signed by Google on servers and not by developers on their local machines.
I'm wondering why Google doesn't allow developers to build the optimizes APKs still - the Android build system does have that capability. Noone really used it, but it's there - there should be a way to opt out of signing key sharing.