Remember that one time Google forced an "Anonymous Coward" to remove the ability to choose alternative search engines in Android?
I can't wait to see how they explain this in the DOJ antitrust lawsuit.
android.googlesource.com/platform/packa
Conversation
Replying to
I expect some of the defense of Android to rest on AOSP and the capability to roll your own ROM, build your own marketplace, etc. Defaults like this will come up but could be explained away because "Android is not a monopoly" and certainly wasn't in 2009. 1/
2
1
Replying to
AOSP requires tons of dev get it to build/boot at all. Then you have to do tons of dev if you want to use boot security, or to remove even -some- of the proprietary bits.
Combine that with keeping up with updates and it is a full time job.
I tried.
1
1
2
Replying to
oh I know. I'm just saying that "we open-source it" will be a Google mantra throughout the lengthy proceedings.
1
1
Replying to
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.
1
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.
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
I will however revisit this when there are other non-google-made AOSP targets well explored by more experienced people such as yourself, because Google itself clearly DGAF if anyone can easily maintain AOSP on their devices.