(Un)Adventures in SailfishOS: too little, too late

Around 8 years ago I purchased a Moto G 2014 LTE: a mid-ranger phone with great speakers and an acceptable SoC for the time.

The reasoning behind my choice was to experiment with Android's codebase and actually get good at Android ROM development, while at the same time push the device's lifetime to its extremes.

After having put away my daily driver Nexus 5X, this was my only phone left together with a Lumia 635 that I would have never for the life of me used ever again, after being forced to use it an entire summer.

On the Moto, unlike the Lumia, I was able to port LineageOS 17.1 after modifying some existing (but very obscure) device trees, yet the final result ended up being quite disappointing.

The UI was bonkers slow in many places and the phone would only be able to keep two apps at best in the background with its 1G of RAM, even after updating the ROM configuration to Android Go; opening apps like Firefox rebooted the handset, Android's VPN support was (and remained for very long) broken and alarms fired later and later with each passing day.

The fixes were hard to find, deep in the 3.4 ACK but eventually made it into my Motorola msm8226 kernel.

After these issues were fixed, I had an usable phone whose form factor was pretty amusing compared to my classmates' 18:9 Xoxomi sm8250 monsters, yet I still had the high ground speakers-wise.

The what OS

One day, through the Moto G's XDA section, I stumbled upon a post about a SailfishOS port.

I knew about SailfishOS already and that it used the same Hybris (or Halium) magic that UBports uses to get a full GNU/Linux OS running on these Android phones, but I have never experienced that “magic” beforehand (the Nexus 5X with Plasma Mobile should not count, being an awfully incomplete experience).

Out of pure curiosity, I decided to try it out; resulting in reverting my cool and updated vendor, kernel and system to CM12.1 for satisfying the Sailfish port... not cool, even though I just wanted to give it a shot (also I still hope that Michał can get it to hybris-14.1).

I really enjoyed the Sailish UI and its performance, although there were very few apps around that were useful (or usable) day-to-day; the lack of Android app support only exacerbated the situation as I did not buy a SFOS X license from Jolla.

I used SFOS with 2 or 3 apps on it for a month or more until I snapped, leading me to head back to Android 10 until I got my new phone.

Generous destiny

My new phone, the Sony Xperia 5, was a tactical choice: an amazing 21:9 display (which felt awkward initially but got to love in 2 days), awesome speakers, fancy cameras, a beast of a sm8150 and, of course, Sony Open Devices support that was not yet available for the 5 II at the time, making me settle for this one.

Getting a Sony of this caliber meant getting involved with their Open Devices program, as high-end devices do not get the same amount of love as the cheaper (or older) ones. The scope of this all was to bringup SailfishOS, although I was very skeptical of doing so at the time, especially due to the (then extremely old) Ubuntu 14.04 chroot required for building the OS; this lead to the port of the latest LineageOS to escape from the stock ROM's Google hell, making it, indeed, a breath of fresh air.

Build and... Build, until it's done

Time passes by and almost a year later, I actually determine myself to port SFOS, but problems arose almost immediately: while cloning the HADK bits onto my separate NVMe drive (being on a laptop with 500G+500G setup), I realized there was not enough space to compile the OS as a HADK-syspart is required; essentially being another clone of Android's sources for mounting /system and /vendor, which are both packaged on the system. As a bonus, me having /home onto another drive meant that sharing things between /srv/mer and ~/hadk was an absolute kidney stone to deal with.

After several days of recompiling and rebuilding the rootfs over and over because building SFOS is not straightforward nor portable, the different, freshly formatted with Ubuntu AMD Zen machine finally finished baking a flashable image.

Of course, the first boot was an absolute failure and was stuck at the SFOS logo for several minutes, only for the screen to then turn black; it turned out that my /system and /vendor were empty.

After fixing that by modifying hadk-syspart and rebuilding yet again, it finally booted and got to the tutorial: I knew that the port worked now (except a few things like vibration, notifications and the fingerprint sensor that would be fixed later on) and I could finally try the latest and greatest SailfishOS.

Coincidentally, a few days later I heard about Waydroid, seemingly an enhanced Anbox so that OS like UBports and Sailfish could spawn an Android container to use its apps without much of a hassle. Several days of troubleshooting passed by to get it working, leading to this commit.

Precarious... apps and whatnot

