PostMarketOS Saves Old Smartphones

Modern smartphones, even the budget models, are extremely impressive pieces of technology. Powerful ARM processors, plenty of RAM, and an incredible number of sensors and radios are packed into a device that in some cases are literally given away for free when you sign up for a service plan. Unfortunately manufacturers are not obligated to keep up with software updates, and while the hardware may be willing to keep on fighting, the user is often pushed to upgrade due to perennially outdated software. Even if you aren’t the kind of person to be put off by using a phone that doesn’t have the latest and greatest OS, the lack of software security updates pose a clear threat in a world where mobile devices are increasingly targeted by attackers.

But what if the operating system on your phone worked more like the on one your computer? That’s the dream of postmarketOS, a Linux distribution created by [Oliver Smith] that is designed to be installed on outdated (mostly Android) smartphones and tablets. He’s recently made a comprehensive blog post about the state of the project a little over 6 months since it started, and we have to say things are looking very impressive so far.

One of the key goals of postmarketOS is to avoid the fragmented nature of previous attempts at replacing Android with a community-developed operated system. By avoiding binary blobs and focusing on getting the mainline Linux kernel running on as much as the hardware as possible, there’s no need to make different forks and releases for each supported device. By unifying the OS as much as far as it can be, an upstream update can be pushed to all devices running postmarketOS regardless of their make and model, just like with traditional Linux distributions.

The blog post shows two things very clearly: that the community is extremely excited and dedicated to the prospect of running what is essentially desktop Linux on old smartphones and tablets, and that postmarketOS still has a long way to go. In these early days, many devices aren’t what could be considered “daily drivers” by most standards. In fact, the blog post mentions that they’ve decided to abandon the term “supported” when talking about devices, and make no claims beyond the fact that they will boot.

Still, incredible progress is being made on everything from mainline kernel development to getting standard Linux desktops such as Gnome, MATE and XFCE4 running. Work has also been done on the backend process of compiling and packaging up components of the operating system itself, promising to speed up development times even for those who don’t have a beefy machine they can dedicate to compiling. The blog post ends with a helpful list of things the reader can do to help support postmarketOS, ranging from making your own t-shirts to porting to new hardware.

At Hackaday we’ve seen our fair share of hackers and makers re-purposing old smartphones and tablets, keeping them out of the landfills they would almost certainly end up in otherwise. A project that aims to make it even easier to hack these cheap and incredibly useful devices is music to our ears.

