9 ms·

App bundles allow smaller apk sizes [0]: > Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the cod

by est31 6y ago

App bundles allow smaller apk sizes [0]: > 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. You no longer have to build, sign, and manage multiple APKs to optimize support for different devices, and users get smaller, more-optimized downloads. But as all this logic sits on Google servers and might involve lots of signing of apks for a single app and version, Google has decided it needs your signing keys for that feature. Which is weird already because you could also think of a model where you provide Google not with the keys but a service where Google presents you an apk, and you sign it. Then you can inspect it retroactively and run scanners on it, if you want to. The keys stay yours and you would know what Google is up to with your application. If you have problems with giving Google your signing keys, you can just avoid this feature. But apparently there is the fear that Google wants to make the feature required. Which would give them ability to alter basically any app on the play store as they deem fit. Or they might in fact be forced by governments. Already now many providers like facebook take down public posts because a local government disliked a post. What if a govt told Google "please install this altered Signal app on this person's device"? And yes, Google apps already run as system app so they could already do something like that, but an implementation of that is way harder to make consistent among different vendors. [0]: https://developer.android.com/guide/app-bundle https://developer.android.com/guide/app-bundle

nodamage 6y ago
> Which would give them ability to alter basically any app on the play store as they deem fit. Google already controls the operating system, the Play Store, and the SDKs you used to develop your app in the first place. If they wanted to alter your app there is already ample opportunity to do so, what additional trust do you gain by managing your own signing key here?
- prepend 6y ago
  Isn’t it simply that any changes by Google would clearly not match the developer’s signature so are evident when they are different?
  - nodamage 6y ago
    If the signature does not match that tells you the app was tampered with, but the inverse is not true when your "adversary" controls the compiler, installer, and the operating system itself. Reflections on Trusting Trust (https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...) provides a good explanation as to why.
  - bellyfullofbac 6y ago
    I don't want to defend Google here, but in theory, since Google controls the OS, it can also make it lie to you. So you tell the OS to "show me this app's signature", and the OS can just lie and show you the expected signature. You want to copy the app to an SD card so you can check it on your Linux PC? The OS can copy the "legal" app. Also yeah, it seems code signing won't affect anything if the OS wants to be malicious. "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value and change it to the expected one...
    - altfredd 6y ago
      > in theory, since Google controls the OS, it can also make it lie to you Google controls Android, but it does not control every other OS and every piece of hardware. If someone downloads an apk with their own custom Google Play client, running on their own computer, they can check whether it was tampered with. In the past a tampered apk from Google servers would have been signed by wrong key (because the proper key is controlled by developer), pointing to Google as culprit. Now it will be signed by "developer's" key (shared with Google), creating plausible deniability for Google and US intelligence services. > "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value This sounds extremely labor-intensive. Who will write all those no-op libraries? Who will pay for it?
      - 6y ago
