this post was submitted on 12 Jun 2025
57 points (100.0% liked)

technology

23822 readers
42 users here now

On the road to fully automated luxury gay space communism.

Spreading Linux propaganda since 2020

Rules:

founded 4 years ago
MODERATORS
 

More recent updates: https://www.androidauthority.com/google-not-killing-aosp-3566882/

https://grapheneos.social/@GrapheneOS/114665423084970607

And updates from the Graphene chatroom:

it [porting] is not faster than expected. we finished most of what we thought we were going to need to do already. if they had not dropped a bunch of what we need, we could be doing experimental releases soon. instead, we do not know how long it's going to take to add back Pixel support to Android 16. Android Open Source Project no longer supports Pixels. we have to implement it ourselves in a new way, different than what we have done previously. we are missing our most talented and productive developer due to the conscription situation. the kernel port is a trivial part of it and they made that harder by no longer publishing kernel commit history and splitting the previously unified kernels into 3 separate groups.

Pixel 6, Pixel 6 Pro, Pixel 6a and Pixel 9a share a kernel branch. Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro and Pixel 8a share a kernel branch. Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL and Pixel 9 Pro Fold share a kernel branch

there is a 1 line difference between the first 2 groups. there are major differences between the first 2 and the 3rd group.

before Android 16 it was fully unified, they messed that up, and dropped source code history from AOSP for Pixel kernel modules. the Pixel device repositories and hardware repositories are gone so we'll need to fork the 15 QPR2 device support and remove all the code, getting it from adevtool for now instead. this kills our hardware-based USB-C port control feature. we'll need to reimplement it in a new way

you are viewing a single comment's thread
view the rest of the comments
[–] MizuTama@hexbear.net 5 points 3 days ago

I don't get your last point. Fairphone doesn't have the hardware security measures that are needed to ensure gOS has its security needs. There are other OSs that are focused on de-googling like /e/OS (which you can have your Fairphone come with).

They shouldn't turn the project towards Fairphone as it defeats the project's purpose, if anything you could argue for them to maintain a separate fork but I believe when it was mentioned to them they pointed out that would split dev time and resources, reducing the security of the main project and that other OSs exist for those use cases.