Interesting. I use the Touchdown client for my corporate e-mail access and our Exchange server is 2013, so no issue there. HOWEVER.... I DO have 3 outlook.com accounts that I access using EAS via the native mail client. When I let auto-discover configure the mail setup for my outlook.com accounts it setup a connection to a a hotmail.com server. I bet it's entirely possible that some of that infrastructure is still hosted on EX 2010. I know for a fact that even some of the older Office 365 accounts are still on EX 2010 on the back end. That would mean that it's possible that anyone setting up a Hotmail or outlook.com account using the native mail client (using EAS) might run into this bug.
Thanks for this, but FWIW my wife has the battery drain issue and doesn't
have Exchange at all. So what you're describing may be A cause but isn't
THE cause.
Still not resolved. It would be nice if Verizon would at least acknowledge the battery drain is a real issue caused by some update in NG6 that did not get resolved in NK1. Thanks for nothing.
I have had this issue for months. I have tried many of the tips in the previous posts on this thread, disabling location, disabling the Verizon support app, nothing seems to help. Even in airplane mode it drains faster than normal. I used to be able to put it in airplane mode and could go hours before it dropped a single percent. Now even in airplane mode it drops a percent every 10-15 minutes. If out of airplane mode the phone sometimes gets extremely hot and battery can drop at a rate of 30% in a matter of an hour or two just sitting in my pocket. I usually go into work at 8:30 and by lunch time (I usually have lunch around 12:30) it is always less than 50%. Before the culprit update I used to be able to go 2 days on a single charge if needed. In the battery status it used to always be the screen (at around 50%) that used the most battery which is normal. Now it is almost always Android OS on the top of the list by an abnormally large margin (30-40%+) and the screen is like 15-20%. Something is WRONG here VZ. Please fix this, there are enough complaints already. We should not have to be contemplating rooting our phones or flashing them with some mod because our batteries are dying before a single work day is up. I'm starting to wonder if when I really need the phone in a potential emergency that the obvious battery drainage issue might literally be the death of me.
Seeing process krtccd chewing up CPU again, and battery that was fully charged at 8 AM is under 50% 2.5 hrs later.
Running Terminal Emulator, and executing top -n 1 clearly shows krtccd taking 50% CPU.
Anybody have ideas of how to debug what krtccd is doing? If there is some offending 3rd party app involved, as the Verizon Moderators seem to be pointing fingers at repeatedly, there should be some real way of drawing a connection between krtccd and an app. Otherwise, their claims should be treated as guesswork.
Try starting in safe mode, then add apps one at a time to see if that reveals the one that is eating the battery.
I already can see that it is not an app that is chewing up CPU (hence battery), but an OS daemon, called krtccd. While it's possible some 3rd party app is invoking the OS in such a way that causes the daemon to behave this way, I would contend that the development owner of the daemon should handle and control bad input from an app. This is why I was looking for a way to debug the daemon. Additionally, rebooting seems to stop the daemon for a while, and I have not found any way to force it to recur.
I will play around with safe mode and see if I can see what you mean by add the apps back in. Certainly, if that means uninstalling and reinstalling, that is not practical or useful, as having the apps active right now does not guarantee a recreate of the condition. So, not seeing the problem after reinstalling would not be proof of anything.
Broadening my search a bit, I found that krtccd is a Kernel Runtime CompCache Daemon.
This forum has some more detail on that:
[Q] Android System 4.4.2 drain | Samsung Galaxy S 4 i9500, i9505, i9505G, i9506 | XDA Forums
and:
compcache - Compressed Caching for Linux - Google Project Hosting
So, who needs to look at it? It appears to be an Android function, but I only see complaints for Samsung products, and the only carrier I have seen specified is Verizon.
After my last update, I contacted the developer of the CompCache project. Here is what he had to say:
"zram (aka compcache) needs careful tuning to make sure it doesn't work against you. I really consider memory compression with zram an experimental feature and it really looks bad that the vendor on your phone does not even allow turning it off. Also, zram is in active development, so not sure if your vendor picked up a buggy version or made some custom changes.
As such, without detailed information about their configuration I do not have a way to fix your issues, so I would just keep pushing the vendor to allow disabling it at least."
He points out that development of zram is maintained by other developers at this time.
I asked if he could give some pointers on debugging zram when it is chewing CPU? Or maybe some reasons under which high CPU usage might be 'normal'?
He replied, "It's possible that a process/app has a memory leak or it simply is consuming large amounts of memory. In such cases, the kernel would keep pushing pages out to the swap and zram would make things worse by keep trying to compress incoming swap pages -- in memory leak or excess use conditions it would be better to just let the app die."
The next time this crops up, I will try to pay close attention to the memory usage at that time, True memory leaks can lead to loss of memory allocation accounting, so that my not be terribly useful, but at least it something to try. Certainly, it could explain why a reboot alleviates the problem for some amount of time. At the end of the day, it still indicates that krtccd (CompCache / zram) is either not handling low memory conditions well, or is just plain defective.
I hope Verizon deals with this soon. We're overdue for a system update, there's been several SSL vulnerabilities in the libraries shipped with 4.4.2 that Verizon hasn't patched yet on the S4. Hope the fix for this is included with it. I'm sick of my battery dying after 3 hours off the charger (I also see krtccd using most of the CPU, and rebooting will temporarily fix it for a few days).
Start a new topic or ask questions in the open forum.
