Install postmarketOS on Android phone and use Docker as a home server
crackoverflow.com
crackoverflow.com
If you are going to setup a server on a phone, it might indeed be a good idea to avoid Android, mainly because of how aggressive the OOM killer can be with background apps.
On Android, killing a background app is not so much of an issue (caveat: [1]), they are designed for this. But you don't want your service or even your ssh deamon to be killed by Android.
Now, I don't know how running the phone 24/24 7/7 plugged in is going to last in the long run, especially concerning the battery. Has someone tried this?
[edit: see below comments, the post actually advises removing the battery]
The OnePlus 6/6T are also supported by Mobian [0], which is just regular glibc-and-systemd based Debian, and so a pretty familiar Linux server experience.
> it might indeed be a good idea to avoid Android
It's a good idea to avoid Android because of kernel security as well. Old Android devices always use out of date Linux kernels even when using custom ROMs, and when running (containerized) network services you really depend on the security of your Linux kernel to keep those things properly isolated. Both PostmarketOS and Mobian do bring current mainline Linux support to these devices, so you can be quite a bit more confident in your kernel that way.
It's a shame PostmarketOS and Mobian don't really support many newer devices well. Last I checked the OnePlus 6(T) were still the highest performance devices that had okay support. The Snapdragon 845 - a 2018 flagship SoC - in the Oneplus 6/6T made them real high performance device to repurpose for a long time. In 2024 though it's now beaten in performance by the Raspberry Pi 5 or RK3588 based Armbian based devices. Those SBCs of course already have much better I/O and more straightforward ways to get a supported Linux running on them (and don't require disconnecting the battery with custom soldering). So you need to be really committed to reusing your old hardware to go down this route.
Well it's "just" a matter of updating the kernel, right? Those linux projects like PostmarketOS do a lot of mainlining, which benefits custom Android ROMs.
I agree that if the goal is to use the device as an RPi, then it's better to avoid Android. But I wouldn't say that Android is less secure than Linux in general (on the contrary, Android has an interesting security model).
But if you're only using it for limited projects as an RPi replacement, then it's probably alright if you're also putting a firewall in front of it, or having it in an isolated network segment with a reverse proxy.
Can you elaborate on that? You seem to be suggesting that there are low-level firmwares on Android devices that are exposed to the Internet and do not receive updates. Which ones? And do they receive updates with Linux on mobile OSes? And if yes, why couldn't alternative AOSP-based systems use those firmware updates?
You can imagine the consequence if there was a vulnerability in say the WiFi firmware or the microphone. The Bluetooth stack is especially vulnerable, with it being an attack vector many times in the past.
On Android devices, only Android has been able to deliver updates to those firmware blobs. This is mainly because these are closed source binary blobs, and are provided by the OEM (often in conjunction with the respective chipset manufacturer, covered by a license agreement).
AOSP and unofficial Linux based OSes like PostmarketOS do not have a license to obtain and distribute these firmware. But even if they did, it means nothing if the support agreement from the chipset maker has ended. Being closed source bits, you can't do anything about it if the respective manufacturer refuses to provide updated firmware.
Ocassionally, some Android custom ROM makers may extract these blobs from more recent devices having the same chipset but running newer firmware, and of course, it doesn't always work (well), not to mention, it's technically illegal. And of course, an official project like PostmarketOS or LineageOS would never do something like redistribute proprietary firmware bits. Projects like these conveniently ignore the firmware issue, and leave it as an exercise for the end user.
Which doesn't really apply to a server use case, does is?
setprop persist.sys.fflag.override.settings_enable_monitor_phantom_procs false
/system/bin/settings put global settings_enable_monitor_phantom_procs false
Termux as an example supports several services that run forever. Works great, sshd and crond don't get killed for example. https://wiki.termux.com/wiki/Termux-services
Battery wise you can use this app to keep it in a healthy range and temperature indefinitely: https://github.com/VR-25/acc
This let me ssh into the real android instead of inside termux, which might be preferable depending on the use case
Nowadays in most phones you can limit charging to e.g. 80%, which is much lighter on the battery.
Additionally, the battery works as a heat sink (or heat store really considering it's just a solid slab of dense material) so expect more throttling when it's not there.
Thanks for the heads-up about the thermal inertia of the battery! Maybe a stationary phone in the server role could use a glue-on passive radiator.
You could take it out but many phones won’t work without a battery so you need to find a way to trick them into thinking one is installed.
For those who never used musl and Alpine Linux (which PostmarketOS is based on), the list of supported architectures and software ported over is quite large; here's a list:
https://pkgs.alpinelinux.org/packages
Alpine is my distro of choice for very small systems and VMs once I make sure there are no compatibility issues with what I need to install/build, which can happen sometimes but is really rare. The amount of saved resources (CPU, storage) is significant, making it ideal for VMs.
last big issue i remember is they not implementing fallback-on-tcp when getting large dns record replies, so some dns record resolution would fail. the standard clearly says to switch to tcp under certain conditions, but they did not.
the bug was reproduced and reported, they refused to acknowledge it and kept the issue for a lot of people for a long time (at least one year iirc). they eventually relented and and implemented the correct behaviour.
call glibc what you want, but at least they don't have such dumb issues and that attitude.
call glibc what you want, but at least they don't have such dumb issues and that attitude.
I... Don't know what to say. You really can't think of one decision that the glibc maintainers have made that caused a lot of pain for users? Pretty sure the musl author has/had a blog post full of them. You don't write c library for no reason at all.
Depends on the workload. Running anything which relies on C libraries under the hood is a minefield. E.g. Python's C libraries are often not compiled for musl, so each Python package installation requires compilation.
And it's easy to keep them at around 100%. For instance: For a nominal 12v battery, one can very nearly just feed it 13.8v (plus or minus some temperature compensation) and have results that are actually pretty good and close-enough to 100%.
And when things go very wrong, lead acid batteries tend not to catch on fire.
It's a natural fit for UPS duty.
The lithium batteries in cell phones are a different thing. They hate being at 100% SoC and degrade fairly quickly in that state.
They can be pretty happy at around 50% SoC, but it's hard to actually keep them there because of the way the voltage ramps [don't] work with lithium chemistries: It's almost flat through the middle of the curve.
And cell phones don't let us do that anyway: It'd be great if there was a "Compute mode: Just do your best to keep this battery near 50%" setting to click on, but there is not. (And we could hack that in, except: We don't own our phones.)
And when things go wrong, they can become exothermic in ways that are not exactly ideal for an unattended device sitting on a shelf.
It's only solving part of the problem though: Sure, it can keep the charge at around a self-reported 50%. But the device itself doesn't necessarily have a good idea of what 50% even means, especially as the months and years tick by and cells age, unless it is allowed go closer to the extremes (closer to 0 and closer to 100, sometimes).
The reasons for this get weird. Near the edges of the curves (0 and 100), the BMS can use voltages to figure out where things are. This works well.
In the middle of the curve, voltages are damn near flat and cease to be an indicator of state-of-charge, so the BMS counts coulombs instead. This works too (for awhile).
Except they're not ideal batteries. They age even if they're not being used at all, and shit happens just as it does for any other non-ideal entity. So on a long-enough timeline, even a perfect coulomb counter doesn't necessarily have any way to accurately report state of charge.
The way that this problem is dealt with on a phone that actually gets used like phones get used is that the BMS can reset the coulomb counter during the peaks and dips of a normal charge cycle, based on voltage.
But charge cycling doesn't happen even with a Chargie-equipped phone sitting on a shelf and running Docker containers, does it?
Overall though, it would probably make the most sense to physically remove the battery from any phone used as a dedicated webserver, and then have it connected to an external UPS instead.
And yes, agreed absolutely: It safer to pull the battery, and not particularly difficult or detrimental to do so for the kinds of applications I'm envisioning here that involve a disused phone doing server-ish stuff.
For people that didn't know, this is probably the fastest and riskiest way to destroy your battery quickly
I dedicated an Nvidia shield K1 to be a Sonos interface. Just mounted it to a monitor arm and left it plugged in for something like four years. The mount was this beefy metal thing, a little steel cage for the tablet, but as soon as I unscrewed it enough to remove the tablet from the mount the tablet undramatically exploded. It ballooned to a width that was thrice the original thickness of the tablet, pushed the plastic apart, and it was clear that the case was never going to come back together again. I was afraid to touch it, lest it rupture.
It seems like it would only be a terrible idea beyond a certain scale. The pillowing battery is just assisted disassembly. And now it's easy to get the battery out.
Although swapping battery of ups is surprisingly easy. Buy a new one from online store with a few dollar. Disconnect the connection to old battery.(a REALLY important step). Remove old one. Slap the new one in. Connect the wire. And pre-charge it for a few hours. Then it can just go back online like a new one.
(absolutely not an expert, though, this is why I asked for experiences :-))
I could be interested in using my PinePhone like this. Its battery is removable and the phone can be started without it, but the Wi-Fi / Bluetooth module won't run without it. I had the idea of faking the battery like this, but I don't have the skills to handle hardware like this.
To be completely honest, what I had in mind was to use it as a Bluetooth receiver to play music using my dumb speakers. I don't have a Bluetooth receiver and at this point if I have to buy something I might be better off buying some off the shelf device to do this. So the status quo is to just plug a laptop the times I want to play music in this room because I don't care that much about it.
However, this may still be constrained by OEMs restricting access to AVF or by battery enhancements that make it virtually unusable.
This drives me nuts.
Sms forwarder app + tailscale on phone, python script on server that forwarded incoming sms to telegram bot (probably could use webhook to avoid this step though). Worked perfectly with 100% uptime
That makes the whole thing a lot less interesting. Install linux on a small computer and do linux stuff with it probably wouldn't get clicks.
At 60%, the battery will drop to 45% percent before recharging to the specified percentage for coulomb counter drift compensation.
Most lithium UPS avoid this by using LiFePO4.
Moto G04 with 128GB Storage (UFS - 400MB/s read/write), 4GB RAM and 2TB capable SDcard UHS-I slot is just 90 USD.
ZRAM is enabled by default at 2GB and 2GB storage swap, it's adjustable under "RAM boost" setting.
Disabling the app background killer is one toggle away for Termux.
No root required.
Wi-Fi does around 350Mbit with no buffer bloat, and supports simulatenous softAP and station mode with a dedicated DHCP by enabling hotspot without mobile data. This is useful for out of band management, e.g if Wi-Fi AP goes down, there is a small hiccup though.
You can combine Speedify and Tailscale (for NAT) to have 99% uptime with seamless failover since there is a mobile modem in there. ;)
The Type-C port is dual role and will charge from a powered hub in host mode. However connected devices power is disrupted for a split second if the charger is removed, so the phone isn't really a UPS for external peripherals unless you don't mind the brief reconnection.
I do hope a Pi A+ or something similar and popular exist in the future at a reasonable price, considering that we have phones that are cheaper than the Pis while missing GPIO but adding camera, speaker, screen, case, charger, LTE, and a headphone jack which was also removed on the Pi 5 (USB DACs aren't consistent with pipewire).
Mini PCs vary and they aren't really portable, hard to setup headless, especially projects utilizing an easy DIY approach like the Pi-hole or kit/pre-flashed SDcards.
For comments comparing a new Pi with used PC: used Pis exist and are a lot cheaper after shortage.
The translation: “With the help of simple tools, a loaf of white (or rye) bread can be turned into a trolleybus…
But WHY?!”
The label on the wrench says: “Skillful hands.”
1) A lot of people, particularly people who would be in the mindset to install PostmarketOS, probably have an old Android phone lying around, or at least know someone who has a phone they'd give up for free because it's currently living in a desk drawer or something. This means you can get a home server for free. Android phones aren't exactly the fastest thing in the world, but they're probably fast enough for a lot of servery things, and even a relatively small 128GB internal disk can still stream a fair number of movies if they're generously compressed with H264 or something.
2) Power consumption. My phone charger that I'm using right now peaks at 20W, and idles at considerably less than that when the phone is fully charged. That's getting into "guilt-free" territory; you can leave this plugged in and not really have to worry about your bill spiking as a result.
https://github.com/cyberkernelofficial/docker-in-termux
I've done it successfully a few times and it works just fine.
Android and Termux have their limitations. Granted, I was running a full KDE session in Termux on a 2016 phone, but I saw Android OOM-kill random processes in Termux. You probably don't have a swap partition on your Android phone. Android apps are designed to be killed when in background, and Android avoids killing the app at the foreground, but Android doesn't know some processes running in Termux shouldn't be killed. This could happen if something on your server suddenly uses more RAM than anticipated.
On a regular Linux distro, you can have a swap file and/or teach the OOM to not kill some critically important services, like ssh for instance.
But the PinePhone is none of this: terrible phone quality, the modem on my device is unreliable, the autonomy is okayish. I also had a PinePhone Pro that died: big improvement except the autonomy was much worse and it would strongly eat. I believe that's what killed it, actually.
With good hardware, I would be happy with a Linux mobile OS. But I don't use WhatsApp, I don't have a banking app, I don't pay with my phone, and have no proprietary app in general.
Things like Wi-Fi calling would probably not work neither, but I don't have this with my old Android phone neither.
You will have to hope mobile alternatives to Signal will work well enough for you too (and I guess that requires liking some adventure, but if that works, you also win on not being limited to one phone per Signal account).
You mention autonomy a lot, and I agree. I don't think it's a question of hardware: I can install Android on my PinePhone and see that it uses much less battery than a Linux system.
Android was built for that: it is extremely optimized for battery usage. I think it will be very hard to beat that with Linux.
But I'm willing to believe that Linux mobile can improve a lot.
> I can install Android on my PinePhone and see that it uses much less battery than a Linux system
Did you and what did you manage to achieve? I could reach 1.5-2 days of light use with mobian.
While I think it is cool, I am really wondering if there is a future with the idea. If the goal is to run Android apps through Waydroid, then I may as well run Android. If the goal is to be more private... well I think AOSP-based systems like GrapheneOS are in a better position because they get the Android security model.
The cool thing about running Linux is the freedom, but honestly I generally don't need that on my phone. On my phone I want the mainstream apps that allow me to connect with friends and family (yes, that includes WhatsApp and Signal). It quickly ends up being a fancy RPi with a screen and battery (and tons of sensors that probably won't be useful), but then I can actually go with an RPi and SSH from my laptop (I think such server projects suggest removing the battery anyway).
This said, I truly admire all the mainlining work that the PostmarketOS contributors are doing. This really helps everybody, including the AOSP-based Android alternatives.
If you want to ask more questions and this site has some way to message me with notifications feel free! I've been using this Pinephone for at least over a year or 2. Random aside: Don't use an SD card as a boot/main drive. I got a 256 & 128 gb SD card that are read only now..
Unless you have one of their handful of (obsolete) blessed phones and pay them money for the privilege, you can't use their stuff.
I get that they're effectively a startup spun out of Nokia, and that they'd rather sell value than give it away. Still, non-Android Linux for touchscreens is in a sad state. Having one of the only options locked up where few people can try it and nobody can contribute to it makes the ecosystem worse.
There's gotta be a better solution to raise all the boats than get a handful of enthusiasts with old Sonys to pay them $30 each.
Personally I like having Linux on the phone a lot for other reasons as well. For example, last summer I was backpacking in North America for several weeks. At some point I realized that I'd really hate to lose the photos on the memory card of my DSLR. Instead of getting another card and hiding the first one somewhere "theft-proof" in my belongings, I just went to BestBuy, got a memory card reader, plugged that into the phone, mounted the memory card filesystem and rsynced the files home over my vpn - which is exactly what I would have done if I had my laptop with me. Sure, I probably could have figured out a way to achieve something similar on Android as well, but having all the familiar tools available made it so much easier.
I preferred SailfishOS on my Jolla Phone (and my Jolla Tablet) as the experience is much better with how you can access files on the file system etc. But for various reasons (including a cracked phone screen) I went back to Android several years ago.
Essentially this means all control with the device has to be on the few buttons, and the USB, and all feedback must be through USB (or maybe audio)
How transplantable are screens between phones? Assuming no geometric fit is required, are the connectors/interfaces standardised inside enough to bodge a temporary screen long enough to set-up a remote interface.
About Android, if a device got adb enabled, can use scrcpy to display and control the device from PC. Considering this, the problem is reduced in enabling adb.
If the device supports HDMI-out, can use a USB-C hub to have output and PC connection. If the device supports OTG, can use scrcpy's OTG mode (or attach a mouse via an adapter) and enable adb by doing the required steps manually. If no HDMI out, have to do them blindly. But should be possible using an automation/input tool (like xdotool) to script them. (This procedure can also be used to OEM unlock if want to install pmOS.)
If the device is blessed with unlocked bootloader, can `fastboot boot` a TWRP IMG (almost every device has a TWRP port) that has adb enabled by default. From PC can then set persist enable to true and push authorization keys. If cannot run a custom recovery but the device allows 3rd-party OTA updates in stock recovery, can flash an UPDATE.ZIP that does the same.
Flashing pmOS is also done via fastboot. But probably need to install a custom pmOS IMG to account for the broken screen. Like pre-enabling ssh, similar to how you will do installing Linux to a remote server.
A mobile phone is very different from a Linux server in that it's idling most of the time. But if you run a server and prevent the system from optimizing the battery, then it won't last very long.
Oh, wait...
Otherwise, wouldn't be better to invest time and money in a mini-pc with storage and power capabilities better suited for server use?
Has anyone attempted that successfully?
My ideal would be to run *nix on with a web server and NAS. I don't care about borked camera or bluetooth, just wifi would be fine.
btw if you're into this kind of stuff, check out MacPaint on iPad via UTM. It looks lovely! I can't find the link now, but check out Matt Sephton's blog for that:
https://blog.gingerbeardman.com/2023/10/21/list-of-vintage-j...
(ps I write about this stuff occasionally too https://untested.sonnet.io/notes/til/weekly/58/#h-interestin...)
It had only 32GB storage but it was a fun idea, worked great.
I had this chronic disease where every year I'd turn my PC into a hackintosh and my iPhone into a jailbreaked version of it. Recovery took about a week on average.