jayd16 6y ago
>a service where Google presents you an apk, and you sign it. This doesn't work if the idea is to dynamically generate APKs for the vast Android ecosystem. In theory they could dynamically upgrade apps to be compatible with future OS versions etc.
- tdeck 6y ago
  To add some more context on this, when you provide an app bundle the Play server looks at your device's display size, density, OS version, and architecture. If your OS version is new enough (L+ I believe), it can send you a bunch of split APKs. That means one big APK with DEX code, one with just the armeabi-v8a native code, one with just English translations, one with just xxhdpi assets, etc... In theory a developer could build all these split APKs, sign them, and upload them to Play. However, on older devices that don't support split APKs, Play must compose and sign one custom "fat APK" with all of the stuff specific to your configuration, on the fly. There are a lot of different options for this (you can generate them using bundletool if you're curious). The upload size of all these redundant APKs alone would be a huge burden on developers. This isn't to say that there couldn't be a way to do APK splitting while maintaining the integrity of the app signing system. My guess is that it wasn't a high priority to do so.
ChuckMcM 6y ago
It is one of those situations where the excuse is really out there and much more complicated than the simple, "we 'need' the ability to modify your app before it ships." Since the article gives a plausible scenario where that would occur (could be totalitarian regime, could be an NSL letter from the FBI[1]) Here is a time where having a history of doing the "good and correct" thing would help reassure people that you aren't being nefarious, sadly with the lack of such a history, I don't very many believe anything Google says any more. It is sad really but there isn't anything App developers can do except leave their platform. [1] I know, some consider them equivalent.
- rodgerd 6y ago
  Yes, I think this will be the way that Google satisfy e.g. the Australian government's mandate to aid intelligence and law enforcement agencies to surveil in a targeted way. Not "everyone gets a subverted copy of Signal", but "these three people get a subverted copy of Signal."
  - smartbit 6y ago
    And also the European anti-encryption proposals [0] Lawfull intercept was done on IronChat, PGP-SAFE and Ennetcom that gave direct access to the communication of criminals which are now successfully used in court. In the most recent case, the tacktic of subverting all copies was successfully used by the police to decrypt Sky ECC and get access to .5 billion messages used primarily by criminals. In this comment [1] regarding Sky ECC the question was raised > How could I get a court order to get blanket access to Signal? To which we now know the answer: On Android you don’t, you ask a court order for a list of specific phones you want to listen onto. I’m baffled that Human Rights & Cilvil Liberty organisations are not standing up more fiercely against the new Play Store policy. [0] https://news.ycombinator.com/item?id=25940566 https://news.ycombinator.com/item?id=25940566 https://news.ycombinator.com/item?id=25940670 https://news.ycombinator.com/item?id=25940670 [1] https://news.ycombinator.com/item?id=26468437#26483634 https://news.ycombinator.com/item?id=26468437#26483634
    - heavyset_go 6y ago
tgsovlerkhgsel 6y ago
A good workaround could be that you sign a manifest containing all the files and a version number, and Google signs the APK. (The version number prevents mix-and-match attacks where e.g. an old vulnerable file is reused in a new APK.)
judge2020 6y ago
I seriously doubt 99% of Google Play developers worry enough that they would take the time and money to run a signing server, and that would introduce a lot of complexity for Google.
- heavyset_go 6y ago
  > that would introduce a lot of complexity for Google Oh well, they're imposing it upon everyone else. Google controls what apps are distributed and run on over 40% phones and tablets in the US. Users deserve the right to know if what they're downloading and installing is what they're supposed to be getting. Developers deserve the right to know that what's shipping to their customers is what they intended. Billions of people are vulnerable if the Play Store's infrastructure gets, or is, compromised, or if its owners or governments decide to do something nefarious.
  - izacus 6y ago
    Users, right now, are quite happy trusting Apple (paragon of privacy and security) and F-Droid (the main opensource store) with signing their apps for them, so there doesn't seem much reason for Google to waste extra effort not following them. What's the business reason for Google to not follow Apple in this respect?
    - Andrew_nenakhov 6y ago
      Trust is matter based on reputation, and that is why users generally trust F-Droid. Can we trust Google, based on their reputation?
- jayd16 6y ago
  How is an automated signing server better security anyway? Google can still sign what they want but now every dev has a missive security hole in the form a server that can sign code reachable from the open web?
  - est31 6y ago
josephg 6y ago
Piling on here, thats super weird. The reason for digital signatures is that they make a claim. "As a representative of organisation A, the binary with shasum XXXX is our work. We stand behind it." Why would I generate a private key, then share my private key with google? If google wants to claim that a binary they're shipping to users is same the one they received, they don't need my private key to do that. They can make their own signature, with their own key. Using a key I generated then handed to them is just dangerous security theatre. Google is asking me to vouch for binaries they sign and serve. But I can't vouch for those binaries - I didn't produce them and can't make any claim about their provenance.
- soarfourmore 6y ago
  It’s even weirder that Google’s security engineers would sign off on such a design. I am astounded
- deleted 6y ago
  [deleted]
- nodamage 6y ago
  > If google wants to claim that a binary they're shipping to users is same the one they received, they don't need my private key to do that. They can make their own signature, with their own key. IIRC this is how it works by default for new apps. Uploading your existing signing key is only necessary for backwards compatibility to allow you to update existing apps that have already been published using that key.
  - mcny 6y ago
    > IIRC this is how it works by default for new apps. Personally, I'd like to see Apple, Google, and possibly Microsoft take this to what I think is the obvious conclusion: developers and independent software vendors submit source code, artwork and other such "assets", sufficient meta data, and build instructions to the store, the store builds and publishes the applications and makes them available to users. F-Droid builds and publishes using its own keys and while there are problems with delay for some time-sensitive apps (most notably Newpipe, an application to watch YouTube videos), it works out quite well for the most part. I can't imagine why Apple and Google couldn't have what are essentially multiple build runners running at the same time to cut this time shorter to something like an hour at the most? In return at least for Android (Apple is a bit of a special case), I would like to see it made possible at least for F-Droid or something similar to be able to update apps without requiring user intervention. Not sure how the technology will work exactly but my understanding (please correct me if I am wrong) is Google Play Store has super cow powers and I think it should be able to "bless" other applications to have the same super powers?
remram 6y ago
It's just a little bit weird that Google designed the Play Store and Android with key signing if they then have to ask for those keys. They control the OS and the store, couldn't they just make devices trust Google's app-repackaging-service's key? This would be easier for everyone, and more honest for the consumer user who gets packages signed by whoever actually built it.
- jayd16 6y ago
  This solution is backwards compatible. Changing the installation verification process is not.
  - pas 6y ago
    Why? They control the Play app itself anyway. Isn't verification done by the privileged "Google Play Services" special background service? Which is basically the userspace, which is where Google pushes security updates (because carriers and phone makers don't).
    - jayd16 6y ago
      Signatures are verified at the OS level, outside the playstore. Even if you side load apps, signatures are checked for consistency.
      - remram 6y ago
        I'm not suggesting we remove signing, just that Google use their own signing key for apps they build.
        jayd16 6y ago
        That won't work. For google to take over the signing of existing apps they need the existing keys.
        6y ago
