Google Play Dumps APKs for the More Google-Controlled “Android App Bundle”(arstechnica.com)
arstechnica.com
Google Play Dumps APKs for the More Google-Controlled “Android App Bundle”
https://arstechnica.com/gadgets/2021/07/google-play-dumps-apks-for-the-more-google-controlled-android-app-bundle/
80 comments
One important distinction is that now Google is able to inject code to apps without notice since they are the ones who sign the final APKs.
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.
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.
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.
A threat model that only concerns updates and not new installs is incoherent.
Less incoherent than a total lack of all chances to stop tampering though.
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?
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.
Is that true if you use code transparency signing key?
https://developer.android.com/guide/app-bundle/code-transpar...
https://developer.android.com/guide/app-bundle/code-transpar...
Yes.
> 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.
> 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.
This doesn't affect sideloading in the slightest.
This doesn't affect sideloading in the slightest.
> I'm wondering why Google doesn't allow developers to build the optimizes APKs still
> Noone really used it
I think you answered your own question
> Noone really used it
I think you answered your own question
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.
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.
[deleted]
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.
There goes Moxies justification for using only the Playstore for Signal...
And I'm waiting for the first supply-chain attack resulting from Google signing a rootkit, Microsoft-style...
And I'm waiting for the first supply-chain attack resulting from Google signing a rootkit, Microsoft-style...
AAB supports a code transparency feature: https://developer.android.com/guide/app-bundle/code-transpar...
> 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.
> 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.
> There goes Moxies justification for using only the Playstore for Signal...
Moxie is fine with this state of affairs on iOS - I'm not sure why this would change anything on that front?
Moxie is fine with this state of affairs on iOS - I'm not sure why this would change anything on that front?
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.
Moxie can use F-Droid with his own signature if he supplies a reproducible build.
https://f-droid.org/en/docs/Reproducible_Builds/
https://f-droid.org/en/docs/Reproducible_Builds/
Which in theory Signal supports; anyone tried it lately ?
https://github.com/signalapp/Signal-Android/tree/master/repr...
https://github.com/signalapp/Signal-Android/tree/master/repr...
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.
iOS has been a fully controlled walled garden since day one though, while Android was supposed to be the "free" open source alternative.
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).
> Android's worldwide marketshare is like 75%, though.
Android’s only competition has intentionally priced itself out of affordability for two-thirds of the world’s population.
Android’s only competition has intentionally priced itself out of affordability for two-thirds of the world’s population.
It's pushed because Apple is seen as less privacy intrusive.
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.
For example, https://www.theverge.com/2021/4/27/22406303/imessage-android...
> 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.
For example, https://www.theverge.com/2021/4/27/22406303/imessage-android...
> 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.
> No, its because Apple is seen as a status symbol, has good brand reputation and locks users in the walled garden.
Or, you know, maybe, just maybe, people actually, genuinely enjoy using these devices.
Or, you know, maybe, just maybe, people actually, genuinely enjoy using these devices.
No contradiction here: being owner of a status symbol is enjoyable experience with very rare exceptions.
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.
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.
>who even uses bitmap graphics any more when there's VectorDrawable
A lot, I would bet. Can you even 9-slice a VectorDrawable?
A lot, I would bet. Can you even 9-slice a VectorDrawable?
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)
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)
App Bundle has significant advantages:
1. Reduction in APK Size. Not just native libraries, this gives ability for Google to optimize downloads based on screen size, locale etc.
3. Enables dynamic features. End users can download parts of app only when they need it.
1. Reduction in APK Size. Not just native libraries, this gives ability for Google to optimize downloads based on screen size, locale etc.
In countries where data still costs $$$, its a significant boost to both end user and developers (Reduce size = increased no of downloads).
3. Enables dynamic features. End users can download parts of app only when they need it.
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?
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.
The most popular FOSS ROM communities probably have the biggest interest in this e.g. GrapheneOS, CalyxOS, LineageOS.
Remember when we thought an alliance of Samsung, HTC, and LG would keep Android alive no-matter what Google would do?
Oh those were the years...
Oh those were the years...
Consider GNU/Linux phones, Librem 5 and Pinephone, instead.
www.googlehaswon.com/buyadumbphone
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.
APKs don't magically stop existing. This doesn't have any effect on other app stores.
Yes but if android changes it's format then people will stop publishing APKs for new versions.
No. Devices will still get APKs, but they'll be optimized and signed by Google. ( https://news.ycombinator.com/item?id=27711002 )
Good luck finding the correct version that matches your DPI and arch. Bunch of really "fun" malware campaigns are probably going to happen.
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.
[deleted]
related discussion: https://news.ycombinator.com/item?id=27695486
“ A government could compel the app store owner to change your app, too.”
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.
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.
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.
> Re: 1 - Sure they can.
Sure they can't. Data is lost.
> AABs are hardly required for Google to inject their own code into apps.
Much harder for Google (or anyone legally mandating them) to get caught with AABs though.
> And honestly, why would you even be concerned about them injecting code into third party apps?
... in addition to a bunch of security issues. Also makes it possible to do forced monetization, like YouTube has done.
Sure they can't. Data is lost.
> AABs are hardly required for Google to inject their own code into apps.
Much harder for Google (or anyone legally mandating them) to get caught with AABs though.
> And honestly, why would you even be concerned about them injecting code into third party apps?
... in addition to a bunch of security issues. Also makes it possible to do forced monetization, like YouTube has done.
> Sure they can't. Data is lost.
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.
> 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.
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.
> It's not and it does matter
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.
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.
> Sure they can't. Data is lost.
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.
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.
> So? Presumably you are going to continue to interact with the app.
It changes a lot. Apps losing their data is much more disruptive than the silent replacement incorrectly touted earlier.
> Forced monetization is an even stupider conspiracy than NSA spying since it would require wide use rather than targeted changes.
So? YouTube did it on content creators' content. Obvious yes, but directly enabled by the lack of dev-controlled signing keys.
It changes a lot. Apps losing their data is much more disruptive than the silent replacement incorrectly touted earlier.
> Forced monetization is an even stupider conspiracy than NSA spying since it would require wide use rather than targeted changes.
So? YouTube did it on content creators' content. Obvious yes, but directly enabled by the lack of dev-controlled signing keys.
>Is there even a way a user can check who signed the apk
Yes, super easy to check all the signatures on every app in your android phone with this: https://f-droid.org/en/packages/info.guardianproject.checkey...
Yes, super easy to check all the signatures on every app in your android phone with this: https://f-droid.org/en/packages/info.guardianproject.checkey...
APK model has worked well… does it need changed?
It's not being changed.
The end format is still APK.
The end format is still APK.
Except google gets the source code first and then creates custom specific APK’s. Not sure this step is really “needed”.
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.
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.
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.
[deleted]
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.
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.