> PostmarketOS can't partner with any OEM/ODM

Is there any precedent to believe that such a thing is in fact possible?

> and volunteers have to use hacks

I have terrible news for you about how the official firmware works.

> to unofficially implement basic Android 1.0 functionality years after a device was released?

Conversely, in other places it's far better than Android 1.0. But yes, if you can only start developing against the device after it's released, then your software will be released after the hardware ships plus development time.

> That's sad to see. This is just lame, drivers should be implemented by those who work on them..

My general understanding of the Android ecosystem is that they do write drivers, and you don't want those drivers. I like to imagine that somewhere that out there somebody must be making phones with high quality software, but I've never heard of them.

▲

zb3 8 hours ago | parent [-]

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.

	▲	saidinesh5 2 hours ago \| parent [-]
		> 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.