Comparing G4 Play (harpia) and Moto E2 (surnia) I notice a huge difference in battery drain: the harpia only runs for about 24 hrs (in standby, new battery) on both n and q versions of /e/, whereas the surnia lasts much longer on the official q. (Previous unofficial n and q on surnia also drained fast)
Why does the harpia drain so much? It’s all set to default power modes, but it doesn’t seem to reduce its power consumption much in standby.
It is strange, I’ve got two surnias, both on e-0.15-q-20210312105636-dev-surnia.zip
One drains fast, the other lasts for days… The only difference I found is that the second one shows “BL: 80.0B … 2015-03-13” in fastboot mode, which is two months newer than what the fast draining one shows.
Does anyone know what this BL: … refers to?
Maybe BL refers to the fastboot BootLoader version itself?
The harpias I own (q) can last for a week if they stay in standby mostly.
Do your SIM cards belong to different mobile networks? if yes and one devices next tower by proximity has a weaker signal and the device antenna is compensating, it could explain higher drain. To give merit to the idea you could swap SIM cards for some duration.
(I upgraded a Fairphone3 stock firmware (upgrades the modem firmware too), upgraded /e/ and had to use a new SIM card - sadly all at the same time, so it’s hard to pin the cause, but the device now drains a lot of battery in standby, mostly attributed to mobile network standby in the settings)
Interesting! Are your harpias dual-SIM? Mine are single SIM model XT1604 with BL 01.12 (2017-11-03), first on n, later on q15, q16.
It seems then that similar to Moto surnia some model/modem variants are much better than others in terms of drain. (Even without SIM installed btw)
XT1602, dual-SIM, but only one SIM inserted. Fastboot string says
BL: 81.12 (sha-f9417da, 2017-11-03 00:21:25). As far I can tell, battery drain behaviour didn’t change across releases, q17 currently.
How can energy profiles be compared? I think a benchmark is, default install, no apps, battery drain over 24h without checking screen, AccuBattery average values during sleep? is there anything I can give you to compare?
Thanks, I believe your figures (several days standby). Mine need recharging after 24 hours without activity…
Hard to tell what’s the culprit - something prevents them going into standby properly it seems, and only with certain versions of the manufacturer’s firmware.
I’ve ordered an XT1602 to try! Will report…
My intuition is… it’s all in software, battery capacity/lifetime and mobile network signal strength… I would be surprised for you to find a difference in X1604 vs X1602 if you also benchmark with the same battery and SIM card.
I came to your post in the first place as I see a regression with another device - fairphone3 - after a stock firmware upgrade and then /e/ update the battery drain is considerably heightenend (like… 2,5% per hour in standby according to AccuBattery what should be <1%). So while I think a weak signal to the mobile tower can contribute, it cannot explain the high standby figure. What is yours?
Mine is more like 5% per hour in standby.
Not sure if mobile signal/SIM is crucial for the Motos, since drain is also high without SIM installed.
Also, I’ve got several surnias, all XT1527, and the ones with the later BL revision (as shown in fastboot menu) last for days, whereas the others drain like XT1604.
Got an XT1602 and installed latest 17q. Hardly any battery drain compared to XT1604 ! (same 17q)
Tried to raise as an issue for harpia in Gitlab but my browser (Pale Moon) doesn’t seem to work Gitlab properly.
The XT1602 is the only one with two SIM slots. Could it be as obvious a problem as /e/ constantly checking for SIM2 which doesn’t exist?
Gitlab issue opened: Battery drain on single-SIM models (#3492) · Issues · e / Backlog · GitLab
This should also appear in “What’s not (yet) working” on the device description: Info about Motorola Moto G4 Play - harpia but doesn’t seem to. Do I have to set a label?
After observing AccuBattery for 2 weeks: battery drain in standby on a harpia X1602 dual-sim is 0.6% per hour (compared to FP3 -2,6%) , a charge with 30min screen interaction, default apps +4 and wifi enabled, holds for 5-6 days.
While I think there is no connection to the battery drain issue with a FP3 (FP3 battery drain (#2522) · Issues · e / Backlog · GitLab), debugging the issue should employ the same tools: Profile battery usage with Batterystats and Battery Historian
Right now I’m time constrained, but will debug with the battery-historian both devices until end of July.
Thanks, that should be helpful in finding the source of the drain.
How much detail do you get from your historian app?
How much detail do you get from your historian app?
it’s very detailed, see this old reddit post or upstream repo for examples. The docker run is trivial.
If my readout is right, my 2,8% discharge rate with an unused FP3 device is caused by blisslaunchers WeatherUpdateService keeping a constant “partial wake lock” throughout the day. The cpu can’t sleep and drains battery. Despite having the widget set to “refresh every 8 hours”. Maybe it cant decide on a location and keeps probing.
A user posted my issue already at backlog#3217 (referencing com.asksven.betterbatterystats as AccuBattery alternative for users not able to use adb/historian).
Had to enable
adb shell dumpsys batterystats --enable full-wake-history before generating the
adb bugreport bugreport.zip to get these wake lock stats. Can really recommend battery-historian as way of debugging and I’m curious what you’ll find with your XT1604.
just to give an impression - on a default install (!) on a xt1602 harpia discharge rate without wifi is <0.5%/hr, with wifi on (second half) ~0.6%/hr - with 1 sim card slot populated and no active mobile data connection - and almost no interaction