this post was submitted on 19 Feb 2026
583 points (99.3% liked)
Technology
81451 readers
4451 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If it's just a fork of Android, doesn't that mean 194 days from now they either need to branch off entirely and write their own code from here on out....
Or....
Never advance the base code?
Neither is true, that's not how forking works. But there is some truth to it in that it can start to become significantly more difficult to keep in sync as time goes on, depending on how obnoxious the security becomes and how many places they have to remove it.
Consider the trivially naive case where Google implements this feature in a single function: "function app_is_signed() -> bool" then the fork just adds "return true;" to the beginning of that function, and happily merges every other update Google makes from then on with zero issues. Even if the code for "app_is_signed" itself changes, nobody cares, because the first thing it does is return true and everything else Google ever tells it to check or do is ignored, the function can still be used everywhere throughout the code, it just no longer actually checks anything in Graphene, whereas it does check things in Google's Android.
Of course the reality is much more complicated than that, but the principle is the same. It's only a question of how obnoxious and difficult Google chooses to be about it. They could move the function around every update, or use many different functions, make a whole system out of it, make it do crazy cryptographic validations and checksums in various different places of the code, have watchdog tasks that are checking that the validation code is getting used. They could be really, really obnoxious about it, if they want to be, and they have more resources than the Graphene OS developers probably do to undo and keep undoing all these obstacles, so if they really want to devote that much time and energy to making Graphene's position untenable, they can. But they could also be doing that now, and they're not. Crackers have been fighting these sort of battles against copy-protected software for ages, it's the same principles, and much of the same economic choices go into it. How much does Google want Graphene OS to go away? How much is it worth to them? It has to have a dollar value to them, and that dollar value might be significantly higher than they're willing to bother with.
No. As long as the base remains opensource (AOSP), they can remove the bad parts. Graphene has made numerous contributions to AOSP, I'm confident they can manage that. And if the user base growths, I hope their fundings will follow.
It would be a good thing for the world if AOSP was forked with big resources behind an open project with an open governance. But that needs lot of resources.