hardened_malloc

requirements required to be Android, so it can't be referred to as Android, but rather it's an OS with Android app compatibility. It preserves what's actually needed for compatibility in practice, while not being strictly bound by those requirements. The intentional deviations from these are documented, and there are a bunch of them. > Lastly, I wonder how this will do over time considering Fuschia. If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though.

tical approach is using virtualization to reinforce the app sandbox and user profiles. Eventually, the virtual machines can drop having their own Linux kernels (see gVisor as an example of this). In the very long term, the Linux kernel at the core of the OS could eventually go away too. I'd recommend checking out the standalone projects like https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor for an idea of what the project is focused on doing. The hardened_malloc implementation supports other operating systems, as does Auditor, which supports verifying the stock OS on many mobile devices (they need to be added one-by-one to the internal database based on users submitting attestation samples with the app) and CalyxOS in addition to GrapheneOS. The OS project itself is still in the early stage of reviving it, porting over past work and getting the basics done. It's very focused on the infrastructure and low-level work right now. Working on the higher level features that are more user facing and bundling various apps, etc. is not a priority right now. It doesn't even bundle F-Droid right now, because it's not quite at the point where bundling any third party apps makes sense. It also needs to be determined how to best approach that. A lot of these things will also be done in collaboration with other projects like CalyxOS, with GrapheneOS focusing more on low-level security hardening. CalyxOS is primarily working on areas like the backup service implementation and various other higher-level services, and a lot of this will be used by GrapheneOS too.

ing all of the infrastructure and preventing it from ever pushing out another update to the existing installs. The OS was never compromised, but it lost all of the infrastructure and resources supporting it so it has taken a long time to even get some basics back up and running. Most of the initial focus after the disaster was on standalone projects like https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor. It took a long time to get things back up and running, and it has definitely been massively set back both not only in terms of the development work but also in many other ways. It has still managed to continue onwards and while the OS itself hasn't been fully restored, there's a bunch of useful standalone work that's far better than anything the project offered in the past. You're substantially misrepresenting the events that occurred based on a very incomplete account of the events that you've seen. People seeing your comment are going to end up with an incorrect understanding, just as you did. You're stating your assumptions and misconceptions about what happened as if they're facts. It's a very incorrect account of a very small part of the story. This game of broken telephone where people misinform themselves and then propagate variations of that to many other people is a poor way of spreading knowledge.