Please add function for automatic power saving mode

Does the Battery saving mode also enable the power saving mode? Because on my phone enabling the BSM doesn’t provide absolutely any benefits when it comes to battery life and also the CPU clocks do not seem to get reduced.

By looking in mcetool I think you need to use --set-forced-psm=enabled to activate PSM if battery charge is above the threshold.

Power-saving-mode seem to be always enabled and forced-psm gets enabled when you activate PSM in setting.

1 Like

I did some tests about power saving reported here:

which are based on some information collected in this thread, starting from this post

After these tests, my opinion is that the Xperia 10 II & III should be equipped with few templates (system configurations) about power management. Below, I will describe these templates in terms of their features.


nightly stand-by

  1. WiFi, Bluetooth, mobile data, fingerprints reader, sensors, photo cameras and GPS all off and as far as possible their hardware subsystems should be powered off. For the GPS, the gpstoggle can do that but for the other hardware subsystems I have not checked, yet.

  2. The Android Support should be disabled and zRAM swap should be off-loaded with the script from this patch.

  3. CPUs [0-3] for Xperia 10 II and CPUs [0-1] for Xperia 10 III should be set to minimum working frequency and to conservative scaling mode. The other CPUs, the same but put off-line (all the processes will switch to other online CPUs). Linux kernel, real-time and some few specific system processes that need to deal with time jittering tend to rely on CPU #0 only. Moreover because the [0-3] belong to the same multiple-cores CPU, all of them can be kept online. Update: considering that on Xperia 10 II, the CPUs [0-4] are 1.8GHz while the others are at 2.0GHz the first CPUs set is also the one more conservative in terms of power consumption. Instead, in Xperia 10 III the most powerful CPUs probably will be at [7-8] enumeration. Therefore for the Xperia 10 III, putting just those 2 cores off-line will result in a smaller power save.

  4. the external MMC card should be unmounted and its hardware controller powered off while the internal SSD flash should be put in the power saving mode.

  5. the display should be kept powered off unless hardware keys are triggered.


daily stand-by

This templates is similar to night stand-by but with these differences:

  • the second set of the CPUs are kept online without enforcing their working frequency but the max working frequency can be limited to the half of the hardware max working frequency aka top scaling cap.

  • the Android Support - if it is running - keeps running thus the zRAM swap off-loading will be not performed when this template is applied, unless the Android Support was not running.

  • only the hardware related to unused/inactive services (WiFi, Bluetooth, GPS, mobile connection, etc.) should be powered off.

  • sensors should be kept powered on because they can be useful for some apps like shaking the phone to switch on/off the flashlight but not the compass unless GPS is active or used by an application. Like the fingerprints reader, the compass should be awakened when requested by an application.

  • external MMC can be mounted and kept ready. Most depends how fast / reliably we can mount and umount such a partition when it is not used by any application or by the implication about having a fake-root filesystem-overlay (probably none but it has to be verified and tested).


daily power saving mode

This templates is similar to daily stand-by but with these differences:

  • the first set of CPUs are put in interactive (mark2) or ondemand (mark3) frequency scheduling policy while the others are in conservative mode. A top cap about the max working frequency can be set for the second group of CPUs. Therefore the user can decide between daily power saving mode or daily power saving plus mode by an option (one or another).

  • without the plus option activated, also the internal flash are set to a more responsive / performing power saving mode.


daily performance mode

When a battery is less important than productivity or the smartphone is connected to a power source then all the policies can be set to the most performing option available.


general settings

These following settings apply to all the power management templates.

  • The fingerprint reader and the photo cameras should be kept switched off unless the few cases in which should be temporarily awakened for its duty.

  • The GPS should be powered off when it is not used. The same for Bluetooth and WiFi subsystems.

  • The WiFi tethering should be not ask which is the source of data networking (SIM1, SIM2, WiFi) because the user may want to use it to access to the smartphone locally and we do not know which network services s/he installed to be used. Moreover, when WiFi tethering is asking for which source should be used to share the data connection, it mess-ups the state of the toggle button in the topmenu about mobile data when a SIM is chosen. Under this PoV the related Settings page should be renamed from “internet sharing” to “wifi tethering”

  • The WiFi tethering should be powered off when it is not used by any client for a user-customizable timeout (eg. 5, 10, 15, 30, 60 minutes) but the user can disable this by default.

  • Few default native applications takes too much time to be started {phone, SMS/text, contacts/people, photo camera} but these applications are supposed to be used also in emergency situation like calling the 112/911 or call/texting the home/family or take a shot/video of an incident and any other situations in which a photo/video proof can have a sensible impact about legal consequences. For this reason, these apps should be put in run, kept in run, restarted quickly when they are not running (1-min or immediately waiting on their /proc/$pid/cmdline¹) as many times is necessary and the user should be notified when N restarts fail consecutively in such a way s/he can act accordingly.

  • The default camera app should be replaced in the above role by the Advanced Camera when the end-user decides so (optional). Therefore a Settings page about always-running apps should be created.

  • Some other native default apps that the user optionally can decide to keep ready are clock/alarms, calendar, todo-list, notes. These apps lag-to-start can have a social impact: you are in a hurry and meet a person, then you need to set some quickly some schedule, alarm or simply take a note/todo reminder. Some todo reminders should have an alarm associated but I did not see this feature implemented.

  • The always running native apps should not be closed in the default way (with kill $pid, probably) but set to a suspended state (with kill -STOP $pid) and then awaken when they are started again (with kill -CONT $pid). This is an efficient way to have them ready to run.


notes

¹ In all the Linux systems that I had the chance to work on, the /proc/$pid/cmdline still exists when a process is terminated but it is a zombi. In such a case that procfs item is void with zero size. Therefore, the suggestion to wait on /proc/$pid/cmdline is not completely correct but choosing another instance in the same folder is subjective/arbitrary.