a-dub 6y ago
it doesn't matter, they could just push an android update that bypasses your signature if they really wanted to. granted that's a bigger deal, but they control the ecosystem in google play and hold the signing keys for android and google play itself, you already trust them.
- aesh2Xa1 6y ago
  If the only person with the signing key is the author, then any user could verify the signature outside of Android, could they not? Instead, even outside of Android, we simply cannot know.
  - a-dub 6y ago
    they could push an update that makes it appear like the author signed version is on the device, but in reality a different version is run. they control the keys to the software delivery channel and the operating system. large parts of this are closed source. users and developers trust them and that's just how it is. that said, it's not pretty and i hope it's just a backwards compatibility stopgap as discussed upthread.
  - jayd16 6y ago
    If you're allowed to verify outside of Android, the author could simply post hashes.
  - nodamage 6y ago
    Except verifying outside of Android tells you nothing about whether the application as installed on an actual device has been tampered with, so you don't really gain any security from this.
saurik 6y ago
It isn't just a "fear": Google has said that new apps submitted after August must use this feature.
- topkeks 6y ago
  [citation needed]
toast0 6y ago
Smaller apks are great, but throwing away the security model to get smaller apks really isn't. :( Has Google come out with a way to compress string localization information yet? That would make a big difference for apps that support lots of languages, and last I checked (which was a few years ago, so happy to be wrong), Google didn't have a good solution there.
- izacus 6y ago
  There's support for APK splits by locale, where you can upload a separate APK for each language which keeps the size down. The AAB system criticized in this article will fix your issue too - Play Store delivery will automatically split APKs into per-locale slices and only download languages you need on your device.
  - toast0 6y ago
    > There's support for APK splits by locale, where you can upload a separate APK for each language which keeps the size down How does this work if the user changes the locale on their phone? I guess you need to redownload the APK? I would still prefer compressed localization for all languages, and uncompress the needed one at install/start/sometime if it needs to be mmaped. If the phone locale is changed, uncompress the new one at some point. > The AAB system criticized in this article will fix your issue too - Play Store delivery will automatically split APKs into per-locale slices and only download languages you need on your device. Sure. The system fixes a problem Google (or its predecessor, not sure about timing) created, and let linger for over a decade, by handing control of signing keys to Google. Not a great fix. Sure, de facto, Google could patch any app via Play Services which has lots of permissions, but if they control the signing keys, they can more easily meddle.
- grishka 6y ago
  Apks are zip archives. So, naturally, everything they contain is already compressed.
  - toast0 6y ago
