battery usage

[marix11]

3.5 hours the phone from full to 15%. 2 hours screen, 2 android system. Nexus 5x new. Seems like previuos build was better but i had it only 1 day before upgrading to 07/03

[thestinger]

The Nexus 5X is known to have very bad battery life. It's not due to CopperheadOS. Battery life mostly has to do with your screen brightness and apps polling so it depends on which apps you use and your configured brightness. Tor and I2P are examples of very demanding applications since they're services that are always running and they keep the network active.

CopperheadOS features do add performance overhead but it only really impacts battery life under high load. If you're not running anything demanding in terms of CPU usage it won't really make a difference compared to stock. If you are, then it's still not going to drop battery life more than 5-10%.

[marix11]

Yes, me using tor. Also for cpu maybe openkeychain. But still 3 hour its weird. My old s4 under cm11 had 6 hours. I have enabled all security toggles. Do they affect battery much?

[thestinger]

Page cache memory protection is the most expensive of those features followed by guard pages. They are opt-in because they're too expensive to be enabled by default. I wouldn't expect a large drop in battery life from them though.

[canary5]

I didnt want to open new topic. I have weid bahaviour of my device. Sometimes its laging for some hours, only reboot fixing it. Last few days i was testing variuos security settings. I had 2 devices with fresh install identical. After 6 hours one is down to 97%, another to 50%. No activity on both just some identical apps. The one with 50% had androidOs awake all time. Both are 5x

[canary5]

Logcat sent by email

[Rudd-O]

I am seeing the same issue. Basically every time I charge the phone, and then disconnect, battery plummets (the battery screen may or may not show that the phone is "awake" but you see the battery plummettng really fast anyway, and the case of the phone gets hot). The only way to prevent this from happening is to literally power off the phone right after done charging, and then powering it back on. Otherwise, no such luck, the phone will kill itself in 6 hours.

Original poster is right.

[thestinger]

There's no indication that it's related to CopperheadOS rather than an Android / Nexus 5X issue. This isn't meant to be a tracker for all issues in Android and the hardware.

[Rudd-O]

I suspect it is CopperheadOS, because this does not happen with stock upstream Nexus 5X Android.

I have discovered that it isn't the act of charging the phone that makes the phone stay awake or warm. Sometimes after many hours of having excellent battery life, the phone just begins to burn CPU and burn through its battery. No installed app appears as a culprit in the battery life applet.

Is there an adb way to determine what is causing the issue? I would gladly collect more information.

[thestinger]

First, you need to be able to replicate the issue. Then, you could use adb logcat to check for errors or at least helpful information. Alternatively, perhaps there's a clear culprit in adb shell top. The output of adb shell dumpsys power could be helpful. If you can't reliably replicate the issue, it would be difficult to gather any useful information.

You would need to make a userdebug build to get more valuable information than those options, but that would really only be useful to follow up on a trail provided by those easier options. It's not possible to do much profiling or debugging on production builds, especially since CopperheadOS exec spawning is currently incompatible with one of the workflows for debugging apps.

Your inability to replicate it on another device / install doesn't mean much in terms of whether it's also present on stock. Most people aren't running into this issue on CopperheadOS, so it doesn't always happen. There are lots of issue reports like this upstream, so my assumption has to be that it's an upstream issue unless there's a good reason to think otherwise. Unless something is repeatedly crashing due to a memory corruption issue caught by a feature like OpenBSD malloc, there's little room for it being caused by CopperheadOS (and that would be extremely noisy in the logs). It doesn't do anything like adding services or changing anything related to hardware. It's really nearly the same thing as the raw Android Open Source Project.

[canary5]

I think its Cos issue as well, but 2016/04/06 build seems fixed it for me. Me even afraid to update, that build working very nice, except some system reboots;)

[thestinger]

