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.

▲

jeroenhd 6 hours ago | parent [-]

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.

▲

rolandog 5 hours ago | parent [-]

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?

	▲	gf000 2 hours ago \| parent [-]
		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.