It is much easier for spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps as a one-time setup.
At that point, ADB no longer matters. The spyware is already configured and ready to run. Even if on-device ADB were patched, anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.
As for attacks without physical access, as explained in the article with the 3 scenario, this is neither practical nor realistic. It only affects a very small subset of users (primarily Android developers) under very specific circumstances and during limited time windows.
Correct, and apps using these setups (even for genuine reasons) have been under the cosh.
> At that point, ADB no longer matters.
"on-device adb" wasn't meant for scenarios it is being used for (via Shizuku, for example). It is a pointless attack surface.
> anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.
This same case can be made in support of removing on-device adb. Anyone with physical access can install & configure for their use cases. If you claim that's more hassle than worth, then you have your answer (that is, added hassle for stalkerware sellers, too).
Disallowing on-device adb is restrictive (I co-develop a security app that can absolutely make more from elevated permissions, via Shizuku or Device Admin; let alone root), but I don't think Google will do so because they want to close Android (the platform) more than they need to. To me, given the very human costs of stalkerware & financial fraud, it is an understandable, even if disappointing, security decision. Otoh, I do get that the road to hell is paved with good intentions...
Like Google Mobile Services on stock Android?