Energy saving for Xperia 10 II and III

Hardware Adaptation
#1

SYSTEM

  • OS VERSION: 4.5.0.19
  • HARDWARE: Xperia 10 II dual SIM
  • ANDROID SUPPORT: licenced and installed
  • UI LANGUAGE: English

APPROACH

Recently I set the enery saving mode at 100% of battery threshold which means always active:

Moreover, I dimmed the brightness of the screen to the minimum and I have installed and activated the Pure Black Backgrounds patch which it expected to save energy with OLED display which is the case. The display is set to sleep after 30 seconds.

DATA COLLECTED

The System Monitor was running since the begging and collecting data. Here a composition of what I found:

power-consumption
power-consumption1200×2400 327 KB

The high-resolution image is available for download from here.

SCENARIO

In the area highlighted, the smartphone was resting alone with no native nor Android application apparently running and with the Android Support active.

Despite this the activity about system processes were more intense that normal usage but despite this the battery discharge rate was less or about 1% which is a great achievement.

OBSERVATIONS

Counter sides effects: some sub-system was not working when the smartphone has been waked-up. In this specific case the Bluetooth. More often the fingerprints reader get asleep probably and should be reset.

There is a huge opportunity to extend the battery life leveraging the power save mode as far as all the hardware sub-system are awaken correctly and at expences of the response time because applications starting lag a bit.

In fact, I have installed and activated the Reduce settings app lag patch but this patch changes the visualisation of some SFOS native menu/app not the time of starting of an Android apps.

PROPOSAL

The START / STOP states for the Android Support are not enough because clicking on an Android app, also the Android Support starts automatically. It would be much better having an option to disable the Android Support to avoid that it can support any application without the express will of the user:

  • disabled, stopped - A.S. is not running and it will not start automatically
  • disabled, running - A.S. is put in a sleep state for which it results unavailable
  • enabled, stopped - A.S. behave like now starting when requested by an app
  • enabled, running - A.S. behave like now when it running giving the service

With these option the Android Support can be kept safely disabled but quickly to gives it service if the user need it. This will make the SailFish OS more reliable about Android apps background activities and more power energy saving.

1 Like
Quick start guide v1.7.3.4
A collection of tasks and a request for changes
Support the latest version of Sony binaries
#2

UPDATE #1

I did the same this night long. These are the data collected shown in a picture:

power-consumption-night
power-consumption-night1200×1920 265 KB

The high-resolution image is available for download from here

The green area is about night with Android Support running. While the red are is about using the smartphone in developers mode with a SSH connection active and some light administrative / investigation tasks plus sporadic use of UI plus 4G connection shared with the laptop and listening music in streaming from the native browser using BT earphones.

OBSERVATIONS (p.2)

As you can see the CPU usage is quite plain in the red are while jitters much more in the green area. Despite this, in the green area there is not an energy issue because the discharge rate is below 1%. This means that the smartphone can deliver notifications from Android apps without sensitive compromises energy consumptions. Great! :heart_eyes:

Moreover, both the BT and the fingerprints reader was immediately available after having configured the Android options with Settings:System → Android Support → Show Licenses → (back). This might have correctly awaken or keep alive these hardware subsystems. A further investigation and test will be conducted.

IMPROVEMENT

I noticed that there are three settings about smartphone behaviour:

  1. default - users customisations applies
  2. silence - I expect that the no sounds are produced but music
  3. do not disturb - it is not clear for me this mode thus ignored

The #3 has a moon icon and suggets me that it is for the sleeping/night time. As thumb rule, the best user friendly interface is the one that defines behaviours in a situational manner like:

  1. meeting, note barred - I expect that the no sounds are produced but music
  2. sleeping, dark moon - it is not clear for me this mode thus ignored

The icons two icons complete the interpretation of the labels. During a meeting, I do not want that my phone makes any sound but streaming audio just in case the meeting is conducted using the phone itself. During my sleeping time, the same like in a meeting and the Android Support can be send to sleep if no any user-started app is running - in that case the user should be questioned about.

Warning: user sleeping mode is going to be activated but one or more Android apps are running, do you want close them and {disable, stop, suspend}¹ the Android Support?
(Yes) (no) [_] native apps also [v] rember my choice

After all, if silence is required there is no reason to retrieve notifications until the next morning and moreover, the user might have shutdown all the data connections as well.

The situations model is much easy to be accepted because the users always know the kind of activity THEY are doing: it is the SMARTphone that understand the user will instead of being the user to have to understand the modes options. :wink:

NOTES

¹ depending the implementation of Android Support supending and disabling options.

A collection of tasks and a request for changes
#3

UPDATE #2

The energy saving investigation goes further including the fingerprints reader suspending/awakening conjecture issue:

This is the post in which some more data has been presented.

#4

UPDATE #3

Request for (technical) comments: for those interested - temporarily - at this link below:

It is available a brief analysis with the aim of choosing the most appropriate CPU governors for the Xperia 10 II and III. When this will be completed that two sections will be moved on another page in the same project.