67 thoughts on “PostMarketOS Saves Old Smartphones

  1. ” In fact, the blog post mentions that they’ve decided to abandon the term “supported” when talking about devices, and make no claims beyond the fact that they will boot.”

    Downside of smartphones. All the undocumented hardware.

      1. Mostly but not only. You’d be surprised how many proprietary blobs are in phones and how many of those are purposely obfuscated. Sometimes it’s not just about getting hardware “work” but getting the more advanced functions out of them (HDR out of cameras, casting screen, that sort of stuff)

  2. I for one, welcome our new hacker overlords!

    But, alas and alack, I feel overwhelmed at the prospect of this venture “succeeding” on a broad scale.
    So many phones were bricked by people attempting to make even a “small” change to its firmware/software.
    My Swampscum Galaxy S4? is becoming obsolete BECAUSE of the “upgrades” it recieves, they make old apps unusable while offering “new” apps to replace them that require more permissions and more memory.

    As [Ostracus] mentioned above about the lack of documentation, it is going to be a steep uphill battle…
    …I think.

    1. I really like Samsung’s hardware, but agree that their code is a loser.

      I run Cyanogen on an S2, S3, and S4, the last of which is my daily driver (and the other two do things around the house). If you don’t include the Google blobs and install apps using F-droid, you have a fully open-source phone.

      Still, the Cyanogen/Android versions are very much hardware dependent, and compiling for every possible phone became a burden and it’s discontinued now, sadly. That’s where this project shines.

      I’ve never bricked a phone. If you’re doing “normal” stuff like installing a tested alternative OS, I think the chances are minimal. Has anyone here actually bricked a cell phone? What were you doing?

      1. ive bricked a mytouch 3g flashing radio and spl from a slightly differnet variant of the phone in the wrong order. also bricked a kyrocera rise by stupidly flashing both boot and recovery knowing neither would work since the bootloader does some kind of sigcheck.

        so nothing a “normal” user would do

      2. I was one of the Cyanogenmod maintainers of the AT&T S2, and worked closely with the international S2 maintainers (the differences between the two devices were minimal). (I’m retired from Android hacking now, and was one of the Cyanogenmod maintainers that left to form Omni after the Focal relicensing fiasco – along with pretty much every active Samsung Exynos ex-maintainer, aka the former Teamhacksung.)

        Samsung’s code was horrible – we routinely found boneheaded workarounds for Samsung bugs where they hacked the frameworks to work around a HAL bug instead of just fixing the damn sensor HAL (on those older devices, sensor HALs were simple, eventually the S2 family moved to a fully open source sensor HAL. That became nearly impossible on newer Qualcomm devices with the proprietary sensor fusion engine.) The Exynos platform reference source was full of typos and clearly was way behind what was being given to Samsung Mobile. Development boards are supposed to be AHEAD of shipping products, not way behind!

        In the case of this project – good luck with the RIL. Almost no phone had a functional open-source RIL (radio interface layer) for talking to the cellular system.

        As to bricking devices – pretty easy on the S2 for a while due to Samsung’s buggy eMMC. It wasn’t fully compliant with the eMMC spec and was prone to, in a small percentage of situations, permanently sending the wear leveler out to lunch to the point where not even JTAG houses could fix it if you sent it a secure erase command. Samsung told me, to my face, it was unrecoverable more than 50% of the time in a lab environment and refused to work with developers to come up with a USB-boot repair tool such as Adam Outler’s Unbrickable for previous Exynos CPUs. A year later someone found a leaked eMMC datasheet including documentation for commands that would likely fix the wear leveler – that info was used to repair Superbricked first-gen Kindle Fires that had the same defective memory. (The original KF used a GP TI OMAP that didn’t support secure boot, as a result even a 100% bricked device could be booted from USB just by jumpering a test point.) The guy who did that reported a 100% success rate of users that used his recovery tool.

        Also, international S3s were known to brick themselves due to yet ANOTHER eMMC wear leveler bug… It was known back then as Sudden Death Syndrome. Samsung’s “fix” was to patch the eMMC such that the system would hang instead of bricking when the problem might occur – of course, this meant that people with affected phones had them hang/freeze on a regular basis!

        1. Hey, I’m the guy who came up with the KF USB boot, idsw exploit, and bootloader replacement!

          IIRC the eMMC issue was a bug in the integrated controller, not the OS. The eMMC controller supported (and advertised) the ERASE command, which is used when the kernel’s filesystem driver frees a block to mark the block for trimming. On the buggy eMMCs, there was a small chance that an ERASE would corrupt wear leveling metadata in a way that cause the controller to lock up when read back.

          Users didn’t see the bug on official ROMs since (at the time) only custom ROMs had kernels that made use of the ERASE command.

          Samsung eventually distributed a firmware update for the controller that caused ERASE to no-op.

          I do miss my S2 (i777). It was solid, had a replaceable battery, had an Exynos CPU, and was one of the only non-PenTile OLEDs available at the time.

      3. I bricked my old kindle 3 trying to read battery temp data directly. I broke the bash script (bash script!) that managed battery longevity and it refused to boot, it thought the battery was dead when it was at full charge, overvolting it. :-(
        I can blame it on poor design choices in its manufacture, not my own (lack of) skill.
        Yes. That’s totally it.

    2. Same here for my I9000. It is a shame because the hardware itself works great and it offers everything I could possibly need on a smartphone. I am running the latest CM build for my phone but the apps updates are killing it. I don’t update anymore.

    1. I only have looked some minutes at Android-x86 and never touched other Android stuff, so I expect I’m not the one to get started with that topic by converting an old phone myself.

      When PostMarketOS turns out to be the OpenWrt/LEDE of the Android universe, I definitely want to get my hands on that.

      1. Dear Hackaday… I need an EDIT button… PLEAAAAASE!

        …or a posting ban before having got enough caffeine.

        [Editor’s note: Got your back. But for edits, we’d need authenticated accounts: proofreading vs privacy. And for caffeine-dependent posting permissions, it gets slightly more invasive…]

      2. “When PostMarketOS turns out to be the OpenWrt/LEDE of the Android universe”


        I hate to disagree with you old chap, but it seems to me that two groups of cause fascists fighting over control of the project is probably not going to help the project achieve it’s aims.

          1. In my experience, the people who complain loudest about others doing things for free (or giving things away) are usually the worst offenders when it comes to respecting other people’s property rights.

          1. I’ll reserve judgment until we see how it actually works out, but I’m with [Jonathan] on this one. Two groups of jackasses fighting over control ain’t good.

  3. One of the big killers of old phones is the “locked to Telco provider” death. It is often not worth the money or the effort to try to unlock your old phone when you move to a new provider. If we had access to the hardware, right down to the bare metal, then unlocking of devices which would otherwise be heading via he bargain bins at ebay to one of the great trash piles in some dark polluted corner of our planet, becomes a possibility. If the devs of PostmarketOS can manage this trick, and also get a lot of the radios working, then this will be an impressive and worthwhile project.

    1. The radios will require device-specific drivers, and probably binary blobs at that, so I think it is unlikely for them to be supported (or at least well-supported) any time soon. Of course, if the radios don’t work they’re hardly going to be phones, but that does mean that being locked is a non-issue…

      1. Reverse engineering the binary blob then becomes the issue. This is not impossible of course, since it may be possible to man in the middle attack it if you can load the blob up in qemu or some other suitable emulator and examine what it actually does..
        Reverse engineering may be easier if the hardware that controls the radios can be determined. Obviously if you know that the radio hardware/SOC controller uses an 8051, arm or 65xx2 or other known processor derivative, then demystifying the blob can be a lot easier.

        1. Or Qualcomm Hexagon DSP chip with no public documentation of even the instruction set.
          Some Mediatek soc’s seem to have ADSP cores based on Analog Devices IP, but the ualso bought Coresonic AB.
          So an endless mess.

    2. My daughter gave me my ex-wife’s old S4 (time something went the other direction!), I just wiped it completely clean of all apps and use it was a camera, and internet over wifi. At some point I might use it for PSK-31 or something by building it right into an enclosure with a transceiver. At least older phones still have the headset port.

  4. I’m curious if it is possible to build distribution that actually use all these blobs from original firmware (to fully support hardware) but gives normal Linux userland on top of it instead of crappy android. I think this would be the most universal way to reuse old android hardware, even if leaving blobs would be some compromise on freedom of such system.

    1. The problem is, the Linux userland is different to the Android userland, and many of those blobs depend on the latter.

      It’s not actually that hard to install a Linux userland on an Android device, then access it via VNC.

      1. I know it’s different, I think about some API/ABI translation layer (some time ago I read about such thing for Bionic – Android C library, I don’t remember project name now). Installing Linux on top of Android, with VNC access is quite cumbersome, not very efficient and you still have all unnecessary Android things running in background.

        1. Mention is made in the article of “Libre Drivers and Libhybris” and “Libhybris allows devices lacking FLOSS drivers to make full use of their hardware.”.. so in theory, it will be possible to use binary blob drivers in this non Android environment. Running Android Apps on the other hand is not so simple. If you must run Android Apps, then LineageOS or some other replacement for your vendor specific rom would be the way to go.

          1. So….
            If I follow you correctly, you are writing about a wine* that will run Android apps on a Linux OS’ed phone?

            * not literally “wine”, but a similar idea.

          2. Right. For Android apps I’ve tried Anbox but never really got it running properly. One option I haven’t tried is ARChon, which is App Runtime for Chrome tweaked for Linux/Windows/Mac (instead of just Chrome OS)

    2. Android is a distribution of Linux and open source, Goggle Android is just a forked version you can opt out of! You can port any kind of Linux UI, but are left with having to “steal” the manufacturer specific non free hardware drivers in many cases.Further Phones apply some kind of white listing, so a hardware specific driver from one phone won’t always work on the same hardware in another with same processor and kernel!! Making an universal Android or Linux version that is truly open source is seriously astronomical in magnitude. Hardware drivers have to be either rewritten or leaked willingly from chip manufacturers, which are under non disclosure restraints I presume. This will take the effort of the combined Linux community to fly. The good news is that there is a convergence in PC hardware towards ARM, so as time passes more generic drivers from desktop ARM computers, will be usable on phones. While not entirely open source, the GNU way, Cyanogenmod is a rough compiler and development system that let you compile any Android Linux version you can dream up and you can include any ARM version of Linux software you desire. Hardware drivers are trial and error, so prepare yourself if not someone else have figured out a workable image or source list. This is not desktop Linux with an installer and phone specific repository, but if you need a phone running Linux for a specific purpose, it is most likely possible with Cyanogenmod.

      1. .. what he said.. but also .. “LineageOS is an Android distribution. In other words, you can call it a custom ROM. It was created after the much more successful Android distribution CyanogenMod was discontinued. LineageOS is a fork of CyanogenMod.”.. so if your phone is supported by LineageOS, then that would be the way forward since Cyanogenmod is defunct and therefore not being updated.

      2. “Android is a distribution of Linux and open source”.
        It’s neither, and by itself you can’t use it on any real hardware without adding closed blobs, which makes it a “non-operating-system”. Moreover, the whole Java VM dependency just makes it even more uninteresting. If hardware was documented, tons of e-waste which is being exported to third world to be recycled could be repurposed to accomplish different tasks: a 7 years old tablet paired with other peripherals could easily become an IoT controller, a webradio bedside clock, a logic analyzer, etc.

        1. Problem is, a 7-year-old tablet is about 2 years off from becoming e-waste anyhow because of the non-replaceable battery inside is going to puff up and kill the thing. There’s no sense in recycling what is designed for obsolescence.

          1. I already was imagining them repurposed as non portable devices, just like screens with attached computer. But if hardware was documented, the battery problem would be easily solved as well.

        2. ” If hardware was documented, tons of e-waste which is being exported to third world to be recycled could be repurposed to accomplish different tasks: a 7 years old tablet paired with other peripherals could easily become an IoT controller, a webradio bedside clock, a logic analyzer, etc.”

          Yes! They may not be able to used as a cell phone, but still have a useful life, such as those you mentioned or a 3rd world medical device… ecg, eeg, health diagnostic/monitor.

        3. On the topic of recycling, I watched that video of the guy who put a headphone jack on a custom made iphone, and you saw that in Shenzhen they have tons of refurbished phone PCB on sale, plus all other parts of older phones, so the Chinese certainly re-use old phones it seems.

  5. We will still have the same issues, Lots of binary blobs, lack of documentation, bricks because of small errors, locked modems. This wont be a issue on some devices but most will hit one of those hurdles from the start.

  6. I’ve got a Nokia N900 lying about and useless. Now that POS has support for the camera on it, I think I’ll give the N900 a try with it; it could be used as a neat, self-contained timelapse-device or to record video when it detects movement or whatnot. Built-in UPS certainly doesn’t hurt when it comes to such stuff.

    1. i think this is a good example of the futility of this project. surely you have better hardware than the N900 sitting around unused? probably already running android, right? if you want to turn an abandoned device into an ipcam, there are so many android apps to chose from, it is hard to imagine that using an older device with a worse camera and a deader battery could improve upon the experience of simply using a stock $25 supermarket android device.

      not trying to insult you, just thinking about my own stack of abandoned hardware. when i needed a remote camera i took the top device off the stack (a 2013 android). underneath it: a 2011 android, 2010 android, and a 2007 N810. if i got deep enough into the pile that i was considering the nokia, man, the sky must be falling…

      1. The camera on the N900 is better than on the lowest-end Android-phones and even $25 would still be more than the $0 that I’d have to spend on using something that I already have; I just don’t see the futility there. Sure, I do have a few Android-devices, too, but that doesn’t mean I can’t also try to get some use out of the N900.

  7. What’s really ticked me off is that unlike x86 hardware, our phones often rely on OEMs/carriers for OS updates. Soon after production stops OEMs have little incentive to provide updates leaving the user to either: deal with it, try to load a custom ROM with the risk of bricking the phone, or buying a new phone. I long for the day when I can purchase a phone, load the OS I want on it easily, have an easy way to root it, don’t have to worry about SIM card locks, and receive updates regardless of OEMs/carriers.

    I wish this project well.

  8. i love the idea of using a mainline kernel, but the trick to supporting abandoned devices is really broad hardware support and that is going to take literally a hundred times as much labor as this project will ever see. no one is going to put a herculean effort into an abandoned phone because by the time they make any progress an even better abandoned phone has landed in their laps. so instead it’ll just be an alternative OS for a very few supported devices…and the fact of the matter is, most of the time lineage/cyanogen will serve your needs better. android is a good OS for android phones.

  9. Seems to me that a paradigm shift needs to happen within the industry.
    If the manufacturers were to release all documentation once products entered end-of-life, the abandoned products would still be useable. Recently, I’ve been struggleing to bring my old kindle 3 up to date with new software. The only part I can’t get is the closed off java apps. (The hardware drivers are well documented)

  10. I looked into porting this to a Galaxy Note 4 a few months back. I decided to try porting Halium to it instead (another great android alternative IMO, still trying to actually) I applaud this effort as well, I decided not to try making it work for my device because it was, and still is, in its infancy, I might look into it again at a later date though.

  11. Could we use old phones with new software to run pandemic ventilators? They have a screen, a decent processor and memory. Communication could be done via the usb port (better glue that in).

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.