Murena could, Jolla could, GrapheneOS could do that too (possibly Nexphone also did but we'll find out; only GrapheneOS will give us flagship experience though). Of course these (except Jolla?) are still based on the Android model, but this itself doesn't preclude creating a non-user-hostile OS (of course Google would never certify it), proprietary black-box OEM code only assumes some Android elements, not the end user experience..
I have terrible news for you about how the official firmware works.
I've seen some e-waste ODM (Tinno) code and their freestyle philosophy on modifying the kernel code.. however they at least have to fix this so that basic functionality works as there's QA and serious bugs will affect certification and they'd not get paid. But here if you report a bug to PostmarketOS (but well, even LineageOS), nothing will happen unless you fix it (and if you submit a patch, it will sit there forever, welcome to FOSS).
My general understanding of the Android ecosystem is that they do write drivers, and you don't want those drivers
What's wrong with pixel drivers for instance? I'm of course not talking about those written by e-waste ODMs like Tinno who can't even release GPL kernel sources properly.
What's wrong with pixel drivers for instance? I'm of course not talking about those written by e-waste ODMs like Tinno who can't even release GPL kernel sources properly
A couple of issues , back from my sailfish os porting days (haven't touched it in half a decade so things might have changed):
1. You would still need to run a lot of Android user space to make use of these drivers. We had a separate second init system that runs a stripped down version of Android init, starting enough services to make use of these drivers.
2. These binary drivers are tied to the kernel and Android versions that were released with the phone. So if you wanted some of the newer kernel features (back then it was like better container support), you're out of luck.
Usually, all this means you rely on a lot of hacks to fix some bugs... And porting takes a lot of time and effort.
One thing that has changed in around that time (maybe) is that GKIs[1] are now standard across (Google-branded) Android devices. Board/SoC support is handled via kernel modules now. The builds are directly from the Android Common Kernel, and an explicit goal is to be able to upgrade kernels on-device. (This has actually been demonstrated on Pixel devices, though I'm not sure how widespread it's been across others.) The Common Kernel also doesn't take contributions, and specifically encourages vendors to just upstream their drivers instead. Not that this fully solves the problems you're describing, but Android as a platform has become more intentional about dealing with kernel fragmentation and making itself more structurally friendly toward mainlining.
For the Pixel specifically, Google actually is working to upstream its hardware drivers and enable devices to boot off mainline. [2]
Comments
Murena could, Jolla could, GrapheneOS could do that too (possibly Nexphone also did but we'll find out; only GrapheneOS will give us flagship experience though). Of course these (except Jolla?) are still based on the Android model, but this itself doesn't preclude creating a non-user-hostile OS (of course Google would never certify it), proprietary black-box OEM code only assumes some Android elements, not the end user experience..
I've seen some e-waste ODM (Tinno) code and their freestyle philosophy on modifying the kernel code.. however they at least have to fix this so that basic functionality works as there's QA and serious bugs will affect certification and they'd not get paid. But here if you report a bug to PostmarketOS (but well, even LineageOS), nothing will happen unless you fix it (and if you submit a patch, it will sit there forever, welcome to FOSS).
What's wrong with pixel drivers for instance? I'm of course not talking about those written by e-waste ODMs like Tinno who can't even release GPL kernel sources properly.
A couple of issues , back from my sailfish os porting days (haven't touched it in half a decade so things might have changed):
1. You would still need to run a lot of Android user space to make use of these drivers. We had a separate second init system that runs a stripped down version of Android init, starting enough services to make use of these drivers.
2. These binary drivers are tied to the kernel and Android versions that were released with the phone. So if you wanted some of the newer kernel features (back then it was like better container support), you're out of luck.
Usually, all this means you rely on a lot of hacks to fix some bugs... And porting takes a lot of time and effort.
One thing that has changed in around that time (maybe) is that GKIs[1] are now standard across (Google-branded) Android devices. Board/SoC support is handled via kernel modules now. The builds are directly from the Android Common Kernel, and an explicit goal is to be able to upgrade kernels on-device. (This has actually been demonstrated on Pixel devices, though I'm not sure how widespread it's been across others.) The Common Kernel also doesn't take contributions, and specifically encourages vendors to just upstream their drivers instead. Not that this fully solves the problems you're describing, but Android as a platform has become more intentional about dealing with kernel fragmentation and making itself more structurally friendly toward mainlining.
For the Pixel specifically, Google actually is working to upstream its hardware drivers and enable devices to boot off mainline. [2]
[1] https://source.android.com/docs/core/architecture/kernel/gen...
[2] https://lpc.events/event/17/contributions/1445/