willvarfar 6y ago
I know nothing about the real situation, but commenting off the cuff based on what I read here, it sounds like either: 1) google just sign these apks with their own certs. 2) google should present the developer with a google public key that the developer signs, allowing google to sign an apk with a google key that had a chain of trust to the developer.
DelightOne 6y ago
They could add DRM-features on the fly.
grishka 6y ago
Also what is this "device configuration" thing exactly? Vector drawables help avoid the issue of having unneeded resources in an apk entirely. You definitely should be using them for icons if you aren't yet. Other resource types, like strings in languages you don't speak or layouts for tablets, are small enough that their impact on the apk size is usually negligible.

by est31 6y ago

nodamage 6y ago

> Which would give them ability to alter basically any app on the play store as they deem fit. Google already controls the operating system, the Play Store, and the SDKs you used to develop your app in the first place. If they wanted to alter your app there is already ample opportunity to do so, what additional trust do you gain by managing your own signing key here?

prepend 6y ago
Isn’t it simply that any changes by Google would clearly not match the developer’s signature so are evident when they are different?
- nodamage 6y ago
  If the signature does not match that tells you the app was tampered with, but the inverse is not true when your "adversary" controls the compiler, installer, and the operating system itself. Reflections on Trusting Trust (https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...) provides a good explanation as to why.
- bellyfullofbac 6y ago
  I don't want to defend Google here, but in theory, since Google controls the OS, it can also make it lie to you. So you tell the OS to "show me this app's signature", and the OS can just lie and show you the expected signature. You want to copy the app to an SD card so you can check it on your Linux PC? The OS can copy the "legal" app. Also yeah, it seems code signing won't affect anything if the OS wants to be malicious. "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value and change it to the expected one...
  - altfredd 6y ago
    > in theory, since Google controls the OS, it can also make it lie to you Google controls Android, but it does not control every other OS and every piece of hardware. If someone downloads an apk with their own custom Google Play client, running on their own computer, they can check whether it was tampered with. In the past a tampered apk from Google servers would have been signed by wrong key (because the proper key is controlled by developer), pointing to Google as culprit. Now it will be signed by "developer's" key (shared with Google), creating plausible deniability for Google and US intelligence services. > "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value This sounds extremely labor-intensive. Who will write all those no-op libraries? Who will pay for it?
    - 6y ago

jayd16 6y ago

>a service where Google presents you an apk, and you sign it. This doesn't work if the idea is to dynamically generate APKs for the vast Android ecosystem. In theory they could dynamically upgrade apps to be compatible with future OS versions etc.

