Smartphones can be connected for days on the internal battery, using well under a watt, and they can be ready to respond instantly, and they have an app container system that makes everything just work.
I really think we need to start making Android servers a thing, at least for self hosting, maybe for everything.
Judging by how WearOS seems to be able to run on 35mA or less, I think there's a good case for just making an open fork of Android with similar optimizations, and putting it on literally everything resembling a smart device. I wouldn't be surprised if some kind of Android for Devices comes out someday, assuming Fuschia doesn't ruin the party.
Raspberry Pis (and similar devices) already work great as low-power servers.
The big issue is the home server community being overly focused on creating "battle stations" that look cool and run 40 different Docker containers rather than simple low-power solutions.
Pi doesn't work that great, power consumption is still several watts, too much for batteries to be cheap and compact if you want a day or two of backup, plus self hosting in general is very much enthusiasts only.
Android does what Docker does while remaining very low power, because it gives you one standard API level, rather than some minimal syscalls and you have to bring all your own libraries right in the container.
The power saving is not because of Android it is because of the ARM arch being used under the hood. And ARM servers for power saving purposes are very much a thing already.
> The power saving is not because of Android it is because of the ARM arch being used under the hood.
[citation needed]
Based on my understanding, the underlying OS has way more to do with power usage than the instruction set, and AFAIK Android has tons of optimizations specifically geared towards reducing battery consumption (and therefore power usage) on mobile devices.
With that said, it's true that, in practice, the power floor seems to be lower for ARM devices than, say, x86, but I'd wager that this has far more to do with target market than with ARM's instruction set. Low power x86 boards do (did?) exist.
It's both, if you want to achieve the goal of operating for multiple days on the battery.
A modern battery powered device will have a 'sleep mode' where the current consumption is measured in microamps; and an operating mode where the current consumption is many times higher. Battery life relies on two things: Firstly, the sleep and operating modes being as efficient as possible (the CPU design) and second of all getting into the sleep mode for as much time as possible (the OS design).
If only one app can be on screen at a time, and the OS is free to stop anything that isn't on screen if it wants to - that gives the OS a lot of power to achieve long periods of sleep.
(It's actually more complicated than that, with multiple sleep levels, high- and low-power CPU cores, and on smartphones there are issues like powering the screen and radios, and things like hardware decoding of video - but for a server, who needs a screen?)
Not having a screen is another blocker for self hosting some of the time.
It means you have to enable SSH with some file in a directory, then SSH in, make sure you have a strong password, turn SSH off when you're done, maybe copy and paste or SCP a key somewhere.
With a screen you don't depend on the state of anything else to do admin. Your more savvy relatives can install things for you without them needing the special paired remote admin app.
And of course, you can do "Scan to get started" QR setup.
Plus, in a real consumer self hosting scenario, it would make sense for the server to also be the smart display if you want one, to avoid needing more devices, and keeping the screen would mean developers don't have to explicitly code from both screenful and screenless setups, sometimes things that shouldn't depend on the screen do unnecessarily.
On Linux stuff works differently if you run as a service vs under the DE, because you're missing some environment variable that points to dbus or whatever, and you need extra work to get around it.
> Firstly, the sleep and operating modes being as efficient as possible (the CPU design)
My point is that this part doesn't really have much to do with the instruction set, though. Theoretically, there's no reason you couldn't design an x86 CPU that is just as efficient as an ARM one (or at least, within spitting distance); it's just not done because the economics wouldn't make sense.
Or a dedicated server device that only uses the battery as a backup. Some of the stuff in a phone is unnecessary for a server. Some might be useful like LTE and GPS, but a full resolution AMOLED isn't, a cheap 3" screen is enough.
Or a timer/smart plug on the outlet that keeps the battery from being 100% charged all the time.
It'd be nice if things had logic to control their own charging -- start charging only when the battery drops below 40%, stop charging when you hit 90%. The hardware can do that already.
(And then you can expect something like normal phone battery lifetime, which is still limited.)
As I see it there's a few missing features, and they need to be solved anyway to make self hosting less painful in general, right now I don't see many good ways to do it at all unless you like stuff that unpredictabily needs maintenance.
Play store needs to be split into provider and interface APIs, so you can add your own repos and still have it work with existing tools.
Remote management needs to be a thing for sure, installing apps is the hard part of that. WearOS does it amazingly, just connected to BT and the host play store does it, but you'd need the split app store to make that work well with open source third party repos.
Automatic updates would be solved by that, just deploy your app on a repo, and update via the play store or your interface app of choice.
Finally you'd have to solve the biggest problem with ANY self hosting as far as I'm concerned, how to handle certs and domains with zero manual IT work(Has to be truly zero, no chance it needs maintenance while you're on vacation).
I've been saying this for a while, we need pubkey-based domains like .onion URLs, but without the onion routing, so there's no dependence on a CA or anything that might be hard to do in a fully automated "Scan the QR and connect" context.
Or, more likely, Google gives you a service.yoursubdomain.google when you buy Google One, and routes stuff ngrok style for you, with lots of spying, because P2P hasn't been their thing so far. Perhaps one of the forks could do it though.
Without eliminating domains and certs, I'll continue mostly ignoring self hosting, I don't want any chance it goes wrong while I'm too busy to fix it, since there's no dedicated support staff, just me.
It would also solve the other half of remote admin, apps could just declare a web interface for admin that you access if you have the secret URL.
Then you'd need some systemd alternative to manage processes. You'd have to be able to say "Start this on boot, restart it on failure, and never clear it out of RAM".
On the hardware side, phones are already close to perfect. Keep the screen and NFC and Bluetooth, for QR based connections and the like, keep the battery as a UPS, but add more USB ports, Thread/Matter, and ditch or downgrade the cameras.
The filesystem probably needs to support snapshots, and Android should get a Full Backup and Restore Provider API to make it easier to back up everything, just the home folder, just one app, just the settings, just the data, etc, to your chosen provider, maybe even with hooks for apps to respond to import and export, so that the state of your app is totally portable and needs only a few clicks to restore from auto backup.
Finally, we need a cpanel-like VPS management tool to migrate your stuff to cloud hosted if you want, that can take backup files, and show you what's on the remote device's virtual screen(Again, so QR stuff works) or at least what's being displayed via some "Admin screen API" if you don't want to drag the full graphics API into it(But keeping graphics all the time seems like a good plan for standardization, and for kiosk type stuff).
And then finally, you'd probably want a some of the features from a normal-ish Linux userland, or as close as you could get, to make porting existing stuff easier, but even without that, I'd say the porting would be worth it.
but Android is just based on Linux, so in theory you could tweak a regular Linux server on ARM hardware to get good energy efficiency. The downside of Android is its reliance on Java, which adds a lot of overhead compared to bare-metal languages (I strongly believe - but have no sources or figures to back this up - this is why Apple phones have been faster and more energy efficient, especially in the earlier days (think iphone 4 and co)
Android doesn't run apps in a Java VM. At build time, the Java bytecode is translated to DEX bytecode, which is designed specifically for Android. Today, at install time, the Android runtime compiles DEX bytecode to native code. You're probably right about this being true in the early days, but not so much anymore.
I think the power usage difference between Android and plain Linux on the same hardware is mainly due to the way Android aggressively puts the CPU into sleep states and uses timers (etc) to wake it up as needed.
I'm no Java enthusiast but this screams for source.
I'v always thought it is how iOS manages threads vs in a way Android cannot. But all that info is from more than decade ago, so things may have changed. Can anyone chime in to explain?
To this day iOS feels snappier, perhaps lower latency input/output or something. Am saying as someone who uses and prefers Android and currently using Samsung Galaxy S10 phone (flagship phone line)
Android has the NDK now, it can run native code with only tiny headers of java to launch it, plus ART compiles the Java anyway as I understand it.
Regular Linux could be tweaked, but I think it would be way easier to start on Android and add all the missing stuff you want for a server, than to start on Linux.
Regular Linux still uses a bit more power, and they don't have any kind of container+sandbox that works quite as well, on account of the very tiny userland API that requires containerized things to bring all their own libraries, making them like 800MB a lot of the time, can't really run more than a few apps in 16GB of cheap slow flash like that.
> Regular Linux could be tweaked, but I think it would be way easier to start on Android and add all the missing stuff you want for a server, than to start on Linux.
Things still break on Linux almost every update. Android has a lot that Linux doesn't, as far as I know Linux has very little that Android doesn't other than easy support for legacy Linux apps.
Termux works great as a server environment really. The trickiest part is to start phone without old battery and actually have automatic booting after power outage.
I accidently discovered earlier today that the Fairphone 3 works without it's (easily swappable) battery. So maybe other brands still build them like this.
Since we're talking about an Android phone for self hosting, if the phone is glued/the battery is soldered, after rooting it, the Advanced Charging Controller App* may be an option.
I really think we need to start making Android servers a thing, at least for self hosting, maybe for everything.
Judging by how WearOS seems to be able to run on 35mA or less, I think there's a good case for just making an open fork of Android with similar optimizations, and putting it on literally everything resembling a smart device. I wouldn't be surprised if some kind of Android for Devices comes out someday, assuming Fuschia doesn't ruin the party.