With everything Google is doing with Android, they might not have a choice. It’s either this or possibly one day no longer being able to work on Graphene.
Graphene would be better off cutting themselves off from Google’s OS future entirely and pivot the fork as quickly as possible to remove all dependencies. Probably too arrogant to consider it, though. Also becomes much more work.
Step 2: Keep receiving Google security updates but stop updating Google mainline
Step 3: Start replacing the underbelly to just raw Linux (or BSD or whatever) and slowly shift the “Android” portion to a VM/container
Step 4: RIL and other stuff (probably should happen first) have to be packaged up and become their new entity on the modem side (also probably the biggest challenge, but manufacturers and ODMs provide dev kits)
Step 5: ???
Step 6: Once the Android side is safely firewalled away from the core OS, start embracing something like PostmarketOS
Step 7: GUI/graphics are built out with the Android pieces still running in a container
Step 8: Start writing applications that replace the Android applications, go one by one, remove dependence on each Android application as you go while still maintaining compatibility (I mean the core OS ones that make the device at least basically functional, the F/OSS devs will have to each rewrite/change their apps, or some other magic can be inserted here that isn’t really magic.)
Step 9: Once the OS itself is beefed up enough, retain Android container for the needs of some for some uncomfortably long frustrating time to maintain, but not too long
Step 10: Have Obtainium/F-Droid/etc. all simultaneously pivot and start providing apps for the native OS as well as maintaining backwards compatibility with the Android apps in the container
Step 11: Once some magic point, forced or otherwise happens, sunset the Android portion of the app stores. Keep the containerized Android around a little longer
Step 12: Sunset the Android container, at this point the phone should be running 100% “native” OS and apps and store
Step 14: Profit!
There are industry blueprints for this. Apple is probably the best example of how to implement these shifts, from OS 9 (co-op MT proprietary OS)->OS X (BSD-NextStep-based Unix OS), 68k->PPC, Replacing Unix underpinnings with Apple Frameworks, PPC->Intel, OS X->iOS, Mac from Intel->ARM, etc. etc. They frequently used containerization to keep the old running while the new was built up around it and replaced. It is a solid proven design pattern.
And edit72: I’m not just saying “hey magic people do this” - I’ve done this shit. I’m down to help, and I will. But the project owners need to step up for some actual work instead of just putting potpourri on something someone else built. Annoying side-story, I figured out how to cross-compile/rebuild/fix dependencies on a CPAP app called Oscar so it would be ARM-native on ARM Macs. Couldn’t figure out how to contact the devs after much digging to let them know, so. I have 1 of 1 copy of that app running ARM-MacOS native. Would be neat to help them replicate it though.
I think that sounds like a damn solid plan, personally. Not sure if the GrapheneOS devs would go for it. The lead dev (who I thinked stepped down, so may not be a factor now) had some strongly negative opinions towards a Linux phone due to all of its security holes compared to Android, but like… It’s not as if those things couldn’t be addressed like you describe. It would just take time.
I’m skeptical. Even knowing how paranoid Daniel is about, well…everything.
Who remembers the last time a custom ROM got an OEM deal? It is the reason Lineage OS exists today…
With everything Google is doing with Android, they might not have a choice. It’s either this or possibly one day no longer being able to work on Graphene.
Graphene would be better off cutting themselves off from Google’s OS future entirely and pivot the fork as quickly as possible to remove all dependencies. Probably too arrogant to consider it, though. Also becomes much more work.
Google has more people working in Android then GrapheneOS does, it’s not possible for them to go completely independent.
Google will forever control Android. I would prefer if he just worked on Linux (phone & desktop) to the benefit of all.
You’re under-thinking it.
In pseudo-correct but probably not order:
There are industry blueprints for this. Apple is probably the best example of how to implement these shifts, from OS 9 (co-op MT proprietary OS)->OS X (BSD-NextStep-based Unix OS), 68k->PPC, Replacing Unix underpinnings with Apple Frameworks, PPC->Intel, OS X->iOS, Mac from Intel->ARM, etc. etc. They frequently used containerization to keep the old running while the new was built up around it and replaced. It is a solid proven design pattern.
And edit72: I’m not just saying “hey magic people do this” - I’ve done this shit. I’m down to help, and I will. But the project owners need to step up for some actual work instead of just putting potpourri on something someone else built. Annoying side-story, I figured out how to cross-compile/rebuild/fix dependencies on a CPAP app called Oscar so it would be ARM-native on ARM Macs. Couldn’t figure out how to contact the devs after much digging to let them know, so. I have 1 of 1 copy of that app running ARM-MacOS native. Would be neat to help them replicate it though.
I think that sounds like a damn solid plan, personally. Not sure if the GrapheneOS devs would go for it. The lead dev (who I thinked stepped down, so may not be a factor now) had some strongly negative opinions towards a Linux phone due to all of its security holes compared to Android, but like… It’s not as if those things couldn’t be addressed like you describe. It would just take time.
deleted by creator