HomeInstallBlogExploreTeamDonate

219 days of postmarketOS

December 31, 201718 min. read

Few Years Old Devices Should Not Be Electronic Waste

Most people around us have accepted that it is necessary to buy a new phone every other year. As a smartphone progresses through its own life cycle, manufacturer support for new features become rare, eventually stopping, and the device gets slower and slower. Even worse, after this period, the devices don't get security updates anymore. This means that in many cases the bored IT student next door is able to look up on the Internet how to turn your phone into a surveillance device. Unfortunately the only way to continue to receive security updates after this point is to purchase a new device. In lieu of any alternatives today, you really should purchase a new device to stay current with security updates.

We want to have another option: postmarketOS is a Linux distribution based on (lightning fast) Alpine that aims for a ten year life-cycle. Instead of having binaries and forked source code for every device, we unify them as much as possible. That allows us to provide updates for all devices at once. The project is still in an early stage (no, you still can't make calls with it.) But it would be a mistake to wait for phone call functionality without informing you about all the breakthroughs we have had. Read on for the exciting changes since day one hundred!

Weston Got Company

Plasma Mobile

Plasma Mobile running on the sony-castor-windy with freedreno

The Wayland reference compositor Weston was the first interface we had running on our devices. Good enough for a demo, but to get a real tablet/smartphone experience we always had an eye on KDE's Plasma Mobile project. After countless hours of hard work we are proud to finally present it running on real devices!

Running plasma on real devices with postmarketOS is brand new, which means it has not been tested much and it is far from a polished experience.

With that being said, it looks like it starts on most devices that can already run Weston but devices with hardware acceleration for graphics are much more usable at this point. The Z2 Tablet is one of the two devices booting postmarketOS and supporting hardware acceleration with the open user space driver freedreno. All other devices must use OpenGL emulation in software due to them requiring proprietary GL drivers. We do have various ideas on improving the situation, such as better software rendering or mainlining the devices and using FLOSS userspace drivers where possible.

The gif shows Plasma running on the Sony Xperia Z2 Tablet (click on it to see the full video). Below we show it on the Google Nexus 5, Samsung Galaxy S Advance, Sony Xperia Z1 Compact and again on the Z2 Tablet, but this time with @MartijnBraam's postmarketOS wallpaper straight from our new artwork repository.

Thanks to: @ata2001, @bshah, @drebrez, @MartijnBraam, @NotKit, @PureTryOut, @opendata26, @zhuowei

LuneOS UI

Historically LuneOS and its interface have their roots in webOS from late Palm devices. It was rewritten from scratch to use modern technologies, such as Wayland. The UI is based on the concept of cards for various apps, which can be swiped away to close them, and related cards can be grouped to stacks. That sounds familiar, right?

Much of the UI and default applications are actually implemented as HTML web applications, thus the name webOS.

During the porting we have learned that it is possible to run non-HTML applications as well, such as Wayland or even X applications.

@PureTryOut did the initial packaging while taking a short break from packaging Plasma a while back. Basic applications were packaged, but nothing ran yet. Then @magmastonealex picked it up and with a tremendous amount of work he managed to get it going in QEMU. Afterwards @zhuowei got a proof of concept on his Google Nexus 6P without hardware acceleration by using the Xzibit-method of running the LuneOS compositor inside of a running Weston compositor (this same trick also works with plasma by the way). @NotKit showed us the real deal with his Motorola Droid 4 followed by @magmastonealex Teclast X80 Pro (third and fourth photos below, both have hardware acceleration).

Since Plasma Mobile and LuneOS share similar technologies, they have similar porting problems - and it's good for development to be able to look at problems from different angles through both UI ports. Before we continue, we should mention that whole process from asking "hey how about packaging LuneOS UI" to running it within postmarketOS on a device took less than two months!

Thanks to: @magmastonealex, @NotKit, @PureTryOut, @zhuowei

Hildon, Gnome, MATE and XFCE4

You see where we're heading with this: we got all of these environments running on real devices. Hildon was updated by @NotKit to use sources from Maemo Leste, which continues development upstream. More applications have been packaged, notably hildon-home which allows launching apps by touching icons.

The other three desktops are already maintained upstream in Alpine, which means we can just install them with little or no modifications. @opendata26 made a proof of concept running Gnome 3 after applying a few hacks. There is a photo below with Gnome 3 on a Z2 Tablet running Firefox and watching a YouTube video. @drebrez is working on proper integration for MATE as you can see on the right.

Finally XFCE4 was pre-configured by @pavelmachek. In order to make it usable on his Nokia N900, he also contributed the unicsy_demo package, which reads various sensors and is able to send and receive SMS on his device after some manual preparation. @drebrez packaged the matchbox-keyboard to be used on interfaces lacking their own on screen keyboard. We can happily confirm that XFCE4 and MATE work well even without hardware accelerated graphics!

Thanks to: @drebrez, @NotKit, @opendata26, @pavelmachek

Libre Drivers and Libhybris

In contrary to most Linux on smartphone projects, almost all these photos and the video are taken off devices which do not run proprietary code on the main CPU. The only exception is the Droid 4, which @NotKit owns. He is actively working on making proprietary Android drivers usable in postmarketOS with libhybris. Libhybris allows devices lacking FLOSS drivers to make full use of their hardware.

While we don't welcome binary blobs and prefer to sandbox them where we ship them at all, we embrace this solution for people who want it. However we intend to keep closed source components entirely optional, so you can run pmOS as libre as you want it.

Thanks to: @NotKit

Mainline Linux Kernel

Android Based Devices

It's always a super exciting time for #postmarketOS when someone posts the first photo of their smartphone running on a mainline kernel, oftentimes with a distorted screen. Enjoy such pictures of the Google Nexus 5 (@bshah) and Fairphone 2 (@z3ntu) below. The Sony Xperia Z1 Compact (@ata2001) boots a mainline kernel as well, however the screen does not work yet.

Together with the Google Nexus 7 (2013), Teclast X80 Pro and the Xperia Z2 Tablet — where @opendata26 fixed a mmc regression introduced with newer kernels — we now have six Android-based devices packaged with partial mainline support. We are still at the beginning of unifying them into one linux-postmarketos-stable package, but it's a huge step in the right direction!

While this blog post was in the making, @fourkbomb showed us even more mainlining progress. This work is not packaged for postmarketOS yet, and he used kexec to boot from the original kernel forks to the mainline kernel. Nevertheless, the results are impressive! On the right is the Samsung Galaxy SIII LTE (i9305) running mainline (as you can see in the terminal when clicking on it). As if that wasn't cool enough he made it work on similar Samsungs (i9300, n7100, n7105) as well!

Thanks to: @ata2001, @bshah, @fourkbomb, @magmastonealex, @montvid, @opendata26, @z3ntu

Nokia N9xx Devices

Camera support for the N900 was merged by @pavelmachek. There's still a lot of work to do in kernel and user space, but the classic N900's hardware support is getting better. The only major areas not supported are Bluetooth and 3D acceleration.

Nokia N9 packaging for postmarketOS with the mainline kernel is ongoing now that @filippz made it work (photo on the right shows the N9 during earlier porting stages). @sre has done a lot of work on display support for TI OMAP, and this work is slowly being merged into the mainline kernel. Support for battery status on N9 and N950 should be ready in kernel v4.15. In addition, light sensor drivers are now working. While this is amazing progress, a lot more work still needs to be done for these devices. For instance battery charging, a staple feature for smartphones, is currently not working yet.

Thanks to: @filippz, @pavelmachek, @sre

New Devices

Despite not being a smartphone or tablet, this next device is still right at home in this section: @dee-gomma managed to run and demonstrate basic functionality of pmbootstrap on a 32 bit "postmarket PC", check out his instructions if you still own such an old computer and feel adventurous.

But what you are really looking for are the new supported devices running postmarketOS, right? Most people expect a certain level of functionality on supported devices, and almost all expect that a supported device can be used as daily driver. As a result, this section has historically started off with a disclaimer that our definition of "supported" essentially means that the devices will successfully boot postmarketOS. This time, however, we have decided to abandon the term "supported" altogether in order to help minimize confusion. Here are twenty-five new devices, on which postmarketOS boots. Click on them for detailed information about what works and what does not.

The best way to get an overview of all devices at once is the devices page on the wiki. As of today, for example, it shows that we have 18 devices with working Wi-Fi.

Thanks to: @ata2001 @dakk @dee-gomma @drebrez @flacks @Halamix2 @kaendfinger @kamnxt @kskarthik @lawl @limiter121 @magmastonealex @montvid @MoreRobustThanYou @rendeko @rrooij @shwsh @tyxieblub @WilliamO7 @z3ntu @zhenyolka @zhuowei and everyone who helped them out!

All New 'pmbootstrap init'

When you get started with postmarketOS development, the first thing you do is clone the pmbootstrap git repository. This provides you with a small Python script that runs on just about every Linux distribution because of Python's portability and the script's single dependency on openssl. With it, you will have a great deal of tasks automated and streamlined, so you can focus on actual development instead of spending hours on setting up your development environment.

$ git clone https://github.com/postmarketOS/pmbootstrap
$ cd pmbootstrap
$ ./pmbootstrap.py init
Target device (either an existing one, or a new one for porting).
Available (39): amazon-thor, asus-flo, asus-grouper, ...
Device [samsung-i9100]:

The init action is what you run directly after cloning the source and whenever you want to change your configuration. Besides the devices we already have, it is also possible to type in a new device name now. In the "new device name" mode the script is eager to learn about your new device: Who produced the device? Does it have an SD card slot or a hardware keyboard? Which CPU architecture and bootloader does it have? Oh fastboot you say - why don't you give me an existing boot.img file from a known working Android ROM while we're at it, so we can extract the flashing offsets?

Once this information is gathered, it presents you with an automatically generated kernel-package and device-package. We get new devices running with their original kernel first, before we try to run the mainline kernel on them. Besides that, new questions were added for the interface: timezone (e.g. Your host timezone is Europe/London, use that?), username and custom default packages (e.g. how about vim, gdb, strace?). Build options rarely need to be changed, so they were grouped together to make it easy to skip them.

https://wiki.postmarketos.org/wiki/Porting_to_a_new_device

After init is through, you are just one command away from cross-compiling packages or building a full installation image. We have whole new porting and installation guides that walk you through the process step by step.

Thanks to: @craftyguy, @drebrez, @ollieparanoid

Binary Repository

In order to change something in Android's system code, you need to download its entire source code of 100 GB, then do your change and build everything, which takes another 150 GB of storage, as well as 16 GB of RAM (or SWAP) and lots of time even on the strongest computers (numbers from here, 2017-12). Subsequent builds are faster, but still you have this initial build which seemingly takes forever.

postmarketOS doesn't use Android's build system, but divides all of its software in packages just like a regular Linux distribution. As mentioned previously we directly use Alpine's repository for many packages in postmarketOS - but today we also have a binary repository for our own packages (with interfaces like Plasma Mobile, kernel packages, etc)! While it still has a few rough edges it gets the job done: Now you only need to compile the packages that you want to change. Even if your computer takes hours just to build the Linux kernel it is still feasible to use it for postmarketOS development. All compiler output is cached with ccache, so subsequent builds are a lot faster as well.

This also means that it is possible to update your postmarketOS installation running on your device now.

Keep in mind that we have not reached the point yet where we can verify each update on the device migrates properly from the previous version, so you will probably have some breakage sooner or later. Kernel updates should work as well, thanks to the kernel update script @ata2001 wrote - but right now you will need to invoke it manually.

Thanks to: @ata2001, @ollieparanoid

Continuous Integration

pmbootstrap has had test cases since the day it was released. We hooked Travis and Coveralls up with that testsuite to automatically run it for each new pull request. And we steadily increased the coverage from 51% to 64%. The list of shell scripts we automatically verify with shellcheck has grown again.

As we learned about kernel config options that should or should not be enabled to work properly with Linux on smartphones, we created the pmbootstrap kconfig_check action to automatically check the configs. This runs whenever you change the kernel config with pmbootstrap menuconfig, and it runs on Travis as well.

Thanks to: @ata2001, @drebrez, @MartijnBraam, @ollieparanoid

Other New Features

Running postmarketOS in a QEMU VM, with pmbootstrap qemu, will now use 3D acceleration by default. In addition, QEMU image files can now be resized on the fly by using the new --image-size parameter. These changes continue to make QEMU an invaluable resource for developers packaging and testing new software in the postmarketOS/Alpine Linux environment.

Regarding encryption, it is possible to use encrypted swap files now. Furthermore the touch screen keyboard for full disk encryption (osk-sdl) we introduced last time became the default now, and has helped to make full disk encryption a great deal more practical. You just don't need to fire up a USB telnet session anymore to unlock your phone each time you reboot it. But for initramfs debug, you can still install a hook that gives you a debug shell - and it displays a nice splash screen until you tell it to continue booting.

Thanks to: @BrianOtto, @craftyguy, @drebrez

Various Refactoring

@drebrez made it possible to share code between the device specific package recipes with devicepkg-dev. The package building code in pmbootstrap was rewritten by @ollieparanoid to make it easier to extend and to do build-time dependency installation just like Alpine's abuild for improved compatibility.

@ata2001 refactored the Android recovery zip installer to have close to zero dependencies on the recovery system used, which makes it possible to work not only in (exotic versions of) TWRP, but also in CWM and probably every other Android recovery system. He also extended it to support devices that need the heimdall-isorec flash method.

Thanks to: @ata2001, @drebrez, @ollieparanoid

Raw Numbers

Environment

We would like to thank all projects that collaborate with us, and talk about some of their news which is relevant for us as well.

Alpine Linux 3.7 was released with thousands of git commits of hard work. While postmarketOS is still based on their rolling release edge branch, the idea is that we also base our work on the stable channels at some point in the future. @awilfox from the upcoming Adélie Linux assured that they will be upstreaming and maintaining the LTS version of KDE Plasma in Alpine. As soon as it's upstreamed we can base our Plasma Mobile packaging directly on the KDE Framework in Alpine, and when Plasma Mobile works with the LTS version of the Plasma Framework at some point in the future we can build on top of that as well! Several contributors to postmarketOS have also directly contributed to the Alpine Linux 3.7 release and, while not nearly as impactful as the official Alpine Linux developers, we are still very much committed to helping out our Alpine friends where ever we can!

The Plasma Mobile team recently detailed their roadmap in a recent blog post. And they got a lot of interest with the successfully funded Librem 5 phone, which will either use Plasma or Gnome 3. We think the Librem 5 is great for all Linux smartphone projects out there.

The somewhat mobile friendly matrix client nheko just had its 0.1.0 release, and while we have not finished packaging it yet, author @mujx confirmed that he had an earlier version working on postmarketOS in QEMU.

tslib powers the touch screen functionality in our initramfs. Shout out to @merge from the project, who was incredibly helpful with answering questions, making it work on Android devices and by patching tslib, the touch driver for the N900 in the kernel, and even implementing automatic touch screen detection! To show our appreciation we solicited help for responding to a tslib request for a vectorized logo in #postmarketOS, and only a day later @rrcha took care of it.

If you're into smartwatches and want to use an open source OS on them today, check out AsteroidOS. @FlorianRevest tagged a version of its msm-fb-refresher component, so were able to package it properly to refresh the framebuffer in postmarketOS for devices that need it.

Thanks to everyone working on these projects!

How Can You Help?

You read through the entire thing, didn't you? Looks like you have some interest in this project - and we can use every helping hand. We've put the more technical tasks at the bottom of each list. pmbootstrap is written in Python, packaging tasks require shell scripting knowledge.

Tasks that do not require a device running postmarketOS:

Tasks that do require a mobile device for development:

Closing Words

What a crazy half year of development we have behind us. Who would have thought that this project would have taken off this much? That such a big community would have emerged out of nowhere? This is the work of every single contributor, we can all be proud of what we have achieved and we have lots of potential for the future. Thanks for reading, and now go party hard on new years eve!

Bonus: install_if

No fancy pictures here, just a little code snippet and possibly boring implementation details. We've moved this one to the bottom because the post has gotten really long again.

In some cases, device specific config files are needed for programs, such as X11 or Weston. Now we could always bundle these configs with the device package, regardless of the program in question being installed or not. But then again we would clutter up the filesystem with useless files, which isn't nice. Thankfully Alpine developer @kaniini pointed us at Alpine's excellent install_if feature, which allows us to automatically install the config if both the program and the device package are installed. We refactored the device packages accordingly.

weston() {
    install_if="$pkgname weston"
    install -Dm644 "$srcdir"/weston.ini \
        "$subpkgdir"/etc/xdg/weston/weston.ini
}

Thanks to: @craftyguy, @kaniini, @MartijnBraam, @ollieparanoid, @PureTryOut, @Wouter92

Comments