Open source phones............
Jonni Bidwell urges you to flee the Apple-Google duopoly and make your smartphone a more wholesome place…
Is the dream of an open source phone OS dead? No way – we look at the contenders.
There are some two billion phones out there running Linux right now in the form of Google’s Android. But an aging Linux kernel buried beneath several layers of Java and a proprietary app store does not a free mobile utopia make.
The demise of Ubuntu Phone, not to mention other mobile efforts falling by the wayside, was a blow for hopes of a more open mobile platform – but hope is not lost. The UBports community aims to breathe life back into Ubuntu Touch, and has already shipped its first update. Many other projects are alive and well at the hardware level, and at various levels in the software stack. Android has been around for long enough that people are used to it and its app ecosystem, so compatibility is an important consideration for alternative mobile OSes. To that end, libhybris (a compatibility layer between the GNU C Library and Android’s Bionic) allows glibc- based systems to interface with hardware for which only Android blobs exist.
The Halium Project, which aims to reduce fragmentation by unifying the lower layers and standardising the middle layers of the mobile Linux stack, is also gaining traction, making it much easier to develop Linux-based mobile OSes without having to worry about the plumbing underneath. Vulnerabilities such as the recently publicised broadpwn, which may or may not affect up to one billion devices, generate headlines and panic, but in many cases users are powerless to apply protections. So whether you want an entirely open device (good luck with this) or just the ability to receive OS updates without being at the behest your network provider, read on and make your phone free(er).
“The UBports community aims to breathe life back into Ubuntu Touch”
“There’s plenty of blame being thrown around, and no-one is guiltless”
It’s easy to see the stark differences between the pure Linux world and the sullied waters of the Android ecosystem. Linux users, at least those using modern distros, are used to receiving timely security updates – which may even be automatically installed, depending on the user’s configuration. By comparison, about half of Android devices in use at the end of 2016 hadn’t seen a single security update for at least a year, according to Android’s own Security Team.
This isn’t entirely Google’s fault: they release monthly security updates, but those updates are only pushed to Google’s own Nexus and Pixel devices. It’s up to device manufacturers to adapt the updates for their own hardware, and then up to network carriers to push them to users. Most OEMs have little interest in supporting something they’ve already sold you, and network carriers don’t really want to update the horrible apps they so eagerly added to Android to “improve the user experience”.
In some cases there are other obstacles, such as last year where it emerged that Qualcomm stopped supporting its Snapdragon 800/801 chipsets, putting the kibosh to any hopes of devices using its silicon receiving an official Android 7.0 Nougat update. Again, apportioning blame is not easy here: Qualcomm claimed that the OEMs no longer want to support handsets using this silicon, so why should it bear the burden? Yet at the time of the announcement (August 2016) some of the devices using these chips, such as the popular Sony Xperia Z3, had only released in late 2014. Even in today’s throwaway culture, a two-year lifecycle for a phone seems rather short. For its part, Sony claimed that the chipset would not pass Google’s compatibility tests, which now require OpenGL ES 3.0 and Vulkan support. One thing is clear: there’s plenty of blame being thrown around, and probably no-one involved is guiltless.
Google is at least trying to ameliorate the update situation. Project Treble, part of the next edition of Android, aims to decouple the vendorimplemented parts of the OS from the rest of it. By standardising the vendor interface, it no longer matters if silicon vendors can’t be bothered to update their code to fit the new Android framework: it will still jive perfectly well with the previous interface. Obviously this does nothing for devices that have already been abandoned, but it does mean that devices supporting the next Android ‘O’ (‘ Orrible?–Ed) iteration should not see their support unexpectedly curtailed.
Users wanting can escape this synthetic-orotherwise obsolescence may be able to do so by installing LineageOS, which you can read more about on page 80. Other Android-based custom ROMs are available too, including the security-enhanced CopperheadOS and Replicant. The ability to install third-party ROMs depends on your phone’s bootloader being unlockable. Some manufacturers forbid this (although this trend is in decline); while others (like Motorola and HTC) provide a nice web form in which IMEI numbers or other tokens can be exchanged for unlock codes, which in turn can be used with fastboot , part of the Android SDK. Nexus devices can be unlocked without a code.
Failed phone OSes
Numerous attempts to make a more open phone OS have failed to come to fruition:
Firefox OS, Maemo, MeeGo and Ubuntu Touch are no more. But at least the latter two have been rescued by the community, in the form of UBports (see later) and Mer http://merproject.org.
Mer (short for Maemo Reconstructed), was originally an open version of MeeGo’s proginator, but development ceased as MeeGo gained momentum. Some developers were unhappy with the direction MeeGo was taking, and in 2011 some developers resumed silent development of the project. When Tizen was announced (and MeeGo cancelled) in 2013, the Mer Project went public. The mission is to provide middleware (rather than a complete OS) that sits between the Linux kernel and a graphical user interface. Thus manufacturers can configure the hardware side of things, choose a GUI (there are many active projects to choose from) and not have to worry about the rest. It is used in Nemo Mobile, the community continuation of MeeGo. Mer encompasses well-known Linux technologies such as Wayland, systemd and libhybris.
“Hybris is a solution that commits hybris, by allowing us to use bionic-based [hardware] adaptations in glibc systems,” says the Hybris (aka libhybris) GitHub page, and we can’t come up with a better description. Bionic is the Google- developed, BSD-licensed C library used by Android; and as such, many drivers there can only be accessed by Bionic function calls. Libhybris can overwrite these calls with glibc (the GNU C library) ones, so that they can be used with pure Linux systems. Bionic’s BSD licensing allows for the development of the proprietary tools in the Android ecosystem that so irk FOSS purists.
The wider-scoped Project Halium aims to reduce fragmentation in Linux-based phone OSes by providing a common base, including a Linux kernel, the Android hardware abstraction layer (and drivers that are only available in binary form) and the aforementioned libhybris. This should be portable and easy to build new projects atop.
When the MeeGo project was canned, several Nokia employees left the company to join Finnish smartphone manufacturer Jolla. Jolla hoped to produce smartphones and tablets (they have since given up with the latter) as well as the independent Sailfish OS. Sailfish is a Linux/Mer affair, with Jolla contributing a proprietary UI, although alternatives are available. It ships as standard with the Jolla phone, available in developing countries, as well as the Jolla C, available only to developers via a community device
program. Sailfish OS has been licensed to other vendors, and in February it was announced that a Sailfish version if Sony’s mid-range Xperia X will be available to buy. Sailfish OS has also been unofficially ported to several other handsets, as well as ARM7-toting Raspberry Pis. Sailfish applications are built using Qt and C++, using the currently proprietary Silica QML module. A key selling point of SailfishOS is sfdroid, which enables Android apps to run on Sailfish.
Tizen troubles
The Tizen project aims to provide not just a mobile OS, but one for IoT and IVI (in-vehicle entertainment), wearables, TVs and more. It was originally governed by Samsung, Intel, Huawei and other industry giants (the collective formerly known as the LiMo Foundation), with development taking place under the aegis of the Linux Foundation. Today Samsung is the only company actively developing the OS and products based on it, but the Mer Project hopes to work alongside Samsung going forward. In April, security guru Amihai Neiderman discovered several critical vulnerabilities with the software, claiming that it may be “the worst code I’ve ever seen”. Tizen uses the oFono telephony stack used by other FOSS projects.
The KDE community also has aspirations in this area with its own Plasma Mobile OS https://plasma-mobile.org. It uses the Kirigami framework to make the UI lightweight and beautiful; check out the Kirigami Gallery app on Google Play if you don’t believe us. The OS itself is still in a development state and is not ready for prime time, but it can be installed on the Nexus 5/5X. These devices can also be used with MaruOS, which aims to rekindle the dream of convergence by shapeshifting from Android to Debian when an external display is plugged in.
Android’s open-source base (AOSP) has enabled the development of several custom ROMs, but many power users yearn for
something purer powering their phones. Eventually, their best option may be postmarketOS, but for now the project is in its infancy. Only eight devices are ‘supported’ (meaning at least USB networking and graphics output work) – and none of these are capable of making calls. It’s based on the diminutive Alpine Linux and aims to give phones a 10-year lifecycle.
UBports
Many an open-source aficionado was excited when the BQ Aquaris 4.5, the first Ubuntu phone, was launched in 2015. Yet more people were excited when the Aquaris M10 tablet followed a year later. All of those people, then, will have experienced some measure of disappointment when Ubuntu founder Mark Shuttleworth decreed that Ubuntu Touch, Unity 8 and all the associated hardware projects were to be wound up. No-one likes to hear that their unique, if a little quirky, devices are being abandoned.
But all is not lost. The UBports project ( https://ubports.com) was founded in 2015 by Marius Gripsgard, with the aim of bringing Ubuntu Touch to as many devices as possible. The community grew rapidly as developers and free software advocates, taken with the spirit of the project, joined the ranks. Pessimists would have thought with Canonical’s abandoning of its mobile efforts that UBports would cease to be, but in fact the opposite has happened. It has adopted the Ubuntu Touch codebase and intends to develop, maintain and otherwise keep it alive as long as there is interest in doing so. That interest, it seems, is plentiful.
In June 2017, UBports announced its first update, OTA-1, which is available for all the devices originally supported by Ubuntu Touch (the Aquaris phones and tablets, the Meizu phones and Google’s Nexus 4 and 7), as well as some devices which UBports supported before Canonical’s announcement (the Fairphone 2, Nexus 5, 7 and 10, and the OnePlus One). The Aquaris and Meizu phones are now classed as legacy devices, so these will see only security updates going forward. But this is a lot better than nothing.
LinuxFormat was fortunate enough to have an Aquaris 4.5 (codenamed Krillin in Ubuntu Phone parlance) lying around, so we thought we’d document our efforts getting OTA-1 on to it. According to the instructions on the website, it seemed like it should be an easy process. We have a choice of using Marius’ general-purpose Magic Device Tool (MDT, which acts as a wrapper for the hardware-specific programs) or using ubuntu-device-flash directly. In the second case, all that should’ve been required, if you were to believe the instructions at https://ubports.com/page/fs-flash-phone, was to boot our device into fastboot mode (hold the Power and Vol + buttons and select fastboot from the menu); download a recovery image; and copy and paste a lengthy command. However things are never simple – it’s not that the instructions are wrong, it’s just that they only work if your phone is running the original Ubuntu Touch OS.
If you happened to have gone and installed Android on your device, the partition layout is wrong and the recovery image won’t flash. In order to proceed it’s necessary to reflash the original OS (OTA-14 in our case), which you can get, along with the instructions ( enespañol) from http://www.mibqyyo.com/descargas/ categorias/aquaris-e4-5-ubuntu-edition/.
This process is not straightforward, since the SP phone flashing tool requires an old libpng12 , found with some judicious googling. Once that’s in place, we were able to proceed without hiccup and get OTA-14 installed, at which point we were able to follow UBports’ simple instructions and enjoy Stable OTA-1. While the list of new features in this release may appear quite modest (experimental AGPS support, a welcome app, and the new OpenStore app store), OTA-1 nonetheless marks a huge step for community-driven phone development, and owners of relevant hardware will no longer feel so abandoned.
The Ubuntu Touch interface itself remains unchanged – it still takes some getting used to, but it’s hard not to credit its innovative approach and short/long edge-swiping ingenuity. If you’re coming from an Android background, on the other hand, you’ll find yourself hopelessly prodding at the bottom of the screen in search of a non-existent button bar.
“OTA-1 marks a huge step for community-driven phone development”