tdeck 6y ago
To add some more context on this, when you provide an app bundle the Play server looks at your device's display size, density, OS version, and architecture. If your OS version is new enough (L+ I believe), it can send you a bunch of split APKs. That means one big APK with DEX code, one with just the armeabi-v8a native code, one with just English translations, one with just xxhdpi assets, etc... In theory a developer could build all these split APKs, sign them, and upload them to Play. However, on older devices that don't support split APKs, Play must compose and sign one custom "fat APK" with all of the stuff specific to your configuration, on the fly. There are a lot of different options for this (you can generate them using bundletool if you're curious). The upload size of all these redundant APKs alone would be a huge burden on developers. This isn't to say that there couldn't be a way to do APK splitting while maintaining the integrity of the app signing system. My guess is that it wasn't a high priority to do so.

ChuckMcM 6y ago

It is one of those situations where the excuse is really out there and much more complicated than the simple, "we 'need' the ability to modify your app before it ships." Since the article gives a plausible scenario where that would occur (could be totalitarian regime, could be an NSL letter from the FBI[1]) Here is a time where having a history of doing the "good and correct" thing would help reassure people that you aren't being nefarious, sadly with the lack of such a history, I don't very many believe anything Google says any more. It is sad really but there isn't anything App developers can do except leave their platform. [1] I know, some consider them equivalent.

rodgerd 6y ago
Yes, I think this will be the way that Google satisfy e.g. the Australian government's mandate to aid intelligence and law enforcement agencies to surveil in a targeted way. Not "everyone gets a subverted copy of Signal", but "these three people get a subverted copy of Signal."
- smartbit 6y ago
  And also the European anti-encryption proposals [0] Lawfull intercept was done on IronChat, PGP-SAFE and Ennetcom that gave direct access to the communication of criminals which are now successfully used in court. In the most recent case, the tacktic of subverting all copies was successfully used by the police to decrypt Sky ECC and get access to .5 billion messages used primarily by criminals. In this comment [1] regarding Sky ECC the question was raised > How could I get a court order to get blanket access to Signal? To which we now know the answer: On Android you don’t, you ask a court order for a list of specific phones you want to listen onto. I’m baffled that Human Rights & Cilvil Liberty organisations are not standing up more fiercely against the new Play Store policy. [0] https://news.ycombinator.com/item?id=25940566 https://news.ycombinator.com/item?id=25940566 https://news.ycombinator.com/item?id=25940670 https://news.ycombinator.com/item?id=25940670 [1] https://news.ycombinator.com/item?id=26468437#26483634 https://news.ycombinator.com/item?id=26468437#26483634
  - heavyset_go 6y ago

tgsovlerkhgsel 6y ago

A good workaround could be that you sign a manifest containing all the files and a version number, and Google signs the APK. (The version number prevents mix-and-match attacks where e.g. an old vulnerable file is reused in a new APK.)

judge2020 6y ago

I seriously doubt 99% of Google Play developers worry enough that they would take the time and money to run a signing server, and that would introduce a lot of complexity for Google.

heavyset_go 6y ago
> that would introduce a lot of complexity for Google Oh well, they're imposing it upon everyone else. Google controls what apps are distributed and run on over 40% phones and tablets in the US. Users deserve the right to know if what they're downloading and installing is what they're supposed to be getting. Developers deserve the right to know that what's shipping to their customers is what they intended. Billions of people are vulnerable if the Play Store's infrastructure gets, or is, compromised, or if its owners or governments decide to do something nefarious.
- izacus 6y ago
  Users, right now, are quite happy trusting Apple (paragon of privacy and security) and F-Droid (the main opensource store) with signing their apps for them, so there doesn't seem much reason for Google to waste extra effort not following them. What's the business reason for Google to not follow Apple in this respect?
  - Andrew_nenakhov 6y ago
    Trust is matter based on reputation, and that is why users generally trust F-Droid. Can we trust Google, based on their reputation?
jayd16 6y ago
How is an automated signing server better security anyway? Google can still sign what they want but now every dev has a missive security hole in the form a server that can sign code reachable from the open web?
- est31 6y ago

josephg 6y ago

Piling on here, thats super weird. The reason for digital signatures is that they make a claim. "As a representative of organisation A, the binary with shasum XXXX is our work. We stand behind it." Why would I generate a private key, then share my private key with google? If google wants to claim that a binary they're shipping to users is same the one they received, they don't need my private key to do that. They can make their own signature, with their own key. Using a key I generated then handed to them is just dangerous security theatre. Google is asking me to vouch for binaries they sign and serve. But I can't vouch for those binaries - I didn't produce them and can't make any claim about their provenance.

soarfourmore 6y ago
It’s even weirder that Google’s security engineers would sign off on such a design. I am astounded
deleted 6y ago
[deleted]
nodamage 6y ago
> If google wants to claim that a binary they're shipping to users is same the one they received, they don't need my private key to do that. They can make their own signature, with their own key. IIRC this is how it works by default for new apps. Uploading your existing signing key is only necessary for backwards compatibility to allow you to update existing apps that have already been published using that key.
- mcny 6y ago
  > IIRC this is how it works by default for new apps. Personally, I'd like to see Apple, Google, and possibly Microsoft take this to what I think is the obvious conclusion: developers and independent software vendors submit source code, artwork and other such "assets", sufficient meta data, and build instructions to the store, the store builds and publishes the applications and makes them available to users. F-Droid builds and publishes using its own keys and while there are problems with delay for some time-sensitive apps (most notably Newpipe, an application to watch YouTube videos), it works out quite well for the most part. I can't imagine why Apple and Google couldn't have what are essentially multiple build runners running at the same time to cut this time shorter to something like an hour at the most? In return at least for Android (Apple is a bit of a special case), I would like to see it made possible at least for F-Droid or something similar to be able to update apps without requiring user intervention. Not sure how the technology will work exactly but my understanding (please correct me if I am wrong) is Google Play Store has super cow powers and I think it should be able to "bless" other applications to have the same super powers?

remram 6y ago

It's just a little bit weird that Google designed the Play Store and Android with key signing if they then have to ask for those keys. They control the OS and the store, couldn't they just make devices trust Google's app-repackaging-service's key? This would be easier for everyone, and more honest for the consumer user who gets packages signed by whoever actually built it.

jayd16 6y ago
This solution is backwards compatible. Changing the installation verification process is not.
- pas 6y ago
  Why? They control the Play app itself anyway. Isn't verification done by the privileged "Google Play Services" special background service? Which is basically the userspace, which is where Google pushes security updates (because carriers and phone makers don't).
  - jayd16 6y ago
    Signatures are verified at the OS level, outside the playstore. Even if you side load apps, signatures are checked for consistency.
    - remram 6y ago
      I'm not suggesting we remove signing, just that Google use their own signing key for apps they build.
      - jayd16 6y ago
        That won't work. For google to take over the signing of existing apps they need the existing keys.
        6y ago

