> You jumprd in on me sharing my opinion that Android is continuing to head in a difficult to audit and maintain direction.
It wasn't your thread. You jumped into a thread to go off on a tangent about that.
> not investing in testing AOSP anymore.
Huh? It's what they ship.
Conversation
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.
3
1
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.
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
Show replies