Increased Battery Drain From android.hardware.biometrics.fingerprint?

Bug Reports
#1

REPRODUCIBILITY: Happens a few times a month.
OS VERSION: 4.4.0.64 (but goes back to v3, I think).
HARDWARE: XA2 Ultra
UI LANGUAGE: English
REGRESSION:

DESCRIPTION:

Every now and then I get a small, but noticeable, battery drain increase. It’s mainly noticeable overnight where it can go from full battery to 20-30%, untouched, in airplane mode, with Android stopped. It can be noticed during the day too, if it occurs when away from a charger.

A restart will always fix it for some amount of time.

I recently installed Crest and it seems that the drain coincides with a constant CPU usage in the following two process:
systemd-logind ~ 8%
android.hardware.biometrics.fingerprint@2.1-service.sony ~6%

There is a lipstick -plugin evdevtouch -plugin evdevmouse -plugin evdevkeyboard at ~2% too, but that may not be related.

These figures may seem low, but they’re pretty constant, and over a few hours the battery drain is considerable. They are the top two processes when nothing else is actively starting up, etc.

When I restart, those two processes are back down in the pack of <1%, generally.

One question is, is it safe to restart the android.hardware.biometrics.fingerprint@2.1-service.sony service in the terminal? If so, I could save sometime doing that, rather than a full reboot. It might also help to see if that clears it for a similar amount of time.

PRECONDITIONS:

Unknown, though I do start/stop the Android service when in use/not in use. I don’t know if that’s related, but as it’s an Android named service, it might be relevant.

STEPS TO REPRODUCE:

  1. Can’t reliably reproduce, except that after a varying amount of time after the last reboot, it will occur. It very rarely - if at all - occurs twice in 24-48 hours.

EXPECTED RESULT:

While the phone is not being used, the battery charge can remain at 100% overnight (about 8 hours), or maybe drop to 99%.

ACTUAL RESULT:

When this condition occurs it can drop to ~30%.

MODIFICATIONS:

None.

ADDITIONAL INFORMATION:

None at the moment.

1 Like
Fingerprint process gets stuck in active state and eats energy and CPU time
#2

This might be related: Process systemd-logind constant 3-7%CPU usage, scanning camera and audio devices - #24 by nephros

#3

Looks like it yes.

Though yours about the fingerprint daemon and mine about sd-logind are likely separate issues.

One cause for increased activity of the FP daemons are a dirty sensors or scratched sensor. Can you rule out that that’s what’s causing it?

1 Like
#4

BTW, I find that Crest is not a good tool for long-term monitoring.

SystemDataScope and collectd are better.

You can actually monitor specific processes with collectd, and SDS will show nice graphs for them.
See Monitor CPU usage overnight - #19 by nephros and the posts above that for some info on that.

2 Likes
#5

It may be a dirty sensor - doesn’t look scratched - as it does sometimes tell me that. I

I’ve got the issue now, and I’ve just cleaned the sensor and it’s still running at 6.8%. it’s reading the fingerprint straight off now. I don’t know if I’ll need to restart it to clear it. I’ve got some stuff open that I’d rather not reboot if possible, but I might have to anyway, for the journey home.

#6

I just fire it up when I notice the increased drain, and every now and then when I know it’s not in effect. I’ll look into that though, thanks.

#7

Just another aspect of resource measuring on smartphones:
Their CPUs are extremely good at slowing or even shutting down when not needed, So when you see 8% usage, it might be for one thread only at lowest frequency, not 8% of the phone’s overall capacity.

2 Likes
#8

Hi thanks, that’s worth noting, but the increase in cpu on these processes does seem to coincide with the increased battery drain.

#9

So the 35 walk home yesterday with no data network, listening to a podcast the battery didn’t drop at all. Yet since then the battery drain is again noticeably higher. So this may not be all that initially meets the eye.

Anyway, is it safe to kill that android fingerprint service, does anyone know? If nothing else, it may resolve if it’s part of the issue.

#10

If you want to try at your own risk, there is a service called sailfish-fpd. To disable it as root:

systemctl disable sailfish-fpd
``
1 Like
#11

Thanks. I suppose I could try and restart that daemon - it might kill the process. I did try and restart the fingerprint service using the new Utilities option, but the process wasn’t affected.

#12

I don’t usually like to blame the hardware just because a software solution isn’t easily found, but…

Batteries do get old, and one sign is that they start behaving seemingly erratically. Irregular dropoffs. Fluctuations.
Also I think the system gets the battery state from a circuit that is part of the battery itself, so ultimately you cannot really know what’s happening there and have to take the info at face value.

  • Example: last winter my battery got very cold, the percentage dropped to almost nothing very quickly, and it wouldn’t go back up when it got warm again, even after a reboot. However, putting it on a charger for just a few seconds made it jump back up to its previous value. IMO this means that the electronics inside the battery only count the percentage down and never back up unless it’s charging.
    And yes, I know that extreme cold generally isn’t good for phone batteries, but that’s not the point here.
1 Like
#13

Hi, I understand the point, and wouldn’t rule it out, but as a reboot fixes for several a while (days/weeks) and the variation in use etc., is very small, I’m pretty sure it’s a software issue.

I had to reboot it yesterday evening (long time away from a charger) and it stayed at 98% overnight, no depletion. The biometrics.fingerprint process took a while to find in the processes list this morning, and was shown at 0.0%, whereas yesterday it was pretty continuous at ~6%. systemd.logind is also now running at 0.55.

My guess is, something between systemd.logind and android.hardware.biometrics.fingerprint is causing them to constantly talk to each other (or similar) which keeps them at this constant, low level rate.

#14

You could try installing collectd and monitor your device systematically.

1 Like
#15

So this is still happening, and I haven’t really gotten any futher, except to pretty much confirm that it’s something to do with android.hardware.biometrics.fingerprint.

Collectd is great in showing me the drain and the start time, etc. but doesn’t really show me that the process has suddenly kicked-off.

One theory I’m working on, and it will require keeping a manual record, is that sometimes it’s triggered by turning on the screen - this may be to check the time in the middle of the night. The thing is, that happens a lot and it doesn’t always trigger it - and it won’t always happen at night, but be triggered during the day, when turning the screen on happens a lot.

It tends to go a week or few without happening, then may happen several times in the space of a few days.

1 Like
#16

Here’s my bug report concerning my issues with that process eating CPU time and energy:

Sadly, it doesn’t seem to have attracted Jolla’s (or actually anyone’s) attention.

1 Like
#17

Thank you, I hadn’t seen that (I’ve been a bit hit and miss on here recently). I’ll go and have a look.

1 Like
#18

After a few months of testing, not using the fingerprint reader - I’m 99% certain that it is triggered by its use, and doesn’t occur from wake-up.