View Single Post
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#9
I think the current system is quite good, if you know how to use it. I'll address some specific points below. Please note that my response is based on what I have learned while using and monitoring the phone as well as reading some code.

In general, it assumed that all apps which require background CPU, network, or any other processing, declare it. If you want to make something while user is not interacting
with you, please state it and it will be respected. Technically, even switching on screen leads to acquisition of wakelock and releasing it when you switch it off, in accordance to your settings. Same when you start charging.

So, when you use your apps, you are the one, through these apps, that decides when and how to sleep. On my device, during a day, the device sleeps about 80% (12h average) with non-usage times leading to 95% sleep (one suspend about 1-2 minutes). As a result, we have longer battery usage.

Originally Posted by marmistrz View Post

A well-written application will either do the work it needs to do or wait at a blocking syscall. This means that as long as all of the applications I'm using are well-written, I don't need to suspend the applications.
As pointed out above and by others, you suspend whole system, not just application. Well written application takes into account that it needs to declare if it doesn't like it at this moment.

Originally Posted by marmistrz View Post
A diagnostic tool to find out which applications are battery-hogs plus the possibility to force-suspend the misbehaving ones (as an opt-in; Android Doze is an per-app opt-out which is one of the reasons it's so horrible)
In our case, we don't have per-app suspend. You are supposed to close this app and complain/fix the issue.


Originally Posted by marmistrz View Post
Agreed. Then, if the application will tolerate a ~5 seconds deviation from the sleep time, it should declare it. The system should not break the applications.
Its just that the default setting is sensible for mobile device, not for the one that is plugged in. So, application has to declare if it needs to be on and the system should respect it.

Originally Posted by marmistrz View Post
...
The whole idea is, that just as I am the only lord, master and the emperor on my Arch laptop, I expect the same on a phone.

1. On my Linux box an app will (almost) never be killed unless the situation is critical. Usually, if I run out of RAM (i.e. all the buffers get cleared) the system goes so unresponsive that I use the magic sysrq to kill the memory hog.
I expect the same on a phone: no app killing, unless I approve.
Its pretty much the same. Just only imagine if your laptop could also make these short naps and it would be efficient - now we would be talking about much longer battery life

Originally Posted by marmistrz View Post
2. On my Linux box, an app will not be suspended without my consent. If I'm compiling the kernel and turn off the screen, the device will not stop compiling the kernel because the system is too intelligent.
I expect the same on a phone.
Same here. If you compile kernel, just echo to the wakelocks file and release it later (may depend on specifics of your kernel, but should be the similar technique overall).

Originally Posted by marmistrz View Post
3. The real problem comes when you decide to port a desktop app onto a phone. A correct app will suddenly stop working because the operating system is too intelligent, even if it does nothing wrong.
Yes, its a problem, but an addressable one. I have ported collectd to SFOS and had to rewrite the main loop of this daemon by specifying time when it is expected to be waken up and how to handle wakeup/suspend. Turned out to be rather simple. In the end, with the porting, the main problem is actually that desktop apps are for X, not Wayland. Addressing that is much more difficult.

I hope that I didn't do any major mistakes explaining the system. If so, please correct.
 

The Following 5 Users Say Thank You to rinigus For This Useful Post: