Google could publish the code they're going to use to do the transformation step (as e.g. a Docker image), and the developer could audit the result by optionally independently running the same code themselves, at any time after publication. As long as the code Google published was deterministic, the developer should be able to use it to reproduce a binary with the same the SHA as the one offered centrally.

This is the same process that package maintainers (e.g. Debian, Mozilla, Tor) go through to produce reproducible (i.e. verifiable, deterministic) binary packages: they enable arbitrary users to run a copy of the packaging + distribution infrastructure on their own machine, such that they can watch it all go and see that it spits out the same thing the remote server does.

Yup, I'm pretty sure this makes reproducible builds totally impractical for any apps installed through the Play Store.

Apps that currently provide reproducible builds: Signal, Threema, Telegram. (Probably others as well.)

If "optimize[d] download sizes" is the goal, Google could simply release a tool that performed the compression/etc on a bundle (pre-signing) and require[1] that apps must be processed by the tool before submission.

[1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.

"optimizing download size" is a lazy distraction when an OS update can be 1 GB. Goggle really wants to modify the apps for selected individuals. To sugar coat the pill, they came up with the size optimizing story (and reducing carbon footprint, probably).