I am too lazy to shut down the web browser or close tabs, so my phone tends to stay warm and needs to be charged more often. I wish that Phosh would pause background applications when the battery is discharging and the application is not playing anything. I wrote this shell script that does some of this logic, but because it cannot detect when an app is not in the foreground, it responds to the screen saver status instead:
#! /bin/bash
dbus-monitor --session "type='signal',interface='org.gnome.ScreenSaver'" |
while read line; do
case "$line" in
*"boolean true"*)
if [ "$(cat /sys/class/power_supply/bq25890-charger/status)" == "Discharging" ]; then
if [ "$(timeout .3s playerctl -s status)" != 'Playing' ]; then
pkill -STOP firefox-esr
echo "Web browser stopped."
fi
pkill -STOP gnome-software
#sudo pkill -STOP jitterentropy-rngd
#sudo pkill -STOP waydroid
echo "Other applications stopped."
fi
;;
*"boolean false"*)
pkill -CONT gnome-software
pkill -CONT firefox-esr
#sudo pkill -CONT jitterentropy-rngd
#sudo pkill -CONT waydroid
echo "Applications resumed."
;;
esac
done
The script above requires this installation: sudo apt-get install playerctl
I suspect that the reason why the apps do not get live updates to their thumbnails when selecting them is that they are supposed to be suspended when not in use. Web pages contain lots of ad and tracking code that runs in the background, so Firefox (or any desktop web browser) consumes more power with each tab that is open.
In smartphone application development, every thread is automatically suspended when the application is not in the foreground unless the developer explicitly designed it to run in the background. Desktop and server operating systems and applications do not have this concept.
I wish it doesn’t. For example, if I run a command that will take 1 minute in a terminal and switch to web-browser to read something in this time, I don’t want that command to pause.
I think the automatic suspend option from Settings/Power is better, suspending all apps.
There is something else that helps (see gnome-session-inhibit). Every app that wants to keep the screen on (book reader and maybe pure maps) will inhibit the screen saver. The user does the same when it interacts with the touchscreen. The user can override this, turning the screen off, by pressing the power button. In addition to this, an app can inhibit suspend. Lollypop, for example, will prevent suspend when playing an audio file. It is even nicer that it has controls on the lock screen, so that I don’t have to unlock the screen to pause/resume/skip that audio stream.
There is something that your ignore (by not closing tabs): the memory. From what I understood, android can signal an app to save its state and than close/kill that app (freeing memory). When the app is restarted with the old state, it might look like it was never closed, not even if the phone has been restarted. On Linux, the closest thing to this are the web apps
But matt specifically wrote: if the browser does not play anything.
A terminal activelly running a command is something else. Firefox for example uses much CPU resouces when only showing a static website in the background.
But you may want after that command got task complete. Suspending applications in background is a good thing, but I also don’t want every app suspended to every time in background. There should be some smart mechanism that decides when an app can be suspended and when it is a problem.
If I run a matrix client in background, I don’t need all the CPU-cycles … I just a notification service. If Lollypop runs music on lockscreen, I don’t need all the other applications not sleeping. All that stuff can expend time until battery is empty on active usage. If you can expand that time from 4 to 5 hours, why we shouldn’t go this way in general?
Good points. For some reason, Firefox does take a second to resume depending on which JavaScript bloated web pages I have open and if those have been suspended for a while, but I assume that this happens with CPU suspend as well. If Firefox was just suspended a few seconds or minutes ago, the resume is not noticeable. I would be willing to deal with suspend-resume during app switching because the times that it takes a while to resume are not frequent, I need Internet based communication stuff to run in the background, and not having the phone die is kind of a plus.
Certain well behaved apps that are frugal with their background threads can be exempt from application suspend, such as the terminal, but not necessary everything that it launches (like Firefox).
I do not know if WiFi 6’s target wake time intervals are long enough for CPU suspend and resume to be viable, but that could be another way of doing it. However, that kind of software development is specialized and expensive.
The main reason why we need application level suspend is to get the battery life benefit while supporting VoIP (SIP) and other IP network communications, like Matrix. Maybe the apps that get suspended will encourage their developers to write mobile device friendly code. Maybe they do not want to optimize for a phone, but laptops are certainly a use case for most GUIs and would also benefit from longer battery life.
Personally, I start an application because I want it to do something or what it does. If it has nothing to do it should sleep/wait by itself, without being babysitten. Otherwise, is a poorly written app and I’ll have to close it myself when done (if I can’t use a replacement for that app). The main problem is the memory used by that app. The kernel will have to compress-move and decompress-move memory as the app switches from active to inactive. The kernel might kill your foreground app because you like to collectsuspended apps.
A web browser should take care of its tabs/windows, and give an option to its users to suspend inactive tabs (and maybe enable it by default), because the user doesn’t know what apps (javascript code) runs in each page, each time it is loaded and at each moment.
If an app consume 1% CPU when idle is one thing, 50% is another thing. I might accept the first case, but not the second. That app should be babysitted (not kept in brackground) or replaced.
I whish I had some kind of a notifications for the second case, e.g. when the cpu load is more than 80% for more than 5 seconds - make red the background of the top margin. The same with the memory consumption (bottom margin red, so I can swap and kill apps).
I am all for an informed and empowered user. Notification of poor idle behavior would be great, along with an option to babysit the app (suspend all its threads when not in the foreground).
That said, the behavior of some apps like Firefox are so bad that they deserve to be idle managed by default until the upstream project fixes it. There should be exceptions for when the battery is not discharging or sound is playing. Of course, if you want a pocket warmer, this could be disabled.
What’s obvious for anyone is that with a single forground app and a single tab the phone becomes warm faster than anyother phone. The best thing to do is to fix this first. From what I’ve seen, Purism has a good priority list regarding the software for L5.
One other thing that I think will make the battery last longer is to reduce the current used when the phone is suspended. We will notice 10-15% battery percent lost during the night instead of 40-50%, and we will feel it during the day too.
These things should be done first because it will affect all users, regardless of their way they are used to launch apps.
They also use another CPU than any other phone is using. I’m sure it is the main reason for the temperature. And nothing easier than fixing temperature: reducing CPU cycle speed to much less power. But I’m sure that’s also nothing people want.
Another way would be to improve performance of applications, but that is a job of app-devs, not of Purism. But let’s be clear: the heat is nothing that will ever be “fixed” with current version of L5. Therefor we would need a better CPU that can also be used free of proprietary blobs. Maybe L5v2 or later could solve this.
Btw this is no design issue. There was just no better possible solution.
I think that you’re right about heat emitted from the phone. I found NXP power consumption measurements PDF for i.MX 8M Quad (temperature measurements start on page 13), and it seems to me that the SoC is running at least warm, when it performs basic tasks.
This is not really surprising, at least to me, as i.MX 8M is intended for automotive. I expected from the start that battery life will be noticeably shorter, compared to mainstream Android phones, and that it will run warm most of the time. I guess there is still room for some optimization on the software side, but nobody should expect miracles.
There is no point in complaining about these compromises. We can either accept them and make the best of it, or get a different phone.
I haven’t noticed someone complained. I thought is a forum in which we can discuss about warm/cpu/battery and solutions that can improve the phone software.
Unless you are referring to the person who complained that someone else “complained”
I am sure that not every software developer at Purism has the same skill set, so some might be doing the low level hardware / kernel work, while others do primarily GUI stuff. So really, each skill set has its own priority list, which may mean that someone who can do hacks similar to my shell script may have the time available and not take time away from the person doing the CPU suspend.
Fortunately, Purism put in a large battery to compensate for the automotive CPU. How well that ends up compensating after all of the software work is done is anyone’s guess, but my hope is that it can last longer than most smart phones with only basic cell usage. However, applications like Firefox will continue to be a problem. I hope there is eventually enough influence and talent from mobile users to fix this eventually. Forcing Firefox to suspend when backgrounded (while the battery is discharging and no sound is playing) is a good way to recognize the problem to a larger group of people, and provides a functional workaround for other apps that behave badly on devices with scarce resources.
I am aware that memory is not freed by application suspend, but I would rather deal with closing tabs on a schedule closer to my choosing, and not being forced to do so right before not using my phone for a while.
I love my browser extensions, so that would be step back in functionality. I would have to give up script blocking, tab synchronization between devices, and a few other useful tools. At that point, I might prefer using Firefox on Andriod. Epiphany scrolls poorly on my desktop (it jumps around a bit), and it also performed worse on the phone. But maybe if they can redo enough of the rendering code to do what mobile web browsers do, then it may be an acceptable compromise. Of course, if they can bake in the same features, then that would make it great. But this is GNOME that we are talking about. They think of configurability as synonymous with complexity; something to avoid. Because of that, KDE will need to be an option for uses who expect more from their desktop environment.
