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

REPRODUCIBILITY: Happens a few times a month.
OS VERSION: (but goes back to v3, I think).


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% ~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 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.


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.


  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.


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


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




None at the moment.

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

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

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.


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.

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.

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.


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

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.

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

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.

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

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.

You could try installing collectd and monitor your device systematically.

1 Like