It uses the kernel from the SoC vendor, for example Qualcomm, for the Xperia 10 III.
This requires libhybris to get the drivers working with a non-Android userland.
This in turn means the phone can only be updated as long as Qualcomm continues patching the kernel.
And this is why you run an outdated kernel once Qualcomm drops support, which will happen quickly. It’s the same for other SoC vendors. They are in the business of selling SoCs, not supporting them.
Mainline support solves that. SailfishOS can also be built with a mainline kernel.
I am in fact working on mainlining the Xperia 10 III. Once I’m done, you can flash an image with a mainline kernel and continue updating the kernel until the phone breaks, not until Qualcomm stops caring.
Next step would be upstreaming some patches to the kernel, I just need to find the time.
Someone more skilled and knowledgeable than me in mainlining could probably get most of the remaining things done in a couple days, but I need to read a lot of docs and try out a lot of things.
It’s not that hard, the hardest part is finding the right info, I don’t even know C. I just enable the components that have drivers and leave the rest until someone writes the driver. :)
Definitely not mostly Android. It’s their own Linux distro/flavour with an “Android compatibility layer” like Waydroid and (gradually open sourced) system components. Ubuntu Touch has a similar approach and I believe postmarketOS as well. I really hope that Jolla’s next community device brings them some more traction and subsequent development velocity. I tried installing SailfishOS on my Fairphone 5 but it is not (yet) a polished setup experience from first boot. If they can polish that, I think it’s a great OS to facilitate a gradual move from privacy-hell. It would allow absolute must-have apps to live in locked down Android compatibility mode while there’s no viable alternative and more and more of your data living in a tracking-free OS.
libhybris literally uses an Android comtainer to bridge over Android kernel drivers from the SoC vendor to the Linux (non-Android) userland.
EDIT: postmarketOS has a mainline strategy, you could create a downstream port, but ultimately their goal is to create strong mainline support for many devices.
AFAIK they offer a way to port their OS to Android devices by re-using the drivers built for Android when building a SailfishOS image for non-native hardware. I personally wouldn’t call that “it’s mostly Android”, but that might be where we have different interpretations. Your initial comment came across as if it was a glorified launcher or a deGoogled Android. If I interpreted that wrongly, my bad. Cheers
I’ve changed wording from “mostly still Android” to “mostly still Android kernel and Android drivers”, I agree, might have been a bit unclear.
Anyway, libhybris requires running half an Android system in a container, so I believe it’d be fair to say it is… half an Android system and a somewhat regular Linux userland with a proprietary UI.
It’s important to know that it can only be updated as long as the SoC vendor provides updated kernel sources.
It’d take months to rebase it onto a new kernel. Just trying to port the drivers would take more time than mainlining. But once you keep things upstream, it suddenly becomes much easier to maintain.
That’s where mainlining comes in.
For example, I am mainlining the Xperia 10 III to make sure it does not become obsolete trash and can still ne used in a couple years:
Yeah, but that does not change anything about the kernel. You can no longer update it if the vendor drops support. Even if the distro had much older roots, it still uses a vendor kernel that has been patched to death.
They use an Android kernel. How does it matter how nice their proprietary UI is if the phone can no longer be updated once Qualcomm, for example, no longer patches the kernel?
We desperately need more mainline support, this isn’t sustainable.
It’s not a standard kernel, it is a vendor kernel. It has sooooo many patches it becomes close to impossible to update then by rebasing. That’s where the mainlining efforts come in: Upstream first.
It’s always easier to maintain something upstream than to try to maintain a downstream fork.
I’d also argue that the mainline kernel tends to have better security, as the drivers have far more eyes on them than the vendor driver kernels.
What about SailfishOS?
I use it and it’s really nice.
That’s just some Linux userspace with an Android container and an Android kernel. It is mostly still Android kernel and drivers.
I don’t expect them to support devices for very long.
Hmm… are you sure?
In their docs they say it uses the Linux Kernel and bridges other Linux libraries including those used in Android.
It does provide a way to install Android apps in a sandbox.
They have their own hardware phones and do support some Sony Xperia phones, which is the one I have.
It uses the kernel from the SoC vendor, for example Qualcomm, for the Xperia 10 III.
This requires libhybris to get the drivers working with a non-Android userland.
This in turn means the phone can only be updated as long as Qualcomm continues patching the kernel.
And this is why you run an outdated kernel once Qualcomm drops support, which will happen quickly. It’s the same for other SoC vendors. They are in the business of selling SoCs, not supporting them.
Mainline support solves that. SailfishOS can also be built with a mainline kernel.
I am in fact working on mainlining the Xperia 10 III. Once I’m done, you can flash an image with a mainline kernel and continue updating the kernel until the phone breaks, not until Qualcomm stops caring.
Very interesting. Yes I run Sailfish on a Xperia 10 III.
But was not aware of the kernel being supported by the SoC.
Seems like you’re involved in an interesting project.
I’m quite curious about it.
Can you check how old your kernel is?
uname -rMine is 4.19.248
https://endoflife.date/linux
Very longterm, support ended over 1 year ago. That kernel is 7 years old…
Android is very conservative with kernel upgrades, but this is insane.
I didn’t know this.
Kernel is still a gray area to me.
Can I update it while maintaining Saifish?
Still early days, but hopefully I’ll at some point have it all working.
This is my current progress: https://git.erebion.eu/forgejo/erebion/pdx213-temp
Next step would be upstreaming some patches to the kernel, I just need to find the time.
Someone more skilled and knowledgeable than me in mainlining could probably get most of the remaining things done in a couple days, but I need to read a lot of docs and try out a lot of things.
That is some impressive stuff, well done!
I’m a software developer but nowhere near kernel stuff.
I do have a curiosity to learn more about kernel development.
Definitely will check it out later.
It’s not that hard, the hardest part is finding the right info, I don’t even know C. I just enable the components that have drivers and leave the rest until someone writes the driver. :)
Fair enough.
But looks cool regardless.
Definitely not mostly Android. It’s their own Linux distro/flavour with an “Android compatibility layer” like Waydroid and (gradually open sourced) system components. Ubuntu Touch has a similar approach and I believe postmarketOS as well. I really hope that Jolla’s next community device brings them some more traction and subsequent development velocity. I tried installing SailfishOS on my Fairphone 5 but it is not (yet) a polished setup experience from first boot. If they can polish that, I think it’s a great OS to facilitate a gradual move from privacy-hell. It would allow absolute must-have apps to live in locked down Android compatibility mode while there’s no viable alternative and more and more of your data living in a tracking-free OS.
libhybris literally uses an Android comtainer to bridge over Android kernel drivers from the SoC vendor to the Linux (non-Android) userland.
EDIT: postmarketOS has a mainline strategy, you could create a downstream port, but ultimately their goal is to create strong mainline support for many devices.
AFAIK they offer a way to port their OS to Android devices by re-using the drivers built for Android when building a SailfishOS image for non-native hardware. I personally wouldn’t call that “it’s mostly Android”, but that might be where we have different interpretations. Your initial comment came across as if it was a glorified launcher or a deGoogled Android. If I interpreted that wrongly, my bad. Cheers
I’ve changed wording from “mostly still Android” to “mostly still Android kernel and Android drivers”, I agree, might have been a bit unclear.
Anyway, libhybris requires running half an Android system in a container, so I believe it’d be fair to say it is… half an Android system and a somewhat regular Linux userland with a proprietary UI.
It’s important to know that it can only be updated as long as the SoC vendor provides updated kernel sources.
It’d take months to rebase it onto a new kernel. Just trying to port the drivers would take more time than mainlining. But once you keep things upstream, it suddenly becomes much easier to maintain.
That’s where mainlining comes in.
For example, I am mainlining the Xperia 10 III to make sure it does not become obsolete trash and can still ne used in a couple years:
https://git.erebion.eu/forgejo/erebion/pdx213-temp
Sailfish is based on MeeGo and Moblin and itself has been around for almost 15 years.
Yeah, but that does not change anything about the kernel. You can no longer update it if the vendor drops support. Even if the distro had much older roots, it still uses a vendor kernel that has been patched to death.
Nope, in fact, Jolla with SailfishOS is the only one among those mentioned that uses an OS independently developed.
They use an Android kernel. How does it matter how nice their proprietary UI is if the phone can no longer be updated once Qualcomm, for example, no longer patches the kernel?
We desperately need more mainline support, this isn’t sustainable.
It’s time to bring X86 into phones back. Latest X86 CPUs are on par with ARM in terms of efficiency.
x86 phones don’t necessarily have ACPI and x86 alone does not make it simpler.
No, let’s ensure manufacturers upstream early so that we can support devices early.
Now we can’t even ensure manufacturers give us unlockable bootloaders.
We can do hat now, just requires the right regulation…
They use a standard Linux kernel with Android drivers trough libhybris. The proprietary UI and middleware is a mistake, I agree with that
It’s not a standard kernel, it is a vendor kernel. It has sooooo many patches it becomes close to impossible to update then by rebasing. That’s where the mainlining efforts come in: Upstream first.
It’s always easier to maintain something upstream than to try to maintain a downstream fork.
I’d also argue that the mainline kernel tends to have better security, as the drivers have far more eyes on them than the vendor driver kernels.