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
AOSP already works reliably without Play services. We currently don't bother bundling assorted apps rather than letting users choose apps of their choice from F-Droid, Aurora Store (Play Store) and elsewhere. We intend to fill in functionality provided by Play services but we
2
1
AOSP works reliably without Play services only after you provide and continually fix lots of tooling to even get it to build and even then one has to extract factory image bits.
That, by itself, is a non trivial amount of work to maintain as I know all to well now.
2
It's not a compliment, it's an attempt to use my name to peddle misinformation which we see as quite harmful towards GrapheneOS and getting the issues we have with hardware addressed. Inventing problems we don't have and distracting from those we do doesn't help us. It hurts us.
1
I was just giving you credit for all the hard work you did on android-prepare-vendor and lots of research and time to work out secure boot and all the other things Google failed to provide in their tools and docs to get AOSP actually working for each hw/release combo.
2
I'll avoid crediting you for this work in the future if you think it is harmful. Sorry.
2
We do not do any work on getting AOSP building or fixing issues with the AOSP tooling, etc. Device support is something we work on, primarily because of the device-specific hardening we do. Most of the device-specific work is resolving issues with low-level hardening features.
1
Pixels do not make our life easy, but they offer the best privacy and security when running an alternative OS. It would be easier for us to support other devices, especially with major version migrations. They don't meet our standards.
Most of the community interested in replacing the OS cares little for security so OEMs don't bother to make it possible to do without losing many hardware-based security features. The level of support for this from a vendor also tends to be inversely related to their security...