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.

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?

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...

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.