Can't tell if on purpose or broken by mistaken (no documentation updates, so maybe broken?)
ACTION_PACKAGE_ADDED cannot be received unless app is a Process.SYSTEM_UID developer.android.com/reference/andr
cs.android.com/android/platfo
commit : cs.android.com/android/_/andr
Conversation
Probably meant to be a privacy related change? No more ad networks or apps snooping on package adds?
Though, no bueno that this isn't documented or shared anywhere I can find :\
1
Replying to
The QUERY_ALL_PACKAGES permission provides access to most (all?) of the past functionality. Not sure about this case though.
developer.android.com/about/versions
If you don't have that permission, you can only see apps that you've marked as being available to the app.
1
For apps targeting API 30+, they're only supposed to be able to see apps in their whitelist unless they request QUERY_ALL_PACKAGES. A lot of changes were made to support this. For now, anyone can use QUERY_ALL_PACKAGES and it's not user-facing yet. It will likely get locked down.
1
It just doesn't make much sense for them to start heavily locking it down when apps can simply drag their heels and avoid adopting API 30+ until it becomes mandatory on the Play Store at the end of next year. This way, at least app manifests will have a list of apps or that perm.
1
Replying to
Makes sense. I was assuming there will be a big wave of breakages when they start forcing people to provide bundles vs apks, leading to all these have a hard depricated date as well
1
Replying to
It's not clear if they're really going to do that any time soon. They've toned down the warnings for releases without app bundles. They could require people to generate a bundle of apks with bundletool and get the same benefits for anything but an app with updates anymore.
1
Not all app developers want to have Google-managed signing keys. There's substantial pushback against this because of them tying it to app signing, and they didn't really need to do that. They could have the SDK run bundletool to generate the same set of apks that Play does.
1
Replying to
Completely agree. It's definitely getting ties to many things, had many discussions with devs who /want/ those features and don't care about the key risk. Most don't guard the keys much anyway, is what I've seen...
Will be interesting to see how it plays out
1
Replying to
Most developers are probably better off with Google-managed app signing keys and only needing to deal with app upload keys themselves. Still, it's not better for everyone and would mean the Play Store apks aren't going to be the same as ones outside the Play Store anymore.
It's quite annoying for apps using hardware-based attestation too, since it chains security to your app through the OS. It gives you the app id and signing key in the hardware-based attestation information. If Google can rotate your app's keys, etc. you can't really use that...
1
We can't publish Auditor anymore via the Play Store if they require us to use Google managed signing keys. We'll take it down if that ever becomes mandatory. It has been announced that it will be mandatory for new apps, which would mean new apps like Auditor can't be published.
1
Show replies