Standby Battery high drain on Xperia 10 III

This is only for standby current
I am splitting this off from the original topic of High Battery Drain X10iii because

  1. It is a reproducible, testable and specific issue. The standby current is not dependent on signal strength, base stations etc. It should be much easier to test , find a fix, and prove it has been fixed.
  2. Until it is fixed, other power drain issues are masked by it.
  3. Jolla has not acknowledged standby drain as an issue, and may not have it marked as a bug requiring a fix.
  4. The original thread is muddied by many issues. This is only for standby current

OS VERSION: All up to


The X10iii has a standby current drain of 0.7-0.8% /hour, when in flight mode.
(This is greater than the extra power to run the cell+wifi+bt radios, and is the biggest contributor to the X10iii short battery life)

The X10iii Android has ~0.2%/hr in flight mode
The XA2 0.25%/hr
X10iii SFOS with wifi and cell, at 0.75%/hr i.e. ~ the same as with them off.
X10iii Android with wifi and cell 0.55%/hr or lower. (I am in a weak and very variable signal area)

The phones were also tested turned off. No change in battery % over 24hrs



My methodology is to charge the phone to 80% (happy with the end-charge setting. Yay!)
Then I set the phone up how I want and leave it unused in a standard place for some hours e.g. overnight.
I then take (InitialBatt%-FinalBatt%)/NumHours = %/hr
These numbers have remained fairly consistent at different battery levels, so I consider the battery gauge readings to be roughly valid.

The basic condition to be fixed is: just restarted, flight mode, no apps running, no Android runtime, no location, NFC off.
Initially this was happening before android runtime was installed. Having a skype running has no significant effect on the drain.
Others have disabled the fingerprint sensor with no reported effect.



Same or better drain than Android.
It should be drawing nothing except the ram retention current, and the fingerprint sensor current. (because cron type processes should have set up the hardware RTC, and not be requiring cpu operation)
Also it should be possible to disable the fingerprint sensor. When a phone is put in a pack, things will brush/bounce against the sensor as you walk, and might result in hundreds of activations/hr






It has been suggested that this would be from Sony AOSP, but so far this is untested

1 Like

Is it allowed to bump bugs? Why does Jolla just not give a single fuck about this problem?

Because they are a small team and don’t have the time to set the priority to everything.

Feel free to contribute to the project.

1 Like

You sound like the type of guy who is perfectly fine with paying for a tablet and receiving nothing.

It would be useful to make some measurements the same way I did, and confirm you have the same issue, and what your numbers are.

Another useful thing to do would be to test the Sony AOSP builds and confirm if this issue originates with AOSP.

1 Like

Can confirm that modifying processor options (scheduler/frequency), or altogether disabling CPU stand-by has no noticeable effect on power dissipation.

Remarkably, stopping the droid-hal-init.service, which kills all those suspiciously dodgy /vendor/bin/hw/android.hardware… processes, results in a significant increase of battery drain (by about 2x). This disables a bunch of things, such as the display, so have a care. Also, it does not appear the service can be restarted easily, so the whole device must be. Surely because systemd is so wonderful.

Any idea whether there are /sys (or /proc) files controlling the power state of the various peripherals? Considering the average current draw during stand-by (display off) is about 30 mA, while it should presumably be less than 5, something is probably not being powered down. Such as a radio.

3 posts were merged into an existing topic: High battery drainage Xperia 10 III

I just wanted to add a link to my observations here:
Logind and udev are dancing in the night:

Not specific to the 10iii but this phenomenon appears when the display is off and may contribute to the OP issue.


Added to internal tracker, even though I somewhat doubt adding yet another bug really has a positive impact.