Probably. Hopefully the opposition points out the countless hours people like and others need to do to even partially de-google devices.
Back in the G1 days it was easy. Back then Google paid people full time to make sure AOSP was solid and easy to build/use.
Conversation
That's not an accurate or fair assessment of our work. It is not what we do and what the project provides. GrapheneOS builds privacy and security technologies. AOSP is a solid base for us and we've never had problems building it. You continue to misrepresent the actual issues.
2
1
I was not referring to end products like GrapheneOS (which is why I didn't name it) but was specifically referring to all the work you and others do to get each AOSP to work reliably without Google bits so additive work like GrapheneOS is even possible.
2
By no means did I mean to imply in any way that anyone used to Google services will find replacements in GrapheneOS.
Was just trying to point out you do a lot of work to get AOSP baselines working on Google hardware so derivative works can even begin.
1
Sorry for tagging you without more context.
Was just trying to say that the days of someone being able to go and get even a bare-bones OS on an official Google device is a substantial amount of work today, let alone making it more secure or making replacements for Google bits.
1
There's a big difference between building AOSP and building an OS that runs on Google's Pixel phones. We're definitely not happy with the lack of support they provide for their devices and the lack of urgency Google and Qualcomm have towards open source SoC support at launch.
1
AOSP is fine and we don't have any problems building it. It's not an issue that we have to handle. We also don't have an issue with AOSP expecting us to provide the user-facing apps. If we weren't so reluctant to include GPLv3 code, it'd be easy to replace those sample apps.
1
Trying to go from source.android.com to working secure booted AOSP on a Pixel device with only the driver bundle they claim you need was a complete waste of time.
One has to ignore their docs and build custom tooling, as I had to do. AOSP dev has a high barrier to entry.
2
Yeah the one missing bit is their driver bundle includes a prebuilt vendor.img which their tooling won't sign by default.
There's some patches sent upstream which fix this, such as android-review.googlesource.com/c/platform/bui which should address this.
1
But apart from this the driver bundle does always work from my experience.
It's nice to be able to get a new device and just build something for it that will work out of the box, and then do the additional work that we do based on that.
No other device is as easy to support.
1
Sony devices have published code that works out-of-the-box. We don't target them because they've historically made many hardware security features unavailable to alternative operating systems, and haven't had good firmware and hardware privacy/security in the first place.
It would be easier for us to support devices like those where we got more time to migrate to new major versions. Due to Treble, we could still move as early as we want, but we wouldn't be forced to do it since they don't upgrade device support to the new release as quickly.
I think Sony is the one OEM that still cares about this, they do a lot of work on their Open Devices project at github.com/sonyxperiadev - and they upstream their patches to AOSP, in general and specifically for this as well.
1
I don't trust Sony after the removing-linux-on-ps3 ordeal... but if someone actually gets one of these and verifies AOSP just builds from source as documented and works on it as documented and maintained by them, then that is pretty hard to argue with and I would gladly try it.
1