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).
Which doesn't really apply to a server use case, does is?
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.
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.
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
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.
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
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.
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?
For people that didn't know, this is probably the fastest and riskiest way to destroy your battery quickly
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.
(absolutely not an expert, though, this is why I asked for experiences :-))
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.
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.
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]
[1] https://dontkillmyapp.com/