Since they stop publishing factory images and device support code for the previous major release. With your own device, you control your own destiny in that regard. AOSP supports each major release for 3 years and your vendor updates won't require a new major release of Android.
Conversation
Without your own device, simply targeting ANYTHING other than a Pixel, since the OEM takes longer to migrate you have a lot more time to port your changes and get your fork of AOSP ready. Treble also allows moving to a new major release without device support code being updated.
1
1
Pixels make this hard, since they move immediately, right when the new OS you need to port your code to becomes publicly available, and they immediately drop support for the previous major release. Treble means AOSP is backwards compatible with device support code, but new device
1
2
support code isn't backwards compatible with an old version of AOSP so we can't simply continue having GrapheneOS based on Android 10 while shipping Android 11 device support code. Forced to migrate rapidly which is extremely difficult. All of this is caused by targeting Pixels.
1
2
Our long-term goal is to be targeting custom hardware in collaboration with organizations like Calyx, where hardware is produced to suit the needs of multiple projects. Would no longer have these issues regardless of how much SoC vendor code is open + can take time to migrate.
2
1
5
If plans are seriously going in that direction I would happily put my time and $ on the table.
The current path of spending endless hours hacking around constantly changing undocumented binary blob hardware vendors like Google... that seems like a dead end. They will never care.
1
Until then I suggest we encourage parallel paths like Pinephone and Librem5 and push for future iterations that can support proper secure booted AOSP as well as other green field OS experiments.
1
1
We consider both of those far worse than the current Pixel targets and they don't actually offer us the control that we want over the hardware / firmware. We want to start from a mainstream reference design with a mainstream SoC with competitive security and be the OEM.
1
1
So that we have the signing keys for the low-level firmware, we can modify all of that, we have proper device support code available to us, we aren't forced to rapidly migrate to new major releases but rather can take a month or two to migrate at our own pace post-release, etc.
1
Pixel devices are what causes these problems. If we had our own Qualcomm SoC device largely just using a reference design and using the Qualcomm SPU rather than the Titan M (not quite as good, but good enough), etc. we'd be able to target reaching parity with Pixel security.
2
1
Or another major SoC vendor like Mediatek or whatever, but Qualcomm has the best platform security right now. Regardless of what's chosen, there's mostly closed source firmware, but you actually get a lot of those sources to modify and sign with your keys if you're the OEM.