One of the first things I usually do when installing a new OS is configuring my Nextcloud account to sync contacts, files, notes, tasks and so on. I knew Sailfish has added Nextcloud support not so recently and was eager to try it out: of course, it lacked support for Nextcloud's 2FA authentication thus requiring a one time access key to login.

I really thought Bob's my uncle then, but no way in hell life was going to be that easy.

There is no built-in way for me to sync my files, tasks, nor notes which I thought would go into the Notes app: people on the forums complained that built-in backups were broken too, but I had yet to see it fail.

This lead me to go on a hunt through Openrepos and Chum for Nextcloud-syncing apps: the Nextcloud Notes app wanted me to register with my Nextcloud account (again) and then stored the credentials unencrypted on the device, but it was my only option to sync the notes.

For my tasks, there is an app just called “Tasks” that, yet another time, asked me to register, but at least this one stored credentials with sailfish-secrets; the app was abandoned by the author due to certainly understandable “uncertainty about SailfishOS's future”.

The obvious question to put out there: why was the Sailfish Accounts API blocked from Harbour (and left without documentation) until 4.5.0, leaving developers with practically no goddamn API for accessing the accounts registered within the system settings? It is patently stupid to login a thousand times on your account, across different apps with different mechanisms to store credentials, merely to keep things in sync.

As for the files, only two choices were left on my table: ghostcloud, which seemed like an abandoned app and was forked only to be rebuilt for aarch64, and sailsync owncloud, which also seemed pretty dead but at least it offered an official aarch64 package; that alone made it my choice in this case. I had to manually add a folder from my Nextcloud to the corresponding path locally, something I found to be perplexing for people like me who store hundreds of folders. I went ahead and continued using this, but it remains a certainly clunky way to sync (and find) files.

For my IMs of choice, I had to (obviously) download a Matrix and XMPP client to use: Sailtrix started to become acceptable only after many months of usage (was borderline unusable until 1.3.5), but I still need to manually accept giving it access to my “secrets” every time it is opened. After setting it up, though, I had a really bad time figuring out why my messages were not appearing in order by date, with “unverified MegOLM session” and “possible replay attack” replacing every single message in my encrypted conversations. All my glaring issues with encryption would magically disappear with the “Clear cache” button. Like a cherry on top, chat history did not function and downloaded files did not even appear on the system at all.

As for XMPP, Schmoose had no OMEMO support in its OpenRepos version (yet) so in order to get it, I had to go to their GitHub release page and install some early beta which lacked a variety of essential features, for example a menu to view, accept or discard OMEMO fingerprints; this app also stores credentials unencrypted and mandates the press of the login button every time you open the app.

“Privacy” and (in)security

Do you (or would like to) use a custom DoH or DoT DNS? Luckily for you (/s), this is not supported in SFOS and the OpenRepos-packaged dnscrypt-proxy is broken and does not ship any systemd service; you can work around this by installing the program manually from GitHub.

Tor browser user? You might be satisfied by Waydroid, otherwise enjoy an extremely outdated, Gecko-based browser pre-installed by default. In case you have wondered: no, you cannot run the Linux version of Tor Browser because QtWayland is so old (Qt 5.6) that it is unable to load 98% of the Linux programs out there. XMPP or Matrix calls? Again, Waydroid.

I was beginning to get fed up with the general sentiment about SFOS: why is it getting all this praise after all? Why is everybody seemingly ignoring the precarious apps situation and just buying Jolla licenses for Android App Support, to use this OS as (like someone on the forums put it) “a fancy GUI launcher”? Why is there almost zero mention of its outdated components and proprietary parts?

Yes, SailfishOS packs proprietary apps and components that were promised to be FOSS, but even after a decade, very little was delivered and less is to come. The outdated components situation, like them shipping an incomplete hybrid between Qt 5.4 and 5.6 because “they are scared of licensing issues” is a problem Jolla dug itself into; a problem they could have avoided completely if everything was open source from the start.

One particular example that struck me, demonstrating the consequences of SFOS' licensing strategy, can be found on the forums, where a developer is hitting a serious Qt bug that breaks their app, so they have to pretty much rewrite the patches from upstream Qt for the bugfixes to be backported on Jolla's Qt fork; the bug was small, but way bigger and more numerous ones would make this dangerously unsustainable.