MHC19Q.2016.04.06.11.37.02 was the first build based on the new branch for the 5X, so the underlying code is a different AOSP codebase. In the previous month, we still used the main Marshmallow branch since they provided factory images for the 5X with the security updates only alongside the release from the new branch. So CopperheadOS was not the same AOSP as stock Android last month, but it is the same base again.

[thestinger]

Anything fixed or broken by MHC19Q.2016.04.06.11.37.02 was an upstream change, there were no CopperheadOS changes in that release.

[Rudd-O]

I have begun shutting off Wi-Fi when I am not in range of a Wi-Fi router I want to use. This alone substantially improved battery life, and stopped the phone from getting warm to the touch.

This is some baffling shit, for sure.

Rudd-O
http://rudd-o.com/

[canary5]

Just to inform you, I have updated to 04/15 and again huge battery drain. And apps laging for example chronium. 04/06 was working perfect

[thestinger]

No changes beyond introducing the legacy permission toggle. It's not related to the version, and probably not CopperheadOS.

[Rudd-O]

On 04/18/2016 12:56 PM, Daniel Micay wrote:

No changes beyond introducing the legacy permission toggle. It's not related to the version, and probably not CopperheadOS.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/copperhead/bugtracker/issues/198#issuecomment-211369708

I am very sure that Wi-Fi is the huge battery drain and hand warmer. If I turn it off, and go back to 4G, then the phone cools off, and the Awake bar in the battery details stops. VERY strange.

Rudd-O
http://rudd-o.com/

[Rudd-O]

I have reported the bug upstream:

https://code.google.com/p/android/issues/detail?id=209170

[canary5]

Hello. After upgrading to 28/05 again huge battery drains

[thestinger]

There haven't been changes to CopperheadOS that would impact battery life, and there weren't any changes from upstream either. I doubt it's a problem that's coming and going with the updates. It probably hasn't changed at all.

You should try going to Backup and reset and using the Network settings reset though.

[canary5]

Tnx for the hint. Reseting network fixed drain

[thestinger]

It was probably caused by the Nexus 5X WiFi driver bugs then. They were triggered by MAC address randomization, but not consistently. Maybe it only happens on specific boots, so updating happened to cause it by rebooting.

[Rudd-O]

Resetting my network did not fix the drain.

Rebooting the device temporarily solves the drain, but then it comes back.

[canary5]

Yes it was temporary fix. Next day same problems. I need reboot to fix it. But thats temo solution. Weird all May versions worked good for me

[canary5]

Seems i have same problem on nexus 6p. First 3 days after install it was perfect, now i have drain again

[thestinger]

Battery drain without further information isn't going to be considered a valid issue. If it's the netmgrd issue, then it belongs in that issue report.

[poisonsnak]

I had the same issue. Phone "awake" all the time when on wi-fi, battery graph says android system is keeping the phone awake, poor battery life (nexus 5x), warm, didn't have these issues on cm13 or stock.

I started uninstalling apps one by one and k9 mail turned out to be the problem, further to that, its IMAP IDLE (push) feature. (Stock and cm13 had exchange support, I believe stock uses gmail and cm13 backports an old version of the mail app that has exchange, which is why I turned to k9 mail and IMAP IDLE) Turned that off and now my battery life is actually better than it was on cm13 / stock (about 30% per day vs. 50%).

This isn't really a bug report so if it's not appropriate please delete or let me know. I just wanted to post so people browsing and seeing this thread would see a good experience with CopperheadOS and a possible solution

[thestinger]

CopperheadOS is very close to AOSP and the only battery life impact would come from exploit mitigations making the code a bit slower. It only causes a tiny hit to battery life when the CPU is churning away, not during idle. Any other kind of problem is likely an app or simply an upstream bug in AOSP. I've worked around various AOSP bugs that are not present in stock due to them replacing components and having Qualcomm sources in-tree for their internal builds.

[Rudd-O]

On 08/09/2016 07:47 PM, Daniel Micay wrote:

