hello
years ago when i learned about sailfishos project, i also read that sailfish was tearing it’s roots in hybris/halium, depending itself of AOSP/android of google.
I never read (yet) that sailfishos was today 100% independent of AOSP (a bit like purism, who is supposed to have no ties with AOSP), but i dont know if it’s official or not yet.
so i just ask : how dependent of AOSP/hybris/halium is Sailfish, for any kind of device?
thank you vm 
A very good explanation can be found here:
SFOS can work without Android! In practice this is more challenging because of the device vendors landscape
but what is the relationship between sailfish and hybris?
i read somewhere that sailfish isnt using hybris anymore, or only on non-jolla devices..
it’s very ambiguous to me, and i try to understand, eg if tomorrow google says “AOSP is not open source anymore” (that may happens one day), then all device would lose their compatibility to third-part OS?
as i see postmarketos is totally AOSP-free, of what i undertsood
i understand that sailfish is still a bit aosp-dependent, especially due to hybris.. but im not sure of it ; eg postmarketos or pureos are (normally) completely aosp independent, and doesnt use their code, to be 100% freed of google/AOSP project.
SFOS is independent from Google/AOSP in terms of OS. It is only for certain (most, unfortunately) devices that SFOS use hybris to get SFOS to work as there are none easily available drivers otherwise
PureOS is a Debian derivative, in that sense it has nothing to do with Android (AOSP or otherwise).
All the operating systems you mention need hardware drivers. This is just the way software is generally split into a part that works everywhere and a part that only works on the specific hardware used. Simply put, the driver for an Intel WiFi chip won’t work for a Redpine WiFi chip.
The OS talks to drivers through an interface that is specific to the OS. Edit: Simply put, a display driver for MS-DOS won’t work for Windows 11, and a Windows display driver won’t work for MacOS.
In the case of a PC, hardware is pretty standardized and there are drivers available, so you can install e.g. Linux on almost any computer you buy and have functioning keyboard, WiFi and display.
Phones are different[1]. Hardware is not standardized, and drivers are supplied by the maker of the system-on-chip (SoC, e.g. Snapdragon or Dimensity). These drivers follow the Android conventions for communication with the OS, since Qualcomm or MediaTek have 100% of their sales to makers of Android devices.
To run on phones, any OS has to use these drivers, and thus any OS running on a phone has to use the Android way of talking to drivers. To my understanding, libhybris is a translation layer to let a standard Linux talk to Android drivers.
This doesn’t make alternative OS:es depend any more on AOSP (the OS) than the hex keys in your toolchest depend on IKEA. You can get a key from any supplier and still be able to tighten every bolt that complies to this specific interface.
The Librem 5 is not based on Android hardware, so uses Linux drivers. This hardware choice comes at a cost. ↩︎
Correct me if i am wrong, but generally said SFOS sits on top of some Android Blobs modem an this kind of parts are using Android a base, and on top of this they have put SFOS. So as long somebody company or developper reverse engineers this part of Android, we cannot say that we are not using Android. Again, correct me if i am wrong. But wasn’t there a point where SFOS had to decide if they wanted an UBtouch or AOSP base, and the decided for AOSP?
Ehm. Several things here:
sits on top of some Android Blobs
Android a base, and on top of this they have put SFOS
In practice it often it does, on top of libhybris which in turn interfaces with “some Android blobs”.
However, SFOS is plain regular Linux (Kernel + glibc + stuff). It does not depend on anything Android.
Some ports demonstrate this, in that they do not use hybris and therefore have no dependencies on anything Android. Like the Pine port already mentioned. One other such port is the x86_64 “tablet” port, which actually boots Ubuntu and then runs Sailfish OS on top of that.
modem
There are some modems whose “firmware” is indeed a stripped-down Android, running completely separately “inside the modem”. Operating systems using the modem communicate with it using things like adb to install config files etc.
This is some modems, and is the case with any operating system running on the actual SoC. It has nothing to do with the drivers of the rest of the system. In theory, on such hardware, if you ran a stock Linux kernel, or whatever other OS, you would still have this Android “island” running inside the modem.
No. Sounds like AI hallucinations to me.
By the way, UBtouch can also use libhybris to run on phones built for Android.
To my knowledge you are mixing the adaptation to a device and the OS. Most phones with SFOS are using Android drivers (and thus a need to rely on hybris to communicate with them) but this is because there are no other drivers available. Pinephone adaptation with SFOS for example does not need anything related to Android.
Isn’t UBPorts based on the same libhybris that Sailfish uses? So the “choice” you outline doesn’t exist.
The blobs you refer to are either hardware drivers (please see my comment immediately above yours) or needed by different parts of the hardware (see below). In both cases they are related to hardware, not to Android per se.
Examples of the “other kind”: Modem, WiFi chip, memory subsystem. These may need configuration data to work properly (like which frequencies are allowed in a certain region), or they are computers in their own right that need software. Proprietary bits of config and software is then supplied as blobs, that will be fed into these systems as the device powers up.
While it is possible that the software inside a blob is based on Android, it would generally be a poor choice. A far more sensible choice would be some real-time OS. We can’t know, because these blobs are proprietary, opaque bundles of bits. (Thats sort of the definition of a blob.)
If this is a concern for you, get a LIbrem 5. Purism put huge effort into making the running system only use free/libre code to the extent possible, at the cost of some functionality plus a more expensive and bigger device.
And thinking/asking/discussing this please do not confuse these things:
Do not mash them together, be aware what they are and mean, and don’t interpret any of them meaning “Android” (except the first).
Side note: “Android kernel” is a misnomer. There is no such thing as an “Android kernel”. Android does not have its own kernel. It uses the Linux kernel.
Hardware vendors however almost never upstream their drivers etc into the main Linux kernel, therefore Android distributions (Google, or Lineage or whoever) must use these kernel forks.
There used to be a time when Google maintained their own fork of Linux, mainly to integrate their Binder technology, but Binder has been merged in mainline a long time ago.
Have you read anywhere that is was dependent on it? Where?
Because the majority of officially supported devices, the Sony Xperia line, are not even using AOSP.
Are you using AI to learn about Sailfish OS? If yes, stop doing that.
so, in others terms, if tomorrow something “happens” to AOSP, means it doesnt stay opened accessible, nothing would change for sailfish, to continue it’s own path, instead of graphene/lineage, for example?
so hybris is a sort of software layer using aosp code to make linux-based distros, compatible with some specific devices?
i thought hybris was for phone uncompatible with mainline, using hybris to run downstream “pure linux” kernels, and hybris was depending on aosp.. but i may be wrong, as i read lot of things here and here..
In practice, pretty much.It still technically has nothing to do with AOSP though.
It has todo with being able to use libraries which expect the Android runtime (Bionic) from Linux programs which use the Linux runtime (usually GNU Libc).
Such libraries or drivers may be in AOSP, but they may come from elsewhere too, like vendor packages, or LineageOS or whatever.
Sailfish would be able to stay on its own path. As long as the interface to Android drivers remains known, Sailfish will still run on hardware made for Android.
If Google changes the interface after making it closed source, then who knows? Major phone makers will probably maintain their cosy relationship with Google, so devices following the old AOSP conventions may become scarce. Licenses may or not be available to Jolla. The license fee may be bearable or outrageous.
No. libhybris is a software layer that conforms to the Android device driver interface in one end and the standard Linux way in the other end.
I think you nailed it.
No modern operating system is inherently compatible with any hardware at all, because they are made to be hardware independent. Drivers are what lets an OS run on specific hardware, and the drivers are often (but not always) provided by the hardware manufacturer.
In doing so, manufacturers make drivers follow the expectations of the OS. This generally means what Android expects, when it comes to phones. When the hardware is intended for embedded systems (computers that don’t look like computers) it often means Linux.
For this reason, Purism picked a SoC for embedded systems for their Librem 5, so they could run mainline Linux and open drivers on it. (Unfortunately for them, mainline support was not as good as expected, so they had to put a lot of work into kernel and drivers.)
Which sfos ports use halium?
No, UBPorts uses halium (yes libhybris underneath), but it’s like an extra layer for things like NetworkManager vs connman, do really some sfos community ports go this roundabout way?
I don’t think any finished/released ones do, not sure.
But there was a PoC screenshot on one of the IRC channels once, I think it was some Samsung device running it? I forget.
Anyway, there is a Halium repo on OBS: