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.
