Phh-Treble author here.

First, to outside looks, your post might be confusing: GrapheneOS and (Phh-)Treble are independent, and complementary. GrapheneOS is focusing on hardening Android (and tbh I'm impressed by Daniel Micay's work). Phh-Treble is about bringing AOSP (the fully opensource Android provided by Google) to the maximum of post-Oreo devices, but using OEM's proprietary drivers. It is technically possible to make a Phh-Treble GrapheneOS, to have an hardened Android that runs on any post-oreo Android device, though that's probably an heresy.

Going back to the subject, I have to say that (one of) my goal when doing Phh-Treble is that some people use my work to create a whole new "Smartphone OS". There are many restrictions, and such a "new Smartphone OS" would probably need to be based on Android to be able to use Treble, but still, imagination is the limit, and you don't need to worry about the drivers! You can just create whatever you think has value, and pretty much anyone can use it straight away! And I'm not just thinking of FLOSS-oriented, privacy-focused, I'd be happy to see alternative "Smartphone OS" emerge.

Looking at Android as it is today, and the opensource apps the community has made, it is possible to make a privacy-focused "Smartphone OS" that is usable to the masses without much effort.

Some other post mentioned /e/, who are people that actually are trying this route. (Though they are totally ignore Treble for the moment...) Though they get quite a bad reputation, for fairly good reason (for instance there are few google "trackers" inside AOSP. they are easy to remove, yet /e/ still have them)

I personly have tried to maintain a distribution of AOSP with pre-installed FLOSS apps to get out of Google's ecosystem, but I haven't had users for it.

Back to the subject of Purism and Librem 5, even though I'm happy such an initiative exists, I feel like they are trying to do too many things at the same time. In my understanding, they are trying to: 1. Make a secure hardware (cf modem over USB) 2. Create a brand new Smartphone OS, going down to drivers, up to applications themselves, basically from scratch. 3. Make a device that runs mainline kernel.

All of those steps can be done independently, and have much higher chances of success if done independently. Also the skill-set required for those are extremely different

> and such a "new Smartphone OS" would probably need to be based on Android to be able to use Treble

Not really, one could most likely use libhybris and Halium to run Project Treble's userspace parts on a fairly ordinary Linux distribution. In fact, I'm surprised that people aren't starting to test this using the likes of Debian, or Arch, or even pmOS.

(One of the remaining issues is that Project Treble images aren't really as standard or unified as people assume them to be, there are a few varieties based on architecture (32- vs. 64-bit) the "hardware-native" Android version (Android 7, 8, 9, 10) that ships on the device, and "A-only" vs. "A+B" booting scheme. But it sure beats having to use one image per phone model, and having to include proprietary blobs in the image.)

Android is a bit of a siren... since there are many devices on current hardware working great, it looks like it should be possible to be the starting point for a lovely FOSS solution.

But it isn't, due to the Android approach of piling together unmaintainable vendor junk like gpu driver and sensors on old kernel that doesn't work with FOSS gpu apis, radioactive horror story wifi / bt stack using non-upstream apis. The different kernels as a whole are individual flies in amber that are impossible to keep working on newer upstream basis.

Therefore your 'secure FOSS phone' becomes the usual Android security apocalypse as soon as the vendor stops patching the security holes found monthly; that's if your vendor even bothered patching and updating those pieces quarterly or even once.

Purism got it right that there's no way to get the needed result - that it's like putting linux on your x86_64 laptop - out of Android / existing devices. The story seems to be about whether their laptop business and the kickstarter gave them enough runway and ability to pay suppliers up front for initial production.

> But it isn't, due to the Android approach of piling together unmaintainable vendor junk like gpu driver and sensors on old kernel that doesn't work with FOSS gpu apis

That's not the Android approach, it's just the embedded-on-ARM approach that Android inherited wholesale. Pre-Android Linux mobile/embedded OS's were just as bad. In fact, we're starting to see some improvements. The SoC's used in the latest Google Pixel (3 and 4) phones are getting mainline support in the Linux kernel.

Could Treble enable a containerized environment for OSS distributions on certified Android-shipping hardware?

I'm thinking of something using an upstream kernel with cgroups and other required options to run containers enabled, libhybris or similar for low-level drivers.

There would be a default e911-capable dialer that would provide basic phone capabilities when other containers aren't running.

The containers would share fullscreen access to a wayland socket or similar arbiter of the display device.

Users could support Android in a container, and any X or wayland-based userland.