Portions of the SDK are open source, portions are not. Android also does not have reproducible builds, so you cannot audit that the open source you are viewing relates to the binaries on your phone. Android also widely depends on binary blob firmwares which also cannot be audited.
As it stands if you buy a normal android phone, then you must trust Google.
>Portions of the SDK are open source, portions are not. Android also does not have reproducible builds, so you cannot audit that the open source you are viewing relates to the binaries on your phone. Android also widely depends on binary blob firmwares which also cannot be audited.
1. you still need way more parties involved (eg. OEMs, chipset makers), unlike google which probably has acesss 95+% of the non-chinese android phones.
You're completely ignoring existence of silently updated Play Store and Play Services which are controlled by Google and have enough permissions to do exactly what you think they can't.
Google has been decoupling things like Play Services from the BSP for a long time now. They could certainly push a backdoored version to a specific set of phones if they so wished.
If you wanted to add the exploit to the kernel, there are plenty of hooks to do so that would not require the kernel to be recompiled (e.g. a loadable module, or BPF). Again, these could be targeted at specific individuals, or groups of individuals.
Still, Google is extremely unlikely to add any backdoor willingly, and unlikely to add one in general. And more to the point, controlling the signing keys for a specific App does not make it easier to backdoor someones phone.
As it stands if you buy a normal android phone, then you must trust Google.