CopperheadOS is very close to AOSP and the only battery life impact would come from exploit mitigations making the code a bit slower. It only causes a tiny hit to battery life when the CPU is churning away, not during idle. Any other kind of problem is likely an app or simply an upstream bug in AOSP. I've worked around various AOSP bugs that are not present in stock due to them replacing components and having Qualcomm sources in-tree for their internal builds.

It's worthy of note that I don't have K-9 Mail on my phone.

The apps I had when I started experiencing the problem:

Barcode scanner, CatLog, Document Viewer, Conversations, Ghost Commander, OsmAnd~.

End list.

A quick read of what is going on right now:

The phone came off the charger 7pm yesterday. It's 12:43 AM and it already has 27% battery, with a projected life of 2 more hours before it dies. The battery view makes it clear none of my apps are consuming CPU or keeping the phone active. The phone has been awake most of the time, whether screen on or off. Screen has been on for 52 minutes, but CPU has been awake for 4h 4m (Android OS is the second biggest consumer). Mobile radio (the biggest consumer) has been active for 4h 45m. However, the phone has been on Wi-Fi all the time and it's specifically told to remain on Wi-Fi during sleep, so mobile radio usage should be minimal. Wi-Fi running time is 0s even though the graph shows Wi-Fi active since the phone powered on.

It's not even funny. I don't know what's up anymore.

Rudd-O
http://rudd-o.com/

[thestinger]

Try temporarily removing Conversations or perhaps signing out.

[Rudd-O]

On 08/09/2016 10:49 PM, Daniel Micay wrote:

Try temporarily removing Conversations or perhaps signing out.

I have tried that, and that did not help. I will try again in the hopes that today's update to Copperhead may have made a difference. Wish me luck.

Rudd-O
http://rudd-o.com/

[Rudd-O]

It made no difference to disable Conversations. The phone still decided to insufflate its battery as if was a bag of coke.

I DID track the problem down, though. The permanent transmissions from my phone to the router are of the form:

22:18:49.998760 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:50.329467 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:50.329514 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.175207 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.175258 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.472169 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.472215 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:52.439179 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
<tons more, constantly, two or three per second, nonstop>

This is despite the fact that the router has VERIFIABLY disabled IPv6.

This means I need to request one of several things to kill this cancer:

1. Ability to root my phone while preserving signatures (so I can disable IPv6).
2. Ability to completely disable IPv6 in the security settings, so the kernel stops being idiotic about this (no, there will be no IPv6, that is a deliberate policy decision to be revised in a few years).
3. Ability to firewall the phone to my liking so it stops sending requests (likely to provide me with only modest battery savings, since the kernel will still want to send traffic).

Please, can we get (2) on the docket?

[Rudd-O]

Those messages, I have deciphered, are sent by Android as part of IPv6 multicast. Looks like there's some crap bug in Android. It only happens after the phone has been on for a while. The multicast listener reports stop happening after the phone is rebooted, but resume after a while of the phone being on. I do not know which circumstance triggers that issue.

[poisonsnak]

I can confirm that I am having this issue as well. I was good after uninstalling k-9 mail for a couple days and now it's back, it just starts up part way through the day while connected to wifi and with wireshark I see the same broadcast messages on my LAN that Rudd-O is seeing. I have 4 other android devices on the same wireless AP and they are not doing this, so I'm not sure if the bug is specific to the AOSP on the Nexus 5X, or CopperheadOS. I have been using the phone for about 6 months and this is the first time I've experienced it, but I'm no expert. I would think it would appear quickly on a google search for "android multicast ipv6" for example if it was widespread and affected stock Nexus 5Xs but I haven't found much: https://www.reddit.com/r/Nexus6P/comments/41cutc/disabling_ipv6_may_improve_your_battery_life/

Some of the guys there think it is related to certain wifi access points. I'm using a Ubiquiti ER-X router and UAP-AC-LITE access point. What are you using Rudd-O?