I do not think that app developers should find adjusting their workflow hard between an updated Qt6 toolkit and Qt 5.6 plus Silica (which is fairly documented), but on top of this outdated, relatively feature lacking Qt base, Harbour is also very strict in the set of libraries that can be used, effectively knee-capping app developers. Many left the platform exactly because of this: unmaintained promises and increasingly outdated software on the platform.

On a more technical side, SFOS also suffers of these issues:

For the Android base and kernel side, let me explain how it works: Sailfish X (product of Jolla) bases itself on the Sony Open Devices Project, which every now and then updates its kernels (e.g. from 4.14 to 4.19, thanks to its contributors) and keeps the device's proprietary blobs updated, so that you are able to build and install newer Android versions than the stock, provided by Sony one.

The 2016 Xperia X, released with Android 6 can be updated up to Android 9, which brings a kernel bump from 3.10 to 4.4 (which went EOL in early 2022).

Jolla is unwilling to get off the SODP Android 6.0 base with the old 3.10 kernel, meaning that people are left vulnerable to some Android 6.0 vulnerabilities which can be found in HALs, some components that are consumed by hybris, device blobs and especially the kernel, which has accumulated a nice amount of CVEs ever since the 3.10 branch of Sony's kernel was last updated.

As for the essential but proprietary features, as an example, the fingerprint scanner functionality is a very simplistic “bridge” between Sony's FOSS fingerprint HAL running in the Android space and the SFOS userland, yet the package to enable such feature is kept proprietary and is distributed through a repository named hw-common; a replacement FOSS package exists but is Android-base specific, meaning it has to be built locally.

While fingerprints are a convenient but unessential feature, VoLTE support is nowadays becoming indispensable and must also suffer such faith: not only is most of the lifting happening in the Android space through blobs, but a required package has not been made available on hw-common for porters and is thus heading the OS backwards overall with regards to open sourcing.

While I do compile my own LOS with microG and patch the OS to increase its privacy, putting it light years ahead of SFOS, I am aware that not everybody has access to the 7 yottabytes of disk space and RAM required to compile Android. In that case, you could just install CalyxOS (or even GrapheneOS) and enjoy a lean, fast and quite worry-free Android experience. If you do not own a supported device for either OS, you could try porting either yourself to other devices as it is AOSP after all, but that would require you to compile it. GSIs also exist for the LOS route.

“Community” project

Like with every Linux project out there, users of such products will continuously attempt to push a “community-centered” ideology, even when potential contributors are barred from accessing certain source code and users might not have many choices or even be heard. A good, healthy community obviously helps immensely with the spread and usage of an OS (or distro), but that does not always apply.

To start, the SailfishOS forum users seems to suffer from the Moronix intellection (article coming someday), already setting the bar very low for any community. Such environments are usually toxic, filled with ignorance and get political exponentially fast, losing technical substance in the way and gatekeeping potential contributors.

As for the developers centered around SFOS, I can say that they have been so far respectful, educated, helpful and enjoyable people to chat with on IRC channels or whatnot. Some might not look like this and be exaggeratedly vocal (ahem, in the “other” fanclub), but they are the adjectives mentioned above.

Le conclusion

Before you draw any negative conclusions, keep this quote in mind:

You always hurt the one you love

I would absolutely love to carry a GNU/Linux machine in my pocket and just use it as a regular, actually FOSS, phone.

But this? This is just deceptive marketing and I have no idea how the SFOS userbase is seemingly enjoying being stepped on by Jolla.

Most people on the forum seem to forget that Jolla is a company (even Sami in their 2021 “Sailing for 10 years” talk refers to the OS as “the asset”): them selling their OS to authoritarian governments, like the Russian one, is simple business, until the EU sanctions backfired in early 2022.

As much as SFOS users scornfully vilify Android and iOS, you cannot deny that they are light years ahead in terms of performance, privacy and even security: Jolla being a “small company” has very little to do with the artificial roadblocks they have put in place.

As for me, at the time you are reading this post, I have either decided to keep SailfishOS and kind of explore the (accessible) codebase and maybe did a few contributions to both apps and system or just lost my patience and got back to Android.

Thanks for sticking along.

P.S. Thaodan made the initial port for the Sony kumano platform, I just added the support for the Xperia 5 based off of the existing configuration and upgraded the Android base.