Related
guys, I found out that the G-sensor daemon "akmd" alwasy takes up to 3% cpu on my N1 with CM-5.0.5/6.
I compared with stock ERE-27 rom, in which "akmd" in that takes less than 1%.
While during standby, it take no CPU usage.
Does it matter? I mean, would that kill our battery?
Actually I first found that out when I was using CM-5.0.5. One day I put my fully charged N1 beside my pillow and after 7-hr sleep, only 86% power left..
Maybe it has something to do with the 360 degree launcher2.
I personally don't use that feature. I'm gonna take a look at my usage.
I just noticed this as well while tinkering.
Gimpeh said:
I just noticed this as well while tinkering.
Click to expand...
Click to collapse
I realize I'm bumping an older thread now but I still feel this might be relevant.
Running top at any point will still show "/system/bin/akmd" which is the system daemon for the compass.
In my case, it almost always resides underneath "system_server". I've tweeted it at Cyanogen once but got no response to my question.
So, after doing some digging, I pulled down the SDK and fired up the "Dalvik Debug Monitor" here's what I saw (See attached: android-troubleshooting2.jpg)
Edit: i42.tinypic.com/m953rq.jpg
Not that it needed reiterating but the AK8973 is the 3-axis compass chip and something calling it or (the driver itself) is throwing an error almost precisely every 10 seconds. Now, I belive this has only been happening since the upgrade to CM5.0.6-N1 (Although I am now on CM5.0.7-Test1) either way whatever bug there is, still remains.
Edit: i40.tinypic.com/21liauh.jpg
Googling for that error: "Compass driver encountered fatal error2" pulls up a single page in the CyanogenMod Forums and two error logs on PasteBin.
Bump!!-Bumb!!
Thanks for the bump! Being a lurker has it's definite disadvantages.
prophetjinn said:
Maybe it has something to do with the 360 degree launcher2.
I personally don't use that feature. I'm gonna take a look at my usage.
Click to expand...
Click to collapse
In my testing, the use of 360ยบ rotation nor the setting of "Launcher Rotation" changed whether akmd was consuming resources.
Full size image link: i40.tinypic.com/dxh0yu.jpg
Just as GaryD had posted here:
forum.cyanogenmod.com/index.php?/topic/3129-ak8973-compass-driver-encountered-fatal-error2
after a reboot the errors disappear for a while. I don't know the pattern to which they reappear (e.g. due to a buffer overflow or some other reason.)
confirmed...
I think this issue is with newer kernels. I saw it on various versions of CM before switching to enom's TheOfficial rom. Doesn't exist on unmodified versions of enom's rom, but I just loaded several of the newer 2.6.33.x kernels and all show akmd using 1% cpu while the phone is sleeping.
Additionally, power drain while sleeping with these kernels is between 5 and 7 milliamps, while with the stock rom (and enom's stock kernel) it is between 3 and 5 milliamps.
If anyone wonders how I am getting these numbers, I am using OSMonitor (from the market). I sort the processes, reversed, by CPU%. To get the power drain, I look at the dmesg log and filter for the "batt" tag.
I may post this as a new topic for the kernel devs to review if it gets no attention here...
bubbahump said:
I think this issue is with newer kernels. I saw it on various versions of CM before switching to enom's TheOfficial rom. Doesn't exist on unmodified versions of enom's rom, but I just loaded several of the newer 2.5.33.x kernels and all show akmd using 1% cpu while the phone is sleeping.
Additionally, power drain while sleeping with these kernels is between 5 and 7 milliamps, while with the stock rom (and enom's stock kernel) it is between 3 and 5 milliamps.
If anyone wonders how I am getting these numbers, I am using OSMonitor (from the market). I sort the processes, reversed, by CPU%. To get the power drain, I look at the dmesg log and filter for the "batt" tag.
I may post this as a new topic for the kernel devs to review if it gets no attention here...
Click to expand...
Click to collapse
Since I haven't run any other roms I was hesitant to drag anyone else's ROMs into the discussion. I've seen it with InsectrRaven and the Pershoot but they're obviously all pulling from CM's commits on Github. I realize they're not large amounts of cycles but any usage that can be minimized is something. Right? Maybe I'm just a minimalist at heart.
Much appreciated on the bump and the bump towards the devs.
Another confirm here.
I'm on CM5.0.7-test2 with pershoot 2.6.33.4 kernel. Mine was steady at 6% CPU though.
Confirmed..
E/AK8973 ( 101): Compass driver encountered fatal error2 is thrown in every 10 seconds.
CM-5.0.7.1-N1
Kernel 2.6.33.4-cyanogenmod
this TOTALLY makes sense to me. used the stock ROM for last 3 months and had great battery life. after using cyanogen 5.0.7 the last 4 days, battery life is much worse than the stock ROM for me. also different is in cyanogen this "akmd" always shows up in my battery usage, but this never appears in the stock ROM. i'd make a solid bet that this is a cause of the poor battery life on current cyanogenmod, especially if this thing is hitting every 10 seconds with some fatal error. wonder if it can be easily fixed?
I have an EVO, unrooted, no OTA update, fully stock but used the 'top' app to notice the compass /system/bin/akmd consistently using resources.
Disabling auto orientation has fixed it, and done miraculous things for my battery life (battery graphs can have flat lines!), but I want my auto-rotate back. Is this a case of the accelerometer writing out a bad settings file, or it's a bug or what?
I'm still seeing this issue in the latest cyan r c 2 nightly. I'm confused why the compass would be used for the screen orientation. As far as I know, we are talking about 2 different sensors. The phone has a compass sensor, which is akmd, and also has an accelerometer sensor, which is used for auto screen rotation. The compass I thought is only used in things like maps street view and Google sky map.
Regardless, is there any solution to get akmd to stop running all the time? What process is calling this to even run all the time exactly?
I have the exact same problem (though akmd often takes up 80% here) on Hero with CM6 nightly build Aug 19th. I hope I can simply delete the file somehow.
dvfk said:
I have the exact same problem (though akmd often takes up 80% here) on Hero with CM6 nightly build Aug 19th. I hope I can simply delete the file somehow.
Click to expand...
Click to collapse
was same for me.. i had disabled auto-rotating in "settings->display" and in cyganamod settings.. AND in launcher pro.. (i always lay down on the side and the phone flips and i dont like it).. i did this 2 days ago.. and phone been laggy as **** since then. akmd have had 70-99% cpu all the time.. so i turned it all back on again. and now akmd takes 1% wake and 0% sleeping.. so wierdo.. shud be the other way around!
any updates on this?
having the issue as well, can't get rid of it.
please someone let me know.
I am posting here because I haven't made the requisite 10 posts to get access to post to the development forum. Is there a developer that would be willing to help me here?
Wanted:
Dev assistance with a persistent sleep-lock and/or full-charge lock issue experienced with nearly all non-stock roms on a Samsung i897 with a fresh flash of CM 10. (CM 10 is not the relevant detail, this issue has happened with every non-stock-based rom based on anything newer than and including GB. (so GB/ICS/JB suffer this issue)
What are we calling sleep-lock?
Sleep-lock in this case is being defined as a spontaneous shutdown, lockup (requiring removal of battery to restart), or spontaneous restart of the Android OS. I understand that these three results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to be randomly happening when the phone is in a sleeping state.
What are we calling full-charge lock?
Full-Charge lock in this case is being defined as a spontaneous shutdown or lockup (requiring removal of battery to restart; I do not seem to suffer spontaneous restarts while on the charger). I understand that these two results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to all happen when the device is on the charger, but most often when the phone reaches or is near a full charge.
Troubleshooting done to date:
I have tried various ROMs over a long period of time, some were better than others, but they were all victims of this behavior. It doesn't seem to be device-specific (read as hardware) related but ever since DarkyRom that I tried shortly after I got this device a couple years ago, I have had this behavior. Stock ROMs do not suffer this behavior.
Who are you working with?
I am a Sr. Technical Team Leader for a Fortune 1000 VoIP software company and am well versed in troubleshooting methodology. I am somewhat newbish in the ways of logcat so I would ask for a little patience there, but am well versed in Windows, Linux, and many parts of the Android OS and flashing process including Odin, Hiem. and CWM. I'm seeking developer assistance because I am completely inept at code development.
The device that we're working with is a non-production (not relied upon for daily use) and I have no problem leaving it running with a logcat on it, or flashing any ROM you would ask for troubleshooting purposes. That said, the goal is to get the stable CM10 running without reboots or lockups.
Thank you in advance for your time and assistance.
--ChipSharp(DotCom)
chipsharpdotcom said:
I am posting here because I haven't made the requisite 10 posts to get access to post to the development forum. Is there a developer that would be willing to help me here?
Wanted:
Dev assistance with a persistent sleep-lock and/or full-charge lock issue experienced with nearly all non-stock roms on a Samsung i897 with a fresh flash of CM 10. (CM 10 is not the relevant detail, this issue has happened with every non-stock-based rom based on anything newer than and including GB. (so GB/ICS/JB suffer this issue)
What are we calling sleep-lock?
Sleep-lock in this case is being defined as a spontaneous shutdown, lockup (requiring removal of battery to restart), or spontaneous restart of the Android OS. I understand that these three results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to be randomly happening when the phone is in a sleeping state.
What are we calling full-charge lock?
Full-Charge lock in this case is being defined as a spontaneous shutdown or lockup (requiring removal of battery to restart; I do not seem to suffer spontaneous restarts while on the charger). I understand that these two results may or may not be the product of the same root cause (in fact they're probably not) but I'm throwing them in the same bucket because they seem to all happen when the device is on the charger, but most often when the phone reaches or is near a full charge.
Troubleshooting done to date:
I have tried various ROMs over a long period of time, some were better than others, but they were all victims of this behavior. It doesn't seem to be device-specific (read as hardware) related but ever since DarkyRom that I tried shortly after I got this device a couple years ago, I have had this behavior. Stock ROMs do not suffer this behavior.
Who are you working with?
I am a Sr. Technical Team Leader for a Fortune 1000 VoIP software company and am well versed in troubleshooting methodology. I am somewhat newbish in the ways of logcat so I would ask for a little patience there, but am well versed in Windows, Linux, and many parts of the Android OS and flashing process including Odin, Hiem. and CWM. I'm seeking developer assistance because I am completely inept at code development.
The device that we're working with is a non-production (not relied upon for daily use) and I have no problem leaving it running with a logcat on it, or flashing any ROM you would ask for troubleshooting purposes. That said, the goal is to get the stable CM10 running without reboots or lockups.
Thank you in advance for your time and assistance.
--ChipSharp(DotCom)
Click to expand...
Click to collapse
There are many things that can cause what we call SoD (sleep of death). First off, if you have deep idle checked on, remove that (in your ROM options).
What are the changes/mods you made after flashing CM10 (assuming stable version)?
Do you OC/UV?
And finaly, after checking for those things, there's a possible fix. It seems to have work on those who don't have a hardware issue, flashing I9000 bootloaders. The link in my sig guides you through it for the I897. (I9000 being the international version of the captivate)
If you end up going that route, I would do a clean flash. So flash stock software (KK4 no BLs) through Odin or Heimdall, flash the BLs, flash corn kernel to get root and finally flash CM10.
There are no real fix if it's a hardware issue that I'm aware of but hopefully it isn't. Also, I know you want to run CM10 on it but some people reported that running Mosaic 9 fixed their SoD problem. (It is the last I9000 ported ROM)
BWolf56 said:
There are many things that can cause what we call SoD (sleep of death). First off, if you have deep idle checked on, remove that (in your ROM options).
What are the changes/mods you made after flashing CM10 (assuming stable version)?
Do you OC/UV?
And finaly, after checking for those things, there's a possible fix. It seems to have work on those who don't have a hardware issue, flashing I9000 bootloaders. The link in my sig guides you through it for the I897. (I9000 being the international version of the captivate)
If you end up going that route, I would do a clean flash. So flash stock software (KK4 no BLs) through Odin or Heimdall, flash the BLs, flash corn kernel to get root and finally flash CM10.
There are no real fix if it's a hardware issue that I'm aware of but hopefully it isn't. Also, I know you want to run CM10 on it but some people reported that running Mosaic 9 fixed their SoD problem. (It is the last I9000 ported ROM)
Click to expand...
Click to collapse
Thanks for this information. I have read most of this information before, but I appreciate the info nonetheless.
Post install I don't do any customization in terms of OC/UV. So I'm fairly certain that's not it.
I'll run through what you've suggested here in order and see what I get. The specific order is the part that I've found unique. It may take a couple days to get back to you as my test cases involve a couple of charges/discharges, some "normal use" cases etc. I'll let you know my results.
Thank you again for your willingness to help. I'd like to maintain the usefullness of this device and I appreciate your assistance to that end.
--ChipSharp(DotCom)
chipsharpdotcom said:
Thanks for this information. I have read most of this information before, but I appreciate the info nonetheless.
Post install I don't do any customization in terms of OC/UV. So I'm fairly certain that's not it.
I'll run through what you've suggested here in order and see what I get. The specific order is the part that I've found unique. It may take a couple days to get back to you as my test cases involve a couple of charges/discharges, some "normal use" cases etc. I'll let you know my results.
Thank you again for your willingness to help. I'd like to maintain the usefullness of this device and I appreciate your assistance to that end.
--ChipSharp(DotCom)
Click to expand...
Click to collapse
If you tried the other stuff and the I9000 bootloaders don't work, chances are that it's a hardware problem.
BWolf56 said:
If you tried the other stuff and the I9000 bootloaders don't work, chances are that it's a hardware problem.
Click to expand...
Click to collapse
I'm going to give it a try right now....I'm less inclined to buy into the hardware theory though without having these problems on the Stock ROM.
chipsharpdotcom said:
I'm going to give it a try right now....I'm less inclined to buy into the hardware theory though without having these problems on the Stock ROM.
Click to expand...
Click to collapse
Try upping the voltage/minimum clock speed. That worked for me when I was running cm9 with the glitch kernel.
Sent from my Apple IIe
billyjed said:
Try upping the voltage/minimum clock speed. That worked for me when I was running cm9 with the glitch kernel.
Sent from my Apple IIe
Click to expand...
Click to collapse
Thanks for the tip...I'll try that if all of the above doesn't work. At this point, I'm all flashed up and running test cases.
So none of the suggestions here (unfortunately) provided me any different results. That said, I have discovered a couple of different variables that may play a part in this.
1.) This issue only seems to come up when I have the device plugged into power only, not when I have it plugged into a computer.
2.) I think this may be related to trying to sleep while still maintaining the clock application. It seems that when I see this most often, it is when I am plugged into the wall, and I have an alarm set. I was able to be plugged into the wall overnight last week and have no problems without the alarm set, but when I set the alarm, I had the sleep-lock issue (and moreover as you would expect, my alarm did not sound).
Again, I have none of these problems with the stock ROM. I'm going to continue to test on this and hack around on it to see if I can hunt this down, but my concern is that the very things that allow me to troubleshoot are the same things that keep the device from reproducing the error.
You can subscribe to this thread if you care to continue watching the progress, or if you have any similar experiences or potential solutions, but this is one of those issues that if I don't find the root cause, it's going to drive me bat-s%#$-f&@!#%-crazy. I'm aware that even if I get to the root cause I will likely never see a fix for the problem being that this device is so old, but this is caught in my teeth now, and I'm going to have a hard time letting it go.
As always thank you all for your assistance and participation.
chipsharpdotcom said:
So none of the suggestions here (unfortunately) provided me any different results. That said, I have discovered a couple of different variables that may play a part in this.
1.) This issue only seems to come up when I have the device plugged into power only, not when I have it plugged into a computer.
2.) I think this may be related to trying to sleep while still maintaining the clock application. It seems that when I see this most often, it is when I am plugged into the wall, and I have an alarm set. I was able to be plugged into the wall overnight last week and have no problems without the alarm set, but when I set the alarm, I had the sleep-lock issue (and moreover as you would expect, my alarm did not sound).
Again, I have none of these problems with the stock ROM. I'm going to continue to test on this and hack around on it to see if I can hunt this down, but my concern is that the very things that allow me to troubleshoot are the same things that keep the device from reproducing the error.
You can subscribe to this thread if you care to continue watching the progress, or if you have any similar experiences or potential solutions, but this is one of those issues that if I don't find the root cause, it's going to drive me bat-s%#$-f&@!#%-crazy. I'm aware that even if I get to the root cause I will likely never see a fix for the problem being that this device is so old, but this is caught in my teeth now, and I'm going to have a hard time letting it go.
As always thank you all for your assistance and participation.
Click to expand...
Click to collapse
Have you tried it with a different clock app? I mean, if I understand this correctly, it seems to be narrowed down to your current clock apk, which is different than the stock GB one. So I would suggest freezing (or unistalling) your current one with Tibu and trying a different one.
That's actually my next step.
I'm not sure it's accurate to say that I have it narrowed down to the clock app, I simply noted that I reproduced the issue on wall power and with the alarm set. That could all be coincidence. I need to try to reproduce those scenarios more reliably and in a more controlled method.
Do you know of an app I could install that would cause my battery to discharge fairly quickly? It would speed up my troubleshooting.
chipsharpdotcom said:
That's actually my next step.
I'm not sure it's accurate to say that I have it narrowed down to the clock app, I simply noted that I reproduced the issue on wall power and with the alarm set. That could all be coincidence. I need to try to reproduce those scenarios more reliably and in a more controlled method.
Do you know of an app I could install that would cause my battery to discharge fairly quickly? It would speed up my troubleshooting.
Click to expand...
Click to collapse
Haha first time I ever get that question but leaving your camera on should do the job (or video playing)
Hello everybody.
I just got myself an P880 a few days ago. All in all, I am rather content, but there is something that bothers me sorely: the lock screen lag. There is a delay of about 3 seconds between pressing the power button and the screen coming to life. I've had this on stock ICS, stock JB and now on CM 10.1.2. I tried different lock screen and also no lock screens - all to no avail. I even checked another P880 (it was running stock ICS) and it was the same story there. Yet I can't really find anyone else reporting this problem, so maybe I'm doing something wrong? I don't know!
I took a video of my old SGS and the P880 next to each other: youtu.be/RyrgdiLGhoU
All hints and suggestions are appreciated!
lukedoe said:
Hello everybody.
I just got myself an P880 a few days ago. All in all, I am rather content, but there is something that bothers me sorely: the lock screen lag. There is a delay of about 3 seconds between pressing the power button and the screen coming to life. I've had this on stock ICS, stock JB and now on CM 10.1.2. I tried different lock screen and also no lock screens - all to no avail. I even checked another P880 (it was running stock ICS) and it was the same story there. Yet I can't really find anyone else reporting this problem, so maybe I'm doing something wrong? I don't know!
I took a video of my old SGS and the P880 next to each other: youtu.be/RyrgdiLGhoU
All hints and suggestions are appreciated!
Click to expand...
Click to collapse
There is no real answer to this question, my 4x is fine, perhaps half a second delay from pressing the lock button to seeing my lockscreen.
However there are many contributing factors to what could cause this, for example the phone may be locking to a certain frequency too low and it's finding it hard to come back from, if you lock the screen whilst on a RAM hogging app it will also lag, background processes will also slow it down, for example, always clear your recent apps (Long hold Home button) and clear them, if you have root access (jb only i think) Then try using greenify and freezing background apps you dont want either running/receiving notifications from.
If you are still on stock you may want to remove bloatware (apps you don't use) Which will also be churning away in the background slowing down your phone, make sure in your settings you will also have that there is no delay and that lock button INSTANTLY locks the phone and then try again and post back if it's helped or not, if not then we should start looking at other factors it could be, perhaps a week tegra variant and we should look into a custom kernel and raising the minimum frequency a tad and seeing whether or not that will help.
my device has same problem and it's very annoying
hassan1990 said:
my device has same problem and it's very annoying
Click to expand...
Click to collapse
What was the point of this post? Contribute to troubleshooting the problem if you can, but simply posting a "Me too" is no use anyone.
penguin449 said:
However there are many contributing factors to what could cause this, for example the phone may be locking to a certain frequency too low and it's finding it hard to come back from, if you lock the screen whilst on a RAM hogging app it will also lag, background processes will also slow it down, for example, always clear your recent apps (Long hold Home button) and clear them, if you have root access (jb only i think) Then try using greenify and freezing background apps you dont want either running/receiving notifications from.
Click to expand...
Click to collapse
I maybe should have mentioned that it isn't every time that there is this delay, maybe every second time on average - sometimes more often, sometimes not at all.
Having had this problem with different firmwares and also with a cleanly wiped phone, even with a fresh install of CM when I hadn't even flashed the Gapps package, makes me think that this very likely isn'ta bloatware issue.
Changing the CPU governor to performance had no effect either.
hassan1990 said:
my device has same problem and it's very annoying
Click to expand...
Click to collapse
Edit: Never mind what i had written here, I was confused. But yeah, I welcome any information that helps us close in on the problem.
SimonTS said:
What was the point of this post? Contribute to troubleshooting the problem if you can, but simply posting a "Me too" is no use anyone.
Click to expand...
Click to collapse
Equally this post was just as useless! Try what i mentioned above and let us know how it is afterwards, THEN ask other questions
penguin449 said:
Equally this post was just as useless! Try what i mentioned above and let us know how it is afterwards, THEN ask other questions
Click to expand...
Click to collapse
I don't have this problem or I would assist in trying to troubleshoot it. You may not have noticed but I don't tend to ask questions because I am very good at reading and most things have been discussed and answered.
Hello all,
I recently started installing lots of ROMs and Kernels for my G800f. I quickly noticed I always had common issues with those.. I don't know if I"m the only one, I searched a lot for answers without success so maybe you can help me Here are the problems:
-The phone heats up for no apparent reasons, especially the top right corner of the screen. (being on whatsapp didn't heat my phone that much when I was on stock ROM) (This happens even before installing third party apps). I read on some forums it could have something to do with NFC but the fixes never worked in my case.
-The battery drains so quickly (I guess this has something to do with the previous) (I tried to clean up my battery hardware ports etc...) (This happens even before installing third party apps)
-Big camera issues : on snapchat, when I focus by tapping, everyhting slows down and the app becomes unuseable. On the camera app, I get an "Camera disconnected" error randomly. I saw on the forums that this is a problem with the media servers but please tell me what you think )
I can't just stay on my touchwiz stock rom because it's tooo slooooow to handle stuff like pokemon go (in CM13, pokemon go runs lightning fast). Everything is just better on a aosp custom rom, but It's impossible for me to have my phone heat and drain my battery while not having a reliable camera... I hope you will help me find a solution!!
Thank you in advance,
Netapy
Do you have the same problems with stock ROMs afters a factory reset? It looks like a hardware problem, maybe dying battery, of you still have these issues then probably it's the cause. If not it's software related.
Hi there,
I have a C6903 with 16GB of storage. Baseband 8974-AAAAANAZQ-10270045-39. It ran fine under CM12.1 from last year. I recently updated to a CM12.1 nightly from August of this year. After that I started having problems with random crashes.
The phone would either freeze during operating, not responding to any input. I had to hard reset by holding the power button for a long time. This shuts the phone down. Then I start it and it boots up. Or the crash happens, when I am not using the phone, resulting in a black screen and an unresponsive phone. The fix is the same, shutting the phone down with a long press on the power button and then starting it up.
I switched from CM12.1 to AOSP Jaguar LP 5.1.1 from August (I haven't updated to September yet). I was crash free for three weeks, but now I am back with the same crashes. I found four crash logs in /data/anr, but I can't make much sense of them. I have them attached to the post.
The change in behavior when I install a new rom makes me think this could be software related, but getting the same crashes with two very different roms makes it look like a hardware issue.
What do you guys think? I don't want to go back to stock for testing, because I value privacy a lot and XPrivacy is so much work to set up right, IMHO. I like the privacy managers included with Jaguar or CM12.1 a lot. They are so much easier to use. But if I have to, I will go back to stock. Any other ideas? Can anyone interpret the crash logs? Is there anything useful there? Should I test something else?
Please help. Thank you for reading this post.
SpGG said:
Hi there,
I have a C6903 with 16GB of storage. Baseband 8974-AAAAANAZQ-10270045-39. It ran fine under CM12.1 from last year. I recently updated to a CM12.1 nightly from August of this year. After that I started having problems with random crashes.
The phone would either freeze during operating, not responding to any input. I had to hard reset by holding the power button for a long time. This shuts the phone down. Then I start it and it boots up. Or the crash happens, when I am not using the phone, resulting in a black screen and an unresponsive phone. The fix is the same, shutting the phone down with a long press on the power button and then starting it up.
I switched from CM12.1 to AOSP Jaguar LP 5.1.1 from August (I haven't updated to September yet). I was crash free for three weeks, but now I am back with the same crashes. I found four crash logs in /data/anr, but I can't make much sense of them. I have them attached to the post.
The change in behavior when I install a new rom makes me think this could be software related, but getting the same crashes with two very different roms makes it look like a hardware issue.
What do you guys think? I don't want to go back to stock for testing, because I value privacy a lot and XPrivacy is so much work to set up right, IMHO. I like the privacy managers included with Jaguar or CM12.1 a lot. They are so much easier to use. But if I have to, I will go back to stock. Any other ideas? Can anyone interpret the crash logs? Is there anything useful there? Should I test something else?
Please help. Thank you for reading this post.
Click to expand...
Click to collapse
Your attachments show only general info about OS, but nothing related to freezing/crashes. Based on the fact that you were problem free on Jaguar for about 3 weeks, you might have the following:
You installed an app or mode that's causing this; you might have set up something in Kernel Adiutor (such as cpu voltage or what have you) that's causing problems; you might have restricted something in wakeblocker or an app like Xprivacy or any other Xposed module. Just think of what you did at the end of the 3-week-period. In Kernel Adiutor, untick apply on boot and reboot, so that default values could be loaded. If that doesn't help, disable wakeblocker...
optimumpro said:
Your attachments show only general info about OS, but nothing related to freezing/crashes. Based on the fact that you were problem free on Jaguar for about 3 weeks, you might have the following:
You installed an app or mode that's causing this; you might have set up something in Kernel Adiutor (such as cpu voltage or what have you) that's causing problems; you might have restricted something in wakeblocker or an app like Xprivacy or any other Xposed module. Just think of what you did at the end of the 3-week-period. In Kernel Adiutor, untick apply on boot and reboot, so that default values could be loaded. If that doesn't help, disable wakeblocker...
Click to expand...
Click to collapse
I didn't change anything. Same thing when I went for a new nightly of cm12.1 I did nothing out of the ordinary. Since I did not have new problems since the above mentioned, I didn't delve any further. Today I had another, interesting issue. No one was able to call the phone and I wasn't able to call out, even though the network showed up as fine with full bars. This lasted for several hours. I went into flight mode and back out of flight mode and the issue was fixed. Several SMS arrived about calls missed. And again, I have no idea if this was caused by the hardware, an issue with the software or even the network.
And that is the frustrating thing: How can I find out who the culprit is? Are there good system crash diagnostic tools? Because so far I haven't seen anything.