This was interesting as well. https://code.google.com/p/android/issues/detail?id=197460&q=wifi%20drain&sort=-opened&colspec=ID%20Status%20Priority%20Owner%20Summary%20Stars%20Reporter%20Opened I will try disabling 5GHz and report back... in a few days

[Rudd-O]

I'm using an OpenWrt access point with IPv6 entirely disabled (the interfaces themselves have the disable_ipv6 sysctl enabled), but I also can confirm that the problem happened at the AP of my previous employer, where IPv6 was enabled.

My phone is connected to the 5 GHz band.

[poisonsnak]

Changing to 2.4GHz did not help, it started up on me already this morning.
Do you know these are coming from the kernel in android and are not caused by an app somehow? It just seems weird to me that the CopperheadOS devs know nothing about this, there must be a combination of things causing this. What do you have installed for apps? This is my list: AirOS Mobile Amaze AutHomationHD Authy FreeOTP IceCatMobile inSSIDer K-9 Mail (after I found it wasn't the cause, I reinstalled it) MuPDF Steam WhatsApp

When I have time, hopefully this weekend, I'm going to wait for the bug to appear and then try using netstat in adb to find out where they are coming from http://stackoverflow.com/questions/14229816/how-to-use-adb-shell-to-find-the-ports-which-a-process-is-using

[Rudd-O]

It is 100% certainly coming from the kernel, because it's the kernel that is responsible for IPv6 address negotiation, and those absurdly repetitive packets are part of the IPv6 address configuration process.

Rudd-O
http://rudd-o.com/

[thestinger]

CopperheadOS doesn't do much that's relevant to this. It only adds a couple netfilter rules (reverse path filtering and dropping INVALID packets) and changes a few sysctl settings. Perhaps that's triggering this for you, but it's not doing anything wrong. I can't replicate this, so I can't debug it.

[Rudd-O]

I no longer believe it's CopperheadOS that's causing this. This must be some sort of complex grand mal seizure that the Android kernel is experiencing. Clearly there is no reason, regardless of netfilter rules, that the kernel would need to bombard the LAN with this idiotic series of packets.

I will have to take this up to the Android folks, who are epic in their unresponsiveness.

It is, however, a problem for the users of your technology, given that it's not just me, and that it doesn't seem to affect just Nexus 5X users. Might be worthwhile to try and set up a reproducer, then debug the kernel. I could probably do it myself using some perf goodness or something like that, if my phone was not limited to non-root apps. Right now, I'm limited to whatever is non-root that I can to diagnose the issue... and that's not much I can do.

This is why I prefer open Linux systems over the nonsense that is modern locked-down "Linux".

[thestinger]

It could be a bug triggered by the netfilter rules.

[Rudd-O]

On 08/12/2016 09:02 PM, Daniel Micay wrote:

It could be a bug triggered by the netfilter rules.

Well, yes, that's true, but

(1) would that not cause the issue unconditionally and at all times I'm on Wi-Fi? (2) if that was true, then I would still have no way to actually diagnose the issue, because I do not have root on the phone.

Rudd-O
http://rudd-o.com/

[poisonsnak]

It started up again today. Here's a brief history of what I did to trigger it: friday, 8AM - unplug phone, at 100%, set wifi during sleep to disabled as I needed the phone to last saturday, 11:30 PM - set wifi during sleep to enabled. Battery at 75% (no charging in between) sunday, 1:45 PM - left the range of my wifi AP sunday, 2:55 PM - returned to within range of my wifi AP sunday, 3:45 PM - noticed phone was hot, had been awake for some time.

From 2:55 to 3:35 you can see netmgrd crashing over and over in the log. It seems to stop crashing (or does this get suppressed in the log after a while?) but the wakelock persists until the phone is restarted.

I think this leaving and returning to the AP may trigger the issue. The last time it happened, I was at work, ran out to pick something up, came back, and noticed my phone was hot a little while later. adb logcat.txt

adb shell dumpsys batterystats shows netmgrd with 30 minutes of wakelock All kernel wake locks: Kernel Wake lock netmgr_wl : 30m 54s 463ms (4 times) realtime adb shell dumpsys batterystats.txt

adb netstat had only one connection udp 0 0 192.168.11.117:68 192.168.11.1:67 ESTABLISHED - which I believe is for DHCP? Seems odd for it to be connected for more than a few seconds. I ran it again after 5 minutes and the connection was still established. adb netstat.txt

adb shell top had this for usage User 4%, System 5%, IOW 0%, IRQ 0% User 74 + Nice 1 + Sys 109 + Idle 1653 + IOW 0 + IRQ 2 + SIRQ 4 = 1843 adb shell top.txt

adb shell dumpsys power had this to say about wakelocks Wake Locks: size=1 DOZE_WAKE_LOCK 'DreamManagerService' (uid=1000, pid=4278, ws=null) adb shell dumpsys power.txt

I've attached the full output of these commands. Hopefully this helps track down the source. I won't restart my phone for the rest of the day in case you want me to try something else.

[Rudd-O]

Hehehe! I too have noticed that leaving and returning to the AP seems to trigger the problem. Unbelievable, how did I not put those factors together?

[thestinger]

The netmgrd issue is already known. It's a memory corruption issue in that proprietary executable detected by the hardened allocator.

[Rudd-O]

I "took my phone away" from the Wi-Fi network while tcpdumping (verifying that the phone was in fact no longer in range), and returned it within the Wi-Fi range after about 30 seconds. The problem does not seem to have recurred.

I will try the same thing for a longer period of time now.

[Rudd-O]

I tried it, and I cannot reproduce it. The phone is no longer sending the ICMP6 messages. I will try reenabling IPv6 on my router again, see if I can repro that way.

[Rudd-O]

Nope, even with IPv6 enabled in the router, I cannot reproduce it.

But I'm sure this will come up again. I will keep you posted.

[poisonsnak]

On my end, my ISP does not support IPv6 so i have it disabled on my routers.

It happened again today. A couple of new conclusions I drew:

1. You do not have to return to the same wifi AP to trigger the issue. It may have to be the same SSID though. I connected to 6 different APs today, 1 home, 4 work (same SSID) and 1 other.The timeline:
   • 8:46 AM - phone unplugged, connected to home wifi
   • 9:12 AM - left home wifi
   • 9:15 AM - netmgrd crashed once
   • 9:21 AM - connected to office wifi, netmgrd crashed 16x over 5 min. Phone awake for these 5 min but went to sleep after
   • 11:58 AM - left office wifi
   • 12:01 PM - netmgrd crashed once
   • 12:07 PM - connected to office wifi 2. Issue starts up and phone is stuck awake while connected to wifi for the rest of the day (even at the office wifi 3 and 4 which I later visited, and back at 1).

2.. The netmgrd crash does not necessarily trigger the issue, as thestinger implied earlier.

Battery stats show netmgr_wl with 2h 17m 48s of wakelock so far today.

[Rudd-O]

On my end, the phone (after having it be removed from the Wi-Fi by signal loss, and then reconnected, and then charged) after four hours of charging or so, began draining battery and being warm, with the symptoms of the IPv6 requests every 2 seconds or so happening. No network activity or phone activity (that I know of) was concomitant with the event of the phone beginning to warm up — it just randomly decided that it was Summer Time!

Glad I had that packet dump running and eyeing it when it started happening.

Rudd-O
http://rudd-o.com/

[Rudd-O]

Good news — on the Nougat release, I have experienced over a day of Wi-Fi use without seeing the battery drain... or the crazy ICMP6 packets! :-D

[Rudd-O]

12 hours later, still no ICMP6 packets or phone getting extremely hot.

Seems we're onto something here :-D