zlacker

>>wicket+(OP)
As someone willing to put up with all manner of nonsense (overpriced/underpowered hardware, clunky UI, endless troubleshooting), battery life on mobile Linux devices alone prevents me from using them in the real world.

Is there a single Linux phone/tablet that can last an 8 hour day of actual use? Librem/Pinephone/Juno can't. My uConsole can't. Different category, but my MNT mini laptop lasts like 4 hours and can't be left in standby for too long or it drains to zero.

Meanwhile, it's been 10+ years since I've worried about daily battery life on mainstream mobile devices, even my 3-5 year old ones. I can fall asleep with Youtube playing and it's still playing when I wake up. I'm certainly not here to dunk on Linux phones. I want one! But if someone willing to put forth above average effort to use these devices can't realistically daily drive them, who can?

>>Variou+Xf
This is a big part of why Android was developed in the first place. The operating system and application architecture that makes sense on desktop just doesn't make sense on mobile. Despite the many problems Google's restrictive APIs which you are forced to use can cause for developers, they are also highly optimized for power usage.

>>sharpe+CL
Android is also Linux, so Linux isn't the problem - its the userspace. In terms of wakeups, the systemd/dbus desktop architecture is the worst.

>>bluefl+rP
UBports (the maintained fork of the dead Ubuntu Touch project) runs fine with systemd/upstart/wayland.

Hell, my watch runs Tizen and that's running a bog standard Wayland + PulseAudio + systemd setup: https://docs.tizen.org/platform/porting/system/#systemd

With the right kernel drivers, configuration, and tweaks, with a well-configured userland on top of that, you can run the "normal" Linux stack in a mobile device.

Getting applications to conform with an API that won't let them drain the battery in the background to make sure notifications don't arrive two seconds too late is much harder. Desktop applications don't really like being suspended/resumed the way mobile applications do.

>>jeroen+8R
That's quite interesting. How would one go about making one's app or services suspend/resume friendly?

Are there well-known good practices?... Or, do they need to be rediscovered as they are perhaps proprietary know-how?

>>roland+pZ
By making a soft and then a hard suspend the reality they have to abide by, or otherwise they are killed and users will think they are broken apps.

Mobile apps just had to "grow up" in this environment, plus they have proper APIs for this two-way communication between OS and the app. Android will just ask the app to save its state and then simply unload it from memory (after a while) - but this also makes perfect sense for the desktop scene, you also want to improve energy efficiency there. A spreadsheet app doesn't have to continuously run when it's in the background. You just have to add proper APIs and permissions so that apps can optionally ask for extra background work.