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
Conversation
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
+ even if SoC vendor code isn't open, at least we'd still get to audit, modify and build most of it internally including a lot of the SoC firmware. Maybe there would be an SoC vendor with decent security and open source device support code at that point - right now, not really.
1
1
I mean Librem5 and Pinephone type hardware with the only chailnge being the addition of a proper TPM stack for secure boot stuff would still mean a very small number of blobs and worlds easier to maintain AOSP for than anything that exists today.
2
2
TPM is immensely flawed and would not be a substitute for having decent SoC security and actual verified boot. Also, it's hardly as if verified boot is the only thing missing from there. Way too much focus on that as if it's the only issue brought up with it. Also mixing issues.
1
You go from comparing hardware and the device support code from those vendors to comparing operating systems, etc. I don't really know what we're really having a discussion about. You seemed to be talking about putting AOSP on this hardware but then you switch to stuff like this.
2
If we thought there was better hardware available, we would target it. As you seem to be aware yourself, Pixels are a hassle during the yearly major version migration because temporarily using the previous release isn't a real option so there's an insane workload to migrate fast.
1
On the other hand, implementing proper AOSP support for a device not intended for it and without support from the OEM would be far more difficult than nearly any option that's available... and you're talking about hardware missing so much functionality particularly security-wise.
1
No amount of work would be able to make it fully functional and software work won't address hardware/firmware deficiencies. Don't understand how throwing in a TPM (i.e. a really bad take on a general purpose security chip challenging to use for anything valuable) fixes anything.
1
You talk about these couple weeks of difficult work that has to be done once a year to quickly migrate and continue following along with the upstream security updates as if it's worse than having to do everything from scratch while never having full security support at all.
It's not just a couple weeks of work. The work being done is cutting huge corners because there is just not time to do it right and we all know it.
android-prepare-vendor is a gargantuan hack and we end up tossing in tons of blobs we -could- build if there were enough cycles.
2
I feel like current efforts are doing some amazingly useful research (like hardened malloc remote attestation etc) however vendor is a massive can we keep kicking down the road with no clear path to resolve.
1
Show replies
Daniel, do you have a suggestion for end-user consumers like me? I'm a programmer and I can do technical chores but nearly everything in this thread went over my head and I don't know how to turn it into anything actionable as a person who just wants a phone that works
1