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.
Conversation
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.
2
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.
It would be so much easier to support a device from one of the vendors publishing fully usable device support code. The time it takes them to switch over to new major releases is also a huge help to downstream variants of the public AOSP. Also, not adopting quarterly releases.
1
You have said this but I have not seen this in any devices I have looked at (granted a couple years ago).
Can you point me to specific devices that are going to be less hellish to target than Pixels today for Android 11?
1
1
Show replies