Powersave mode extrem

Linus67

In the context of IT and apps (smartphones or PCs)
On mobile phones (such as Android or iOS) and computers, background suspension means that an app is temporarily frozen.

So, in this case, background suspension set to ON means the app is frozen.

Moem

@Linus67 said:

background suspension set to ON means the app is frozen.

But that's not what UTTT does. It sets PREVENT background suspension to ON. In other words, it sets background suspension to OFF.

For most apps on UT, background suspension is set to ON by default.

Linus67

@Moem
Yes, I thought so too, and it matches the description in the wiki. https://wiki.ubuntuusers.de/Ubuntu_Touch/UT_Tweak_Tool/

In my tests, however, the opposite was true. There might be another reason for this. I’ll repeat the test with different scenarios and log the power consumption in sleep mode.

-10 hours of standby (all apps with background suspension)
-10 hours of standby (all apps without background suspension)

In any case, battery consumption in standby mode (accessible only via phone calls and text messages + alarm clock function) can be reduced to a minimum. It feels like a Nokia 3210 with up to 260 hours of battery life, with the difference that modern smartphone features are available at all times.

gpatel-fr

@Linus67

Thanks for sharing this tip!

I tried it on my Fairphone 5.

While I did not use it for all the time since the 2 days and a few hours I enabled it (forgot about it after restarting the phone) I could see that my estimation of the enery consumption of my ravenous Fairphone 5 was a bit exagerated.

The phone got from 85% to 50% in about 50 hours so while not good it's not as catastrophic I was thinking. Mind that I did not disable Bluetooth, cellular and wifi, only Gps is off.

@Linus67 said:

It would be perfect if a “super power-saving mode” like that could be built into UT.

In my opinion the use case is a bit off the general usage AND it has potential and difficult to debug problems with other uses, so it would be best to bake this into an app to avoid too much complaining from not very experienced users.

I'd say that it would be a good fit for TweakUT since it's already an unconfined app and it is managing already the background state of apps, so manual changes to background state could be coordinated with automatic changes when enabling reduced power use.

It would be perfect if there was an API to allow an unconfined app like TweakUT to add an indicator in the top level status too, for rapid access.

Edit to correct 50 hours instead of 5 (!)

sixwheeledbeast

Just want to point you to discussions here.
https://forums.ubports.com/topic/12184/battery-saving-low-power-mode-within-os-discussions
I long for an toggle-able option like this available from the battery pulldown.
With some knowledge of QML and the layout of lomiri-system-settings I believe its possible to implement.

Moem

@gpatel-fr said:

The phone got from 85% to 50% in about 50 hours

Holy hell, that's amazing.

ikoz

Just to clarify what the scaling governor is because there is some confusion that it magically improves battery life: The scaling governor (as I had already said in a post some years ago) essentially doesn't allow the CPU to increase its frequency and thus saves power. Note that performance doesn't scale linearly with frequency so the processor is most power efficient during low frequencies. However, while the device is idle, an optimized OS does many other things including changing the governor to save power like disabling the performance cores. So, any benefits should be observed only while using the phone, unless of course the port is not optimized at all.

Linus67

Two days ago, I charged a Pixel 3a (24.04-1.3 rc) to 90%. It is now still at 37%. The scaling governor is active. This reduces power consumption to 22mA. When the scaling governor is not active, power consumption drops to only ~240mA

