With older versions of Android, what Google could do was pretty limited (in terms of messing with the core OS). While Google Play Services has a lot permissions, it all fits into Android's permission model and does not run as root. Package installation is done via communication with the Android framework's PackageManager class and the corresponding /system/bin/installd daemon. Silent installations and automatic updates are also handled via PackageManager using a permission that system apps can obtain.
Overwriting most core OS files (eg. shared libraries) in a persistent way, even with an exploit, would be difficult since the entire /system and /vendor volumes are signed using the device manufacturer's dm-verity keys.
However, with Android 10+ shipping with APEX modules [0], Google's ability to push core OS changes to existing devices might be changing. I'm not sure if any devices ship with the unflattened (ie. updatable) type of APEX modules yet, but I'd suspect these would be signed by Google instead of the device manufacturer and would be distributed through Google Play.
Overwriting most core OS files (eg. shared libraries) in a persistent way, even with an exploit, would be difficult since the entire /system and /vendor volumes are signed using the device manufacturer's dm-verity keys.
However, with Android 10+ shipping with APEX modules [0], Google's ability to push core OS changes to existing devices might be changing. I'm not sure if any devices ship with the unflattened (ie. updatable) type of APEX modules yet, but I'd suspect these would be signed by Google instead of the device manufacturer and would be distributed through Google Play.
[0] https://source.android.com/devices/tech/ota/apex