a-dub 6y ago

it doesn't matter, they could just push an android update that bypasses your signature if they really wanted to. granted that's a bigger deal, but they control the ecosystem in google play and hold the signing keys for android and google play itself, you already trust them.

aesh2Xa1 6y ago
If the only person with the signing key is the author, then any user could verify the signature outside of Android, could they not? Instead, even outside of Android, we simply cannot know.
- a-dub 6y ago
  they could push an update that makes it appear like the author signed version is on the device, but in reality a different version is run. they control the keys to the software delivery channel and the operating system. large parts of this are closed source. users and developers trust them and that's just how it is. that said, it's not pretty and i hope it's just a backwards compatibility stopgap as discussed upthread.
- jayd16 6y ago
  If you're allowed to verify outside of Android, the author could simply post hashes.
- nodamage 6y ago
  Except verifying outside of Android tells you nothing about whether the application as installed on an actual device has been tampered with, so you don't really gain any security from this.

saurik 6y ago

It isn't just a "fear": Google has said that new apps submitted after August must use this feature.

topkeks 6y ago
[citation needed]

toast0 6y ago

Smaller apks are great, but throwing away the security model to get smaller apks really isn't. :( Has Google come out with a way to compress string localization information yet? That would make a big difference for apps that support lots of languages, and last I checked (which was a few years ago, so happy to be wrong), Google didn't have a good solution there.

izacus 6y ago
There's support for APK splits by locale, where you can upload a separate APK for each language which keeps the size down. The AAB system criticized in this article will fix your issue too - Play Store delivery will automatically split APKs into per-locale slices and only download languages you need on your device.
- toast0 6y ago
  > There's support for APK splits by locale, where you can upload a separate APK for each language which keeps the size down How does this work if the user changes the locale on their phone? I guess you need to redownload the APK? I would still prefer compressed localization for all languages, and uncompress the needed one at install/start/sometime if it needs to be mmaped. If the phone locale is changed, uncompress the new one at some point. > The AAB system criticized in this article will fix your issue too - Play Store delivery will automatically split APKs into per-locale slices and only download languages you need on your device. Sure. The system fixes a problem Google (or its predecessor, not sure about timing) created, and let linger for over a decade, by handing control of signing keys to Google. Not a great fix. Sure, de facto, Google could patch any app via Play Services which has lots of permissions, but if they control the signing keys, they can more easily meddle.
grishka 6y ago
Apks are zip archives. So, naturally, everything they contain is already compressed.
- toast0 6y ago

willvarfar 6y ago

I know nothing about the real situation, but commenting off the cuff based on what I read here, it sounds like either: 1) google just sign these apks with their own certs. 2) google should present the developer with a google public key that the developer signs, allowing google to sign an apk with a google key that had a chain of trust to the developer.

DelightOne 6y ago

They could add DRM-features on the fly.

grishka 6y ago

Also what is this "device configuration" thing exactly? Vector drawables help avoid the issue of having unneeded resources in an apk entirely. You definitely should be using them for icons if you aren't yet. Other resource types, like strings in languages you don't speak or layouts for tablets, are small enough that their impact on the apk size is usually negligible.