The device can receive calls and text messages. The alarm clock works too. (Nokia 3210 mode

The same behavior on my daily-use Pixel 3a. Without using Wi-Fi, the battery lasts at least 2 days.

I’ve tried to build a script that turns off Wi-Fi when the screen is turned off and keeps the scaling governor always on for all cores. Unfortunately, without success so far. It should be a solution that still works even after an update. I currently don’t see any loss of functionality.

Linus67

I found the reason for my increased battery drain when using Wi-Fi.
On January 26, 2026, I installed an app called "UB Connect" from the OpenStore. ubconnect
I uninstalled it shortly after. The app wasn't uninstalled cleanly, and a ubconnect.daemon.service remained in the system.
Whenever Wi-Fi was turned on, this daemon would automatically start, but it failed because the app was missing. This prevented Ubuntu Touch from going into power-saving mode after the screen was turned off.

After uninstalling and deleting all leftover files from the ubconnect app, Ubuntu Touch goes back into power-saving mode with Wi-Fi on, and the battery consumption is minimal like with mobile data.

Moem

@Linus67 said:

leftover files from the ubconnect app,

Where did you find these files please? I may have a similar situation.

uxes

@Moem you might wanna know that more applications does this daemon copy thing and after uninstall the service is there https://codeberg.org/tautologia/ubconnect/src/branch/master/ubconnect/daemon/install.sh
for example that smartwatch app

Moem

@uxes Thank you for the hint... I took a leap of faith and ran systemctl --user stop ubconnect-daemon.service and got a command prompt... no errors. I took this as encouragement and ran systemctl --user disable ubconnect-daemon.service and it told me something with UBconnect in it was removed. I think that was probably useful!

As for smartwatch apps, I'm still using those, so they can stay.

Linus67

@Moem

I was monitoring the journal with “sudo journalctl -f” while I turned the Wi-Fi on and off. I noticed that when turning on the Wi-Fi, a connection attempt by the daemon fails.

sudo journalctl -f
Mai 20 19:14:25 ubuntu-phablet systemd[2850]: ubconnect-daemon.service: Main process exited, code=exited, status=1/FAILUREMai 20 19:14:25 ubuntu-phablet systemd[2850]: ubconnect-daemon.service: Failed with result 'exit-code'.Mai 20 19:14:30 ubuntu-phablet systemd[2850]: ubconnect-daemon.service: Scheduled restart job, restart counter is at 89.Mai 20 19:14:30 ubuntu-phablet systemd[2850]: Started ubconnect-daemon.service - UB Connect Daemon.Mai 20 19:14:30 ubuntu-phablet aa-exec[5041]: [5041] aa-exec: ERROR: Failed to execute "/opt/click.ubuntu.com/ubconnect/current/usr/bin/ubconnect-daemon": No such file or directoryMai 20 19:14:30 ubuntu-phablet systemd[2850]: ubconnect-daemon.service: Main process exited, code=exited, status=1/FAILUREMai 20

gpatel-fr

@uxes

dekko does it too.
IIRC every app that is installing a systemd service I have looked at don't remove it when uninstalled.

Moem

@Linus67 said:

I was monitoring the journal with “sudo journalctl -f” while I turned the Wi-Fi on and off.

Thank you! That's a bit above my paygrade.

Linus67

@Moem
As @uxes wrote

Run the following commands in the Terminal.

systemctl --user stop ubconnect-daemon.service
systemctl --user disable ubconnect-daemon.service
rm -f ~/.config/systemd/user/ubconnect-daemon.service
systemctl --user daemon-reload
systemctl --user status ubconnect-daemon.service

result:

Unit ubconnect-daemon.service could not be found.

Moem

@Linus67 As I said, the first two were what I did, after figuring out they might be helpful.
Can I be a little proud of myself for figuring that out? I'm not a terminal user at all.

Moem

@Linus67 said:

rm -f ~/.config/systemd/user/ubconnect-daemon.service

Thanks to this hint, I knew where to find it and removed it using the file manager.
All clear now!

The advantage of using the GUI in this case was that it showed me what else lived there. There was another daemon that was no longer needed. So that was helpful.

uxes

@gpatel-fr yes that is just missing thing of click packages since they don’t have some kind of postinstall and postuninstall hooks to insert and remove those systemd services

gpatel-fr

@uxes

It's a feature, taken from the click documentation:

4.3.2 Specification
• Only system packages (i.e. .debs) may declare hooks. Click packages must be declarativeinclude code executed outside AppArmor confinement, which precludes declaring hooks.