Google used to pay a dedicated person to build/test AOSP from source on all new devices. They don't now and this has slipped in priorities.
I know this because I literally met with an Android team manager and talked about it in Mountain View.
Conversation
Many teams working on Android do AOSP first development. It's what they are primarily using and testing during development, and is what they ship on their own devices with the addition of their overlays. The normal AOSP stable tags are the stable tags for their own stock OS.
2
Yet it won't boot without stealing tons and tons of blobs and nonsense from the factory images let alone build signing etc. Tons of hacks are always needed just to get source+drivers AOSP working on their own first party devices.
They have not built ready-to-use AOSP in years.
1
1
That's not true, and again, you're confusing the state of AOSP (which is great) with the state of public support for others to build AOSP for Pixels (which is very poor).
1
The actual AOSP reference devices are devices like HiKey 960. Pixels are a Google product with partially open source device support code released as part of AOSP.
They use them as reference devices internally, and a substantial portion of the teams do AOSP-first development.
1
1
Pixels are not reference devices for others to use for AOSP development. They don't work well for that. You have to look way back for a time when Google's first party phones could be treated as AOSP reference devices. Nexus 5X was all around worse than a Pixel 4 for this too.
1
It's very clear that AOSP is intended to be used to target hardware under the control of the person doing development work, whether it's their own device or a device intended to be used that way. Pixels are not really intended to be used that way, and make many things difficult.
1
Using AOSP is very viable. It's very different using AOSP to target a device intended to be used by you for development vs. using Pixels. You have *3 years* of security updates for each of the major releases and you get device support code from your vendor(s) in a usable state.
1
So when a release like Android 11 comes out, it's a non-event and you can migrate at your own pace. Even without being a partner with early access, it's not much of a major issue. There's nothing to hack together or reverse engineer. AOSP isn't the problem at all.
1
Also, thanks to Treble, you can keep shipping AOSP updates including the major version upgrades without necessarily having support for them from the vendor(s). You can move to Android 11 while using Android 10 vendor support. Better to have it overhauled, but it's not mandatory.
1
I've worked with vendors using AOSP on their own hardware, and it's a far different experience. They don't have to deal with any of the nonsense. They get a source tree from Qualcomm to build vendor, the boot chain, etc. and the tooling for signing firmware + setting up fuses.
If a vendors want, they can take that and ship a device that others can use with their own OS, while still having all the standard hardware/firmware security features. This is the part Google does. What they don't do is releasing usable device support code for use with AOSP.
1
There are vendors doing a better job with releasing usable AOSP device support code for their devices. If you have the impression that Pixels are anything close to the best at that, it's very wrong. Pixels just have the best hardware/firmware privacy and security properties.
1
Show replies
I agree with everything here. For someone with the power to create a device that actually cares about security/privacy Android could have a bright future.
The -reality- however is no one is doing this and all devices are optimized for the wishes of cell carriers, not users.
1
1
Until this situation changes I still remain that the future for Android continuing to be hacked into devices by vendors that don't intentionally care about security/privacy is a huge black hole of work I don't wish on anyone.
1
1
Show replies