CM7DX2 WIFI and Dialer fix/mod!
If you are having problems with WIFI staying connected... Read this!
If you are having problems with the Dialer dialing out 30-120 (or more) seconds after hitting the call button... Read this!
DISCLAIMER: This have ONLY been tested to work on CM7DX2! Also, as with any of my mods or fixes, you are doing this at your own risk. I cannot and will not be held liable or responsible for what YOU choose to do to your phone.
The reason I chose to implement the cron instead of just running scripts or something like that was because I didn't want anyone to have to download one or more apps to do this, and I also wanted to keep the overhead as low as possible.
Now, on to the good stuff!
If you are impatient, download the flashable zip and flash it in BSR. No need to wipe data, cache, or dalvik-cache, although wiping cache and dalvik-cache can't/won't hurt.
In addition to flashing this, you also, MUST enable WIFI Never Sleep! Goto Menu -> Settings -> Wireless & Networks -> Wi-Fi Settings -> Menu -> Advanced -> Wi-Fi- Sleep Policy, then tape Never and hit the back button 4 times!
Background:
After test driving CM7DX2 for DragonZKiller, I had turned it into my daily driver. Everyone who has tried it knows that it is a very stable ROM and works very well. Anyhow, after having it as my daily driver for about 2 weeks, I noticed, on some occasions, it would take 30-120 (or more) seconds to actually dial the call AFTER I hit the Call button, or worse, it would FC on me. Over time, this became very frustrating to me because I could reboot my phone and my outgoing calls would be sent practically the moment I tapped the Call button. This was frustrating to no end because I couldn't nail down what or why it was doing it.
I then started keeping a log of my use of my phone and my observations (yes, true engineer here). I noticed after about 60 minutes of idle time, me not futzing with my phone, the dialer lag (or FC) would appear. That got me to thinking that something was killing the dialer, so I started looking at the CyanogenMod settings as I remembered there was a setting to "Purge Assests" or something like that... Because I set the setting weeks earlier when I was playing with the phone...
I found the setting in Menu -> Settings -> CyanogenMod Settings -> Performance Settings -> Allow Purging of Assets. I removed the check mark next to it and, to be safe, rebooted the phone.
Again, I went back to logging my usage on my phone... Again, after about 60 minutes of idle time, the dialer lag (or FC) would be back.
This has me very frustrated now, because, silly me, I would like my phone to act like a phone when I need it to be a phone... And, not just a development tool, or a device to play Angry Birds, or... You get the idea.
I started poking around to see what was happening to the dialer, when I remembered that ZepplinRox had a thread somewhere pertaining to renicing an app... [FIX] Bulletproof Background Apps! Hot damn! I think this is what I need to look at! Now to find the dialer...
This is easier said then done. I thought I would be a smart ass and just type:
Code:
ps | grep dialer
Well, that didn't work. Okay, then I tried:
Code:
ps | grep Dialer
and various permutations of dialer. Still can't find any process called dialer! Damn it! WTF? I then remembered taking with DZK during the development of the CM7DX2 ROM and he was saying something about the phone/dialer not working... Wait.... Phone?!?!?! Okay, so back to ps..
Code:
ps | grep phone
radio 2179 2037 147608 25472 ffffffff afd0c7cc S com.android.phone
BINGO! Pay dirt! Well, almost. So, I found the "dailer" process... com.android.phone. Great! Now what? Then I remembered DZK saying something about rild... And there was a problem there that was linked to the radio/phone/dialer. Wait, radio?!?!?! Rild?!?!?!?! WTF now? Now I have to look at renicing two things? Great... *sigh*
So, I started looking at ZepplinRox's scripts to renice the dialer, phone, rild, radio... What ever! I was trying to figure out a consistent way to run the renice command at a specific interval... Wait, ZepplinRox is using init.d to run his scripts and it has a sleep command in the script so it sleeps for that long then restarts the command. That is good, but what keeps the android scheduler from killing the script... Android Scheduler?!?!?! Wait... Hold on a sec! I think that is where the problem lies! So, off to do more research!
So within adb, I started running htop to watch the nice level on the com.android.phone process, and in another adb session, I reniced the process com.android.phone. After about 35-40 minutes, I noticed the nice level on the com.android.phone process was being elevated. Then at about 60 minutes, when I tried to use the dialer, it lagged. Ah ha! Now, how do I renice the dialer so that is sticks and works.
I understand cron in Linux, and thought about enabling the cron on Android. I found this blog by imoseyon: cron on android is awesome which pointed me in the right direction.
The Solution:
After much work, I finally was able to have cron running on my DX2!
I created a flashable zip that would install the cron files and enable it on boot. I then created a folder in /data called scripts and put my cron called script (com_android_phone.sh) in there. I set up the cron job to run every 30 minutes. this script doesn't actually renice the process, it renices ALL processes owned by the user radio, which is both com.android.phone and /system/bin/rild. That way, they both stay at a low enough nice level to stay active.
I also enabled logging on the crond and logging for the script which logs to /data/scripts/log/com_android_phone.log. Then, I thought that the script's log file (which logs the renice every 30 minutes) would, over time, fill up all available space in /data. I then created a second cron job that would delete this log file every Sunday morning at 5:00AM.
Myself, litetaker, lesismore, and a couple of others have been testing this and the WIFI cron job and it seems to be working.
WIFI cron job:
So, then I wondered if the Android Scheduler could possibly be affecting WIFI in sleep mode as well. I found there is a user WIFI that owns the wifi process /system/bin/wpa_supplicant, and the wpa_supplicant process is present with both open and secured access points, and is only running when WIFI is connected.
So, I created a cron job to renice all processes owned by wifi and have that one running every 15 minutes because I noticed that the disconnects seem to happen after 15-30 minutes of idle time. (In my original thread, I stated that I was not having WIFI connection issues... This is not entirely true, I use tasker to activate/deactivate several wifi situational profiles, so I wasn't seeing it.) This script also writes a log to /data/scripts/log/wpa_supplicant_renice.log every time it runs so I have that script being deleted every Sunday morning at 5:00AM as well.
I sincerely hope this mod helps everyone that has WIFI issues on CM7DX2. This mod MIGHT work on other DX2 ROMs, but I specifically did not test other ROMs as the problem was primarily in CM7DX2.
If you know what you are doing, feel free to open up the zip and port to cron to other ROMs. Also, make sure you set the correct permissions on and scripts you create and on the root "crontab" are all correct, to avoid issues with the scripts not running.
DOWNLOAD:
cron_scheduler_signed.zip
If you have issues, please note them in this thread, or better yet, come to IRC at http://webchat.freenode.net and join channel #cm7dx2. I'm usually in there. Enjoy!
Ciao!
Reserved for future use.
Good to see someone made a fix for this. I dont have wifi problems since I use llama location profiles which keeps my wifi on based on my home location. But I may be flashing this to my girlfriends DX2 sometime soon because she's always complaining about this. I will report back on how hers does when I do and let her use it for a while.
jsgraphicart said:
Good to see someone made a fix for this. I dont have wifi problems since I use llama location profiles which keeps my wifi on based on my home location. But I may be flashing this to my girlfriends DX2 sometime soon because she's always complaining about this. I will report back on how hers does when I do and let her use it for a while.
Click to expand...
Click to collapse
Yeah, I use Tasker so I wasn't "seeing" the WIFI problem.
Sounds great! Looking forward to hearing how it goes for her.
Ciao!
Moon Shadow wins the internet today!!
Sent from my MB870 using xda premium
Going to give this a shot. I haven't notice any dialer issues but was having the famous wifi issue. Thanks!
I've had the dialer issue once. Horrid. Will nandy then check this out...
Sent from my MB870 using XDA App
Moon Shadow - NM said:
CM7DX2 WIFI and Dialer fix/mod!
If you are having problems with WIFI staying connected... Read this!
If you are having problems with the Dialer dialing out 30-120 (or more) seconds after hitting the call button... Read this!
DISCLAIMER: This have ONLY been tested to work on CM7DX2! Also, as with any of my mods or fixes, you are doing this at your own risk. I cannot and will not be held liable or responsible for what YOU choose to do to your phone.
The reason I chose to implement the cron instead of just running scripts or something like that was because I didn't want anyone to have to download one or more apps to do this, and I also wanted to keep the overhead as low as possible.
Now, on to the good stuff!
If you are impatient, download the flashable zip and flash it in BSR. No need to wipe data, cache, or dalvik-cache, although wiping cache and dalvik-cache can't/won't hurt.
In addition to flashing this, you also, MUST enable WIFI Never Sleep! Goto Menu -> Settings -> Wireless & Networks -> Wi-Fi Settings -> Menu -> Advanced -> Wi-Fi- Sleep Policy, then tape Never and hit the back button 4 times!
Background:
After test driving CM7DX2 for DragonZKiller, I had turned it into my daily driver. Everyone who has tried it knows that it is a very stable ROM and works very well. Anyhow, after having it as my daily driver for about 2 weeks, I noticed, on some occasions, it would take 30-120 (or more) seconds to actually dial the call AFTER I hit the Call button, or worse, it would FC on me. Over time, this became very frustrating to me because I could reboot my phone and my outgoing calls would be sent practically the moment I tapped the Call button. This was frustrating to no end because I couldn't nail down what or why it was doing it.
I then started keeping a log of my use of my phone and my observations (yes, true engineer here). I noticed after about 60 minutes of idle time, me not futzing with my phone, the dialer lag (or FC) would appear. That got me to thinking that something was killing the dialer, so I started looking at the CyanogenMod settings as I remembered there was a setting to "Purge Assests" or something like that... Because I set the setting weeks earlier when I was playing with the phone...
I found the setting in Menu -> Settings -> CyanogenMod Settings -> Performance Settings -> Allow Purging of Assets. I removed the check mark next to it and, to be safe, rebooted the phone.
Again, I went back to logging my usage on my phone... Again, after about 60 minutes of idle time, the dialer lag (or FC) would be back.
This has me very frustrated now, because, silly me, I would like my phone to act like a phone when I need it to be a phone... And, not just a development tool, or a device to play Angry Birds, or... You get the idea.
I started poking around to see what was happening to the dialer, when I remembered that ZepplinRox had a thread somewhere pertaining to renicing an app... [FIX] Bulletproof Background Apps! Hot damn! I think this is what I need to look at! Now to find the dialer...
This is easier said then done. I thought I would be a smart ass and just type:
Code:
ps | grep dialer
Well, that didn't work. Okay, then I tried:
Code:
ps | grep Dialer
and various permutations of dialer. Still can't find any process called dialer! Damn it! WTF? I then remembered taking with DZK during the development of the CM7DX2 ROM and he was saying something about the phone/dialer not working... Wait.... Phone?!?!?! Okay, so back to ps..
Code:
ps | grep phone
radio 2179 2037 147608 25472 ffffffff afd0c7cc S com.android.phone
BINGO! Pay dirt! Well, almost. So, I found the "dailer" process... com.android.phone. Great! Now what? Then I remembered DZK saying something about rild... And there was a problem there that was linked to the radio/phone/dialer. Wait, radio?!?!?! Rild?!?!?!?! WTF now? Now I have to look at renicing two things? Great... *sigh*
So, I started looking at ZepplinRox's scripts to renice the dialer, phone, rild, radio... What ever! I was trying to figure out a consistent way to run the renice command at a specific interval... Wait, ZepplinRox is using init.d to run his scripts and it has a sleep command in the script so it sleeps for that long then restarts the command. That is good, but what keeps the android scheduler from killing the script... Android Scheduler?!?!?! Wait... Hold on a sec! I think that is where the problem lies! So, off to do more research!
So within adb, I started running htop to watch the nice level on the com.android.phone process, and in another adb session, I reniced the process com.android.phone. After about 35-40 minutes, I noticed the nice level on the com.android.phone process was being elevated. Then at about 60 minutes, when I tried to use the dialer, it lagged. Ah ha! Now, how do I renice the dialer so that is sticks and works.
I understand cron in Linux, and thought about enabling the cron on Android. I found this blog by imoseyon: cron on android is awesome which pointed me in the right direction.
The Solution:
After much work, I finally was able to have cron running on my DX2!
I created a flashable zip that would install the cron files and enable it on boot. I then created a folder in /data called scripts and put my cron called script (com_android_phone.sh) in there. I set up the cron job to run every 30 minutes. this script doesn't actually renice the process, it renices ALL processes owned by the user radio, which is both com.android.phone and /system/bin/rild. That way, they both stay at a low enough nice level to stay active.
I also enabled logging on the crond and logging for the script which logs to /data/scripts/log/com_android_phone.log. Then, I thought that the script's log file (which logs the renice every 30 minutes) would, over time, fill up all available space in /data. I then created a second cron job that would delete this log file every Sunday morning at 5:00AM.
Myself, litetaker, lesismore, and a couple of others have been testing this and the WIFI cron job and it seems to be working.
WIFI cron job:
So, then I wondered if the Android Scheduler could possibly be affecting WIFI in sleep mode as well. I found there is a user WIFI that owns the wifi process /system/bin/wpa_supplicant, and the wpa_supplicant process is present with both open and secured access points, and is only running when WIFI is connected.
So, I created a cron job to renice all processes owned by wifi and have that one running every 15 minutes because I noticed that the disconnects seem to happen after 15-30 minutes of idle time. (In my original thread, I stated that I was not having WIFI connection issues... This is not entirely true, I use tasker to activate/deactivate several wifi situational profiles, so I wasn't seeing it.) This script also writes a log to /data/scripts/log/wpa_supplicant_renice.log every time it runs so I have that script being deleted every Sunday morning at 5:00AM as well.
I sincerely hope this mod helps everyone that has WIFI issues on CM7DX2. This mod MIGHT work on other DX2 ROMs, but I specifically did not test other ROMs as the problem was primarily in CM7DX2.
If you know what you are doing, feel free to open up the zip and port to cron to other ROMs. Also, make sure you set the correct permissions on and scripts you create and on the root "crontab" are all correct, to avoid issues with the scripts not running.
DOWNLOAD:
cron_scheduler_signed.zip
If you have issues, please note them in this thread, or better yet, come to IRC at http://webchat.freenode.net and join channel #cm7dx2. I'm usually in there. Enjoy!
Ciao!
Click to expand...
Click to collapse
I used to have wifi issues, BUT since the last SBF around two weeks ago I have had no problems...I have not altered any crucial settings nor installed any mods/scripts... Thank you Moon Shadow, your continued effort is appreciated!
SMILE It's Not Illegal Yet
here is a alt host for when original goes down
Don't worry Dev it has a dl counter: Download CM7DX2 WIFI and Dialer fix/mod!
It doesn't seem to be fixing my wifi. Just unlocked my phone from sitting for about an hour and wifi was disabled again. Toggling wifi off/on didn't fix, have to reboot. As far as the dialer, I couldn't tell you if it worked or not as I never stumbled upon this problem.
KiaraTheDragon said:
here is a alt host for when original goes down
Don't worry Dev it has a dl counter: Download CM7DX2 WIFI and Dialer fix/mod!
Click to expand...
Click to collapse
Thanks, however, I host my files on my own website. I appreciate it, though!
Ciao!
RyanThaDude said:
It doesn't seem to be fixing my wifi. Just unlocked my phone from sitting for about an hour and wifi was disabled again. Toggling wifi off/on didn't fix, have to reboot. As far as the dialer, I couldn't tell you if it worked or not as I never stumbled upon this problem.
Click to expand...
Click to collapse
Hrm... :-/ That is interesting. Is your WIFI settings set to Never Sleep?
Ciao!
I'll be eagerly watching this thread for people's results/impressions. I just SBF'd my X2 to sell it, but if this means I can run CM7 without wifi issues, I might reconsider and keep 'er after all.
Moon Shadow - NM said:
Hrm... :-/ That is interesting. Is your WIFI settings set to Never Sleep?
Ciao!
Click to expand...
Click to collapse
That I do. Restarted a few times and let set for 1/2 hour. Just unlocked my phone from the nap and wifi was once again disabled.
RyanThaDude said:
That I do. Restarted a few times and let set for 1/2 hour. Just unlocked my phone from the nap and wifi was once again disabled.
Click to expand...
Click to collapse
Okay, I hate to ask this, but in order to troubleshoot this farther, I am going to ask you to SBF back to do the following: (If you aren't able or willing to do this, I understand, but I will be very limited as to the support I can give.)
1. SBF back to stock.
2. Perform a Factory Reset and wipe dalvik-cache.
3. Activate (if necessary).
4. Root.
5. Install the ORIGINAL BSR.
6. Boot into the BSR.
7. Flash CM7DX2.
8. Flash the CM7 gapps.
9. Perform a Factory Reset and wipe dalvik-cache.
10. Make sure WIFI is set to Never Sleep. (See OP.)
11. Reboot and install the CM7 BSR.
12. Boot into BSR and flash the cron scheduler.
13. Boot normal and test.
14. After about 4 hours, PM me with these log files (in a zip file): /data/cron/log/crond.log, /data/scripts/log/com_android_phone.log, and /data/scripts/log/wpa_supplicant_renice.log.
15. Also include a "logcat *:E *:W *:I". I'm hoping you have adb installed and are familiar with it. If so, use: "adb logcat *:E *:W *:I > logcat.log" and put that in the zip file as well.
I understand this is a PITA, but, again, it's really the best way for me to try to see what is happening with your phone.
Also, if you are using Titanium Backup, only restore your apps and their data, DO NOT restore any system apps or data (the ones in green or red).
Thanks.
Ciao!
I tried flashing it and it ended up aborting the flash due to an error. I'd have to try again to get the exact error but it was something to the effect E: couldn't mount whatever the zips name was. I downloaded it again and got the same error so rather than fighting it, I installed it manually. I take it it's working as I see the entries in the logs.
Anyway, I put the phone down a couple hours ago and just checked now and wifi was still active and connected. Might be too early to say for sure but so far, so good for me. I'll give it a day and then post back.
Hopefully I'll be able to do this later tonight.
---------- Post added at 06:14 PM ---------- Previous post was at 06:11 PM ----------
I just pulled the crond.log and this is what's in it:
Code:
rond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
Does this help anything?
RyanThaDude said:
Hopefully I'll be able to do this later tonight.
---------- Post added at 06:14 PM ---------- Previous post was at 06:11 PM ----------
I just pulled the crond.log and this is what's in it:
Code:
rond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
crond: user root: parse error at 7
Does this help anything?
Click to expand...
Click to collapse
Yeah, that does. That means it's not reading something correctly.
Check the permissions on /data/scripts/com_android_phone.sh and /data/scripts/wpa_supplication_renice.sh. They both should be 755 (-rwxr-xr-x). If not, issue "chmod 755 " (put each file name where is).
Also check /data/cron/root and make sure that is 644 (-rw-r--r--).
Also, check the time stamp on the log file. That will tell you when it was last updated.
Thanks.
Just removed wifi keep alive, rebooted, put the phone in my pocket for ten minutes and wham dead wifi. Just flashed this zip and will report back.
By the way on boot after flashing this I got the triangle data icon and no service for about 30 seconds, then it came back, don't be scared!
Thanks so far Moonshadow!
Sent from my MB870 using XDA App
Haven't been having the wifi issue which I believe is because I use JD Ultimate with wifi preferred set to on. This extends the time the phone allows for a wifi connection to be made before turning on 3g. I have been having problems with the dialer recently and will let you know if this takes care of that issue. And as always thanks for the work and the great lesson regarding the problem and fix...a very interesting read.
Sent from my MB870 using Tapatalk
Moon Shadow - NM said:
Yeah, that does. That means it's not reading something correctly.
Check the permissions on /data/scripts/com_android_phone.sh and /data/scripts/wpa_supplication_renice.sh. They both should be 755 (-rwxr-xr-x). If not, issue "chmod 755 " (put each file name where is).
Also check /data/cron/root and make sure that is 644 (-rw-r--r--).
Also, check the time stamp on the log file. That will tell you when it was last updated.
Thanks.
Click to expand...
Click to collapse
I checked all three script files and permissions were 755, and the root file was 644, and I'm getting the same errors as Ryan in the crond log.
Not getting any updates or modification to the one log file in /data/scripts/log/dhcpd_renice.log. Mod date on that file is 2008-8-1 07:00. Modify date on crond log is today 10:57pm.
The other logs have updates, and my wireless hasn't ever been this stable on cm7. Never had any problem with the dialer, but it's still working. So hurray there!!!
So what's up with the dhcpd script, anything I can look at further to get at why it's not logging/failing in the crond log?
Sent from my MB870 using XDA App
Related
Downloaded the new Google Maps update praying it would fix the FC's no dice. Are all Cyanogen ROM users having this problem? Having one more problem, my phone will notify me of E-mail; but when I go to my email it isn't showing my latest email. I have to refresh it to have it show up. Not Gmail but my Comcast account? Any help would be most appreciated.
Thanks
Just FYI to anyone with this same problem, I just rooted my eris for the first time 2 days ago. Maps nav was freezing on my non-rooted 2.1 in the same exact way. Something seems to be wrong with maps in general...but I'm not sure if it's just with the eris. But I do know that maps worked within the 3-4 previous updates. Can anyone provide a way to "downgrade" maps to an update that is a little older? I think this might provide everyone with a temp solution until they provide us with an update that works with the eris...just an idea
i think i read somewhere that some people tried to downgrade maps but it still FC'd on them...
Macrodroid just posted that he had success with downgrading his maps, check his EverVolv or Macrom thread.
Sent from my MacRom MR7 using Tapatalk
The only issue I've had is when i received a call during navigation. While it was rerouting, I received a FC. Starting it again and didn't have any issues.
Downloaded the apk that Mac posted last night. I drive 50 miles to work every morning. It force closed and rebooted my phone after 20 minutes. This occurs while driving down the interstate (not while making lots of turns). Going on a trip soon, might just have to download Zach's xtr rom. I've used it in the past month and navigation worked fine.
If anybody finds a way to deterministically crash the Eris using Maps/Nav, let us know; it would be very helpful for testing purposes. Note that you don't need to be driving around for a crash to occur (although it is conceivable that will help cause the bug to occur) - the Nav app will cause a crash sometimes with your Eris just sitting motionless on a desk.
I've observed a couple of full Android restarts so far (phone connected to the PC with Nav running and "logcat" running), and so far the things I've noticed are:
- the problem is hard to reproduce. Sometimes a crash will happen in 10 minutes, sometimes in 1 hour... sometimes not after several hours. (This is the the problem with "I tried Nav for 30 minutes and everything seemed fine" reports - it isn't easy to prove that a specific fix has actually worked, 'cuz it might be hours before the bug rears it's ugly head).
- All the cases where I've seen an (Android) crash so far (v5713/gapps 20110613), I saw a SIGSEGV (null pointer fault) of the "system_server" process - the same "null string passed to strlen() via libdvm.so" error that has been previously noted elsewhere (e.g. in Tazz' thread and some time ago in other CM7 ROMs (Hero CDMA) ). This obviously will cause a full Android layer restart, but strictly speaking is not exactly a Maps/Nav issue... but probably something about the way that the new Maps/Nav behaves that makes the occurrence of this bug favorable.
I'm still looking at this, but not making much progress. The only thing that I (seem) to have noticed is that turning on checkJNI in the zygote causes Nav to hang (ANR) so that Android offers a FC to the user. I suppose this could be a completely separate bug - the main thread seems to hang waiting for something in the GL.
e.g.
Code:
adb shell stop
adb shell setprop dalvik.vm.checkjni true
adb shell start
... then do your testing.
My mothers Eris was experiencing a similar issue as was my TB. a full wipe did the trick for me using the latest available CM versions and gapps for both phones. No issues thus far... fingers crossed.
Rick
bftb0,
Back when I was trying to figure out the Maps/Nav issues, I had requested people get the kernel log of a crash. I posted here what was interesting to me from someone that had posted one and then later decided to look at the source code and follow the routines mentioned. I remember looking it over but don't think I ever posted what I'd found or was thinking and can't find any notes about it right now. Might look into that again to see if the source holds any clues.
MongooseHelix said:
bftb0,
Back when I was trying to figure out the Maps/Nav issues, I had requested people get the kernel log of a crash. I posted here what was interesting to me from someone that had posted one and then later decided to look at the source code and follow the routines mentioned. I remember looking it over but don't think I ever posted what I'd found or was thinking and can't find any notes about it right now. Might look into that again to see if the source holds any clues.
Click to expand...
Click to collapse
I looked at the link you provided - if you thought that somehow the kernel module for WiFi was a source of trouble, you could certainly just move /system/lib/modules/wlan.ko out of the modules folder and reboot (for testing purposes - obviously in the long run you want to have WiFi capability).
My own testing is moving me in a different direction, though. So far, all the Android crashes that I have seen so far have been segfaults of the "system_server" process. I just watched one a couple of minutes ago, using both logcat and strace simultaneously.
The stack trace at the segfault of system_server in the logcat (if it is actually to be believed) looks something like
Code:
strlen() [libc.so] <- segfault here
??? [libdvm.so]
??? [libdvm.so]
??? [libdvm.so]
dvmLockObject() [libdvm.so]
??? [libdvm.so]
dvmMterpStd() [libdvm.so]
dvmInterpret() [libdvm.so]
dvmCallMethodV() [libdvm.so]
libdvm is the Dalvik VM parser - which you would think/hope would be extremely robust code (and thus makes me wonder if the stack backtrace above the strlen() call is just nonsense - the debugger is not guaranteed to get it correct).
here's the last couple of lines from an strace of system_server as it was crashing:
Code:
11:51:40 sched_setscheduler(157, SCHED_OTHER, { 0 }) = 0
11:51:40 ioctl(10, 0xc0186201, 0xbedce340) = 0
11:51:48 sched_setscheduler(157, SCHED_OTHER, { 0 }) = 0
11:51:48 getpriority(PRIO_PROCESS, 157) = 20
11:51:48 recv(606568, 0x81, 1, MSG_CTRUNC|MSG_EOR|MSG_WAITALL|MSG_ERRQUEUE|MSG_DONTWAIT|MSG_FIN|0xfffb0000) = 1
11:51:48 sched_setscheduler(157, SCHED_OTHER, { 0 }) = 0
11:51:48 ioctl(10, 0xc0186201 <unfinished ...>
11:52:04 +++ killed by SIGSEGV +++
Ugh... not very informative, frankly.
This might be a fairly difficult thing to pin down - after a little bit of testing, I've noticed that it is easier to cause this particular type of crash with a phone experiencing a decent (but reasonable) load than a lightly loaded phone - as if it is more likely to occur during a low resource condition, or is due to a timing/timeout issue. I have some difficulty getting it to occur on a "stripped" GSB 3.7 (Odex) ROM, where I removed almost everything non-essential, and didn't load any apps; but on my GSB 3.7 (Odex) "daily driver" ROM, it happens more frequently, and especially if I try and make the phone jump through other hoops while Maps/Nav is running.
... still looking...
bftb0
[ Edit ] 10 minutes after I made this post I flashed my "stripped down" GSB v3.7 Odex ROM, and set it up to watch it with Nav running. It crashed about 24 minutes later. I guess I should recant what I said above about load dependencies.
Just for kicks I reinstalled 2.1 (ota version) it didn't force close but the map quit updating my location. I had the latest maps installed and once again it crashed/stopped responding after ~20 minutes.
Just for kicks I restored a fairly old version of maps - v5127 a.k.a. "5.1.0" to my GSB v3.7 Odex ROM.
It crashed my phone (an Android restart, rather than a kernel reboot) within 10 minutes of starting up Nav.
Because all of these "crashes" seem to be in the system_server process, rather than the Maps/Nav app, I'm not convinced that the problems are due to the Maps app - we certainly were not experiencing restarts on older versions of GSB way back when maps 5.1.0 came on the scene. (Although we were experiencing the "GPS signal lost" after 20 minutes bug)
I don't know what to think at this time; maybe there is more than one bug involved. Perhaps I should try the non-odexed GSB version to see if it behaves any differently.
bftb0
I went driving around yesterday and was using navigation and had it crap out a few times. One time it said that acore had crashed. Two other times it just locked up for about 30 seconds and then I saw the cyanogen animation. Sort of like a partial reboot because it was really fast.
Sent from my GSB v3.6 ODEXed using XDA App
bftb0 said:
Because all of these "crashes" seem to be in the system_server process, rather than the Maps/Nav app, I'm not convinced that the problems are due to the Maps app ...
bftb0
Click to expand...
Click to collapse
I see what you're getting at but if the crashes are not Maps related why would non-CM7 phones also freeze up? Since this is happening on xtr and stock ROMs also is it possible that something in Maps is causing the system_server process to crash?
PieceKeepr said:
I see what you're getting at but if the crashes are not Maps related why would non-CM7 phones also freeze up? Since this is happening on xtr and stock ROMs also is it possible that something in Maps is causing the system_server process to crash?
Click to expand...
Click to collapse
My best guess is that there is more than one bug involved. Personally, I've observed three different behaviors, from most frequent to least frequent:
1- Android layer restart (always a system_server segmentation fault)
2- Full reboot (kernel restart)
3- Maps ANR (App Not Responding)
#1 is absolutely, positively a bug in the system_server code; plainly stated, native code should never segfault. What is odd about this is that having Maps running seems to cause this fault to occur - it doesn't seem to happen when Maps/Nav is not running. What is extremely challenging about diagnosing this is that (if the debuggerd stack traces are to be believed) it appears that it is the Dalvik VM code itself (libdvm.so) that makes the fatal call into libc.so - a simple strlen() call that gets a null pointer. That seems to imply that figuring this out requires understanding:
- how an unrelated app (Maps/Nav) is affecting java code of the system_server
- how the Dalvik compiler/optimizer/interpreter could possibly have a bug
Note that (again, if the debuggerd stack traces of the system_server crash appearing in the logcat are to be believed) if there really is a Dalvik VM bug involved, I suppose that also means that occurence of the bug could be dependent on:
- JIT on vs. off
- Optimizer settings (and odex'ed vs. non-odex'ed ROMs)
Perhaps this explains some of the variability in the various reports; most of my experiences with the bug(s) have been with the GSB 3.7 Odex ROM (JIT on, no compcache or dithering, various VM heap sizes).
I full-wipe installed GSB 3.7 non-odexed yesterday, and am going to do some more testing.
As for crash cases #2 and #3 - I haven't experienced enough of them to say anything meaningful.
bftb0
PS Over the weekend, I drove about 3 hours on both Sat and Sun, and I didn't want my phone blowing up on me, so I rolled back my phone to celb 4.1 (Froyo) and used Nav continously. The version of Maps in that celb backup was 5127 (aka "5.1.0"). I experienced the "GPS Signal Lost after 20 minutes" bug - which I expected - but using GPS status would allow Nav to re-acquire signal. But, no other trouble. The reason that I mention this is that this same *very old* version of Maps (5127) can readily cause the system_server process to crash in GSB v3.7 Odex. This kind of data is what leads me to believe that (at least for the "Android soft-restart" bug expression) while Maps/Nav can *cause the problem to occur*, this particular bug actually is not in the Maps app itself.
Anyway, that's a few of my observations; no solutions unfortunately.
More testing to come.
I have experienced all of those, but not in that order. Rearranged by frequency for me they would be ...
3- Maps ANR (App Not Responding)
1- Android layer restart
2- Full reboot (kernel restart)
I am on GSB 3.6 ODEXed (3.7 was sluggish for me and I was getting odd and random app force closes so I rolled back).
Settings:
CPU - Ondemand, 710/245
Compcache - disabled
JIT - off
Surface dithering - off
Purging of assets - off
Lock home in memory - off
VM heap size - 32mb (default)
V6 Supercharger - multitasking or sometimes Balanced 1 with launcher HTK
By far the most common problem for me was the Maps ANR. I did get the Full reboot, and several Android layer restarts before I started playing with settings. Unfortunately I don't remember what I started with and can't say what all I did. I was running Maps 3.6.2 (I'm pretty sure) at the time and I kept getting the Maps ANR. I found a copy of Maps 5.5.0 I had forgot about in MyBackup Pro so I wiped Maps data, then uninstalled before restoring just the Maps 5.5.0 apk.
Since then I have only had one problem, which happened two days ago. I had been using Navigation for about an hour and a half, maybe approaching two hours, by the time I reached my third destination. It showed me I had reached my destination but it froze. None of the app buttons were responsive so I tried the phone soft buttons and found they were unresponsive as well. Then the phone did an Android layer restart. At the time the phone was VERY HOT to the point of being uncomfortable to hold in your hand. I have never seen my phone that hot before. It was plugged in at the time because the battery had gotten low so I was charging it.
My wife's Eris is running xtrSense 5.0.1 and I took it out and tried it a while back. It never did a full reboot or an Android layer restart but Maps ANR occurred within five minutes. I tried several times and got the same result each time.
Hopefully some others who have experienced problems will see this and chime in. Maybe if we can narrow down specific occurrences with stock and other ROMs it will help decipher this. Thanks bftb0 for breaking this down into categories and for your work on the problem. If there is any data I can capture and provide let me know.
All -
I've been testing latest map version on a number of roms as of late and offer a few observations:
I have consistently experienced Android layer restart and full reboot on GSB roms, stock settings, versions 3.4 through current. I experienced a reboot on Condemned soul's version 14 rom only once. I have not ever experienced a navigation reboot on OMGB 1.1, Evervolv,3, or 666th Sense (March OTA based rom).
The only ROM I have run that has not resulted in a map ANR is OMGB 1.1, but GPS signal is lost within a minute on that rom. Navigation continues to wait for a signal but does not force close.
Condemned soul's v14, Evervolv 3, and 666th Sense all display the same behavior: navigation runs for between 2-10 minutes and map display freezes while voice navigation continues running as a separate service. Eventually a FC is offered and navigation can be easily resumed from the notification bar. It will FC within another 10-20 minutes.
I've been doing some testing and trying a few tweaks - all dead ends and none of them have worked, but I'll repeat them here in case they are of any use to this group:
First, I tried flashing old versions of gapps to roll back the com.google.android.maps.jar file to see if there was anything there affecting navigation. At first I thought it was working differently, but alas the old jar (if they are actually even different) files really behaved the same -- they locked up the navigation moving map while partially allowing the navigation voice(s) to continue.
After repeated testing, It *seems* that the moving map is hanging up for me in the SAME PLACES. Now this is all very subjective since I cannot pay all that much attention while driving, but when I leave my office for home it seems that the maps hangs at the first right turn, 1/2 mile or 2 minutes away. If I restart it, it will continue for another 10 minutes or so until after a major highway merge.
So, I began to notice the dual-voice navigation some others have mentioned and deduced that one voice is TTS and one is google's backup non-TTS navigation sounds. I suspected, perhaps, that TTS might be crashing or being force closed by the system. A little routing around and I found that if you uninstall TTS that navigation simply will not load but will FC immediately. I also found that you can disable TTS by removing/renaming the libttspico.so file. This way, you can actually force the second navigation voice - its rather pleasant but does not pronounce street names, just says "turn left" etc.
This did not fix the problem either. But it did allow me to rule out that the phone was temporarily losing GPS signal leading to the FC. Without TTS, navigation alerts you that GPS signal was lost with a chime sound. Maps was not hanging on a lost GPS signal. since voice directions continue despite visual map hanging.
So this leads me to my next observation. Without the distracting TTS voice I notice that the maps seems to hang precisely at a point where I am supposed to be alerted to an upcoming change. For instance, after making my first right leaving the office, it hangs when (1) I turn right forcing the map to pan and draw the route for the next leg AND SIMULTANEOUSLY (2) when the GPS wants to tell me the next direction "In a half mile, turn right on to the ramp"
I also thought that there may be a memory problem - like GB is trying to kill one of the Navigation related processes. As far as I can tell, navigation requires that the navigation map, a separate navigation voice service, and PICO TTS all be running at the same time on top of a launcher, maps, email, and other services. I tried tweaking V6 supercharger to gaming settings with no luck.
klobkelosh said:
...First, I tried flashing old versions of gapps to roll back the com.google.android.maps.jar file to see if there was anything there affecting navigation. At first I thought it was working differently, but alas the old jar (if they are actually even different) files really behaved the same -- they locked up the navigation moving map while partially allowing the navigation voice(s) to continue...
Click to expand...
Click to collapse
If the jar files are the same, they should have the same md5sum so it might be worthwhile to compare them and see if each jar has matching checksums.
*POSSIBLE* Navigation Fix
I may have found a fix. I was able to navigate on my daily commute without a FC or reboot (that's not happened in a while). BUT I need your help in testing it more to be sure it is not a fluke. I'll also be testing over coming days
The attached file is NOT a flashable zip. Extract the com.google.android.maps.jar file and push it to /system/framework replacing the gapps gb version. If you use root explorer/es file manager be sure to set permissions to rwrr.
This jar version is from the May 2011 MDPI gapps package. It is nearly double the filesize of the gb version so clearly not the usual framework.
Hope this works in the long run....
I'm driving from Paducah, KY to Oscoda, MI. Should be a good test, I hope this works
ok, for some reason, thought build.prop q's were relevant to the kernel...
anyway, I edited build.prop in /system with RootExplorer's text editor. changed the value for wifi.supplicant_scan_interval from 30 to 120. no extra lines or spaces, etc- just changed the number, saved, then rebooted. it took an obscene amount of time to boot up and the device stopped going into deep sleep after a short while. I installed better battery stats to see what was wrong and the app indicated mmc_delayed_work under kernel or partial wakelocks (i forget which). I restored the original build.prop and the device worked like normal.
Is this a bug or is ICS/JB different enough from GB that you have to go through alternate means to change build.prop (eg flashing an update script from CWM, or something similar)?
I've tried this twice already and gotten similar results and the method by which I edited the build.prop was exactly the same as I used to edit it on GB without issue.
another thread I checked out in the S II dev thread indicated that this is possible- editing build.prop (wifi scan at least, on top of a few others parameters)- w/o issue, so....yeah.
alljokingaside said:
ok, for some reason, thought build.prop q's were relevant to the kernel...
anyway, I edited build.prop in /system with RootExplorer's text editor. changed the value for wifi.supplicant_scan_interval from 30 to 120. no extra lines or spaces, etc- just changed the number, saved, then rebooted. it took an obscene amount of time to boot up and the device stopped going into deep sleep after a short while. I installed better battery stats to see what was wrong and the app indicated mmc_delayed_work under kernel or partial wakelocks (i forget which). I restored the original build.prop and the device worked like normal.
Is this a bug or is ICS/JB different enough from GB that you have to go through alternate means to change build.prop (eg flashing an update script from CWM, or something similar)?
I've tried this twice already and gotten similar results and the method by which I edited the build.prop was exactly the same as I used to edit it on GB without issue.
another thread I checked out in the S II dev thread indicated that this is possible- editing build.prop (wifi scan at least, on top of a few others parameters)- w/o issue, so....yeah.
Click to expand...
Click to collapse
I have no idea why that would happen, but I guarantee you the interval is fine where it is. I've left my player on with wi-fi over a week.
Mevordel said:
I have no idea why that would happen, but I guarantee you the interval is fine where it is. I've left my player on with wi-fi over a week.
Click to expand...
Click to collapse
I'm recording atm but problem isn't replicating. go figure; well, if it does, I'll post a logcat. if not, good for me since I forget to turn the wifi off most of the time and especially in places with no open wifi. anyway, I was posting this in case someone else did come across a similar problem and had a solution since my searches led nowhere (searching for anything mmc_delayed_work related comes up with little useful info/apparently a lot of once-valid GB tweaks are "busted"/not in ICS code base)
whether or not the scan interval isn't exactly the point, why I'm pursuing it; it's the specific point atm, but the general point is device ownership- tailoring your device to your heart's desire; complete ownership. that's the premise behind this whole site as I'm sure everyone here is aware. if I did something to mess it up along the way, great. but if it is a bug or something with ICS code base, it's be nice to know. a lot of folk like messing with build.prop so it'd be nice to know what can or cannot be messed with.
atm, it does look like I messed something up when editing and saving- perhaps I added a space or line where it shouldn't've been- since the device is sleeping as it should, again, if I find something, I'll post the logcat.
thanks for the re:
alljokingaside said:
I'm recording atm but problem isn't replicating. go figure; well, if it does, I'll post a logcat. if not, good for me since I forget to turn the wifi off most of the time and especially in places with no open wifi. anyway, I was posting this in case someone else did come across a similar problem and had a solution since my searches led nowhere (searching for anything mmc_delayed_work related comes up with little useful info/apparently a lot of once-valid GB tweaks are "busted"/not in ICS code base)
whether or not the scan interval isn't exactly the point, why I'm pursuing it; it's the specific point atm, but the general point is device ownership- tailoring your device to your heart's desire; complete ownership. that's the premise behind this whole site as I'm sure everyone here is aware. if I did something to mess it up along the way, great. but if it is a bug or something with ICS code base, it's be nice to know. a lot of folk like messing with build.prop so it'd be nice to know what can or cannot be messed with.
atm, it does look like I messed something up when editing and saving- perhaps I added a space or line where it shouldn't've been- since the device is sleeping as it should, again, if I find something, I'll post the logcat.
thanks for the re:
Click to expand...
Click to collapse
I understand.
Thinking about it, mmc_delayed_work seems like it's tryng to catch up the SDcard or something. Did you reboot cleanly? That may be the issue.
Mevordel said:
I understand.
Thinking about it, mmc_delayed_work seems like it's tryng to catch up the SDcard or something. Did you reboot cleanly? That may be the issue.
Click to expand...
Click to collapse
No clue. what do you mean by "reboot cleanly"? if by that you mean, did I reboot using the reboot option in the power menu, then yes. always.
After restoring a backup and re-editing build.prop, sleep worked like gamebusters. Except, bluetooth auto-toggled on ("bluetooth is turning on"). After rebooting, it was stuck on the boot animation screen for a few minutes. A reboot after that pretty much boot looped it. I restored my backup afterwards...
Looking in the logcat (after editing), I noticed a ton of errors and permission denials.... Since I don't have much expertise here, I can't say for sure that they're normal but they seem to be abnormal. Wayyy more than I remember seeing when I browsed through before on a "clean" boot. But again, with the lack of expertise (or any functional knowledge for that matter)
==
Now, after having restored the backup before making the edits and rebooting, it seems to be stuck in a bootloop....huh. ok, after rebooting it 2x, it finally seems to have booted up "normally." Both before restoring (w/ edits and BT error) and after restoring (w/o build.prop edits), it's taking a lot longer to boot up than it used to....guesstimating 3-4 minutes. When it boots up, I get/got: "process system isn't responding" (both before and after restores now) and something about alarm error.
I've attached logcats of both pre- and post-event, if you're curious. As to "solving" this,I'm just gonna re-flash the PA ROM and wipe caches to get rid of these problems. ergh. device meets my foot against the wall is next on the checklist.
thanks again. I'd like to say, Stay classy, San Diego, but we all know San Diego and its class
As the title states. Those using the newest roms do your phones ring as should? Been using and always going back to Baked 6 because every newer rom I try the phone frequently does not ring. To name a few, I tried Hellybean, Slim, Carbon, Baked 8. I have tried every solution that I can find in these forums. I depend on my phone for work so it has to be reliable. Does it not bother others that the phone does not ring as should or does yours work?
I'm on Helly Bean and it rings every time... although I don't get phone calls very often at all, so maybe if I did it would miss a few. This is a common issue unfortunately and I've yet to hear of an easy solution.
Not Ringing Either
My phone doesn't ring either. Hasn't through out the whole time I've been using HellyBean. I've been searching the forums and thus far haven't found a fix. If anybody has the fix thread can you post it here, thank you. Looks like I'll have to look into another rom as suggested in the start post.
it;s probably a ROM that doesn;t get any attention but i have been using JellyBro and the ringing and notifications work fine.
Look here for a fix
http://forum.xda-developers.com/showthread.php?p=42185823
louiehummv said:
Ugh, not again. Well... for what its worth, I found a way to stop losing em.
First, a little background... I discovered that the "media store" app will index ur phone's media after every reboot (as expected), but hangs before committing its findings from the temporary "wal" file to the "internal.db" database (where all ur media locations are stored). Then, when attempting to access the database while configuring ur ringtones/sounds, the media store app craps out and drops it findings altogether. Basically, the wal file disappears and the database file size decreases. So, all we have to do is force the wall file to commit before the media store drops it. Afterwards, the media store app doesn't appear to have a problem maintaining the database... even after rebooting. Definitely a bug with the app; see for urself by observing internal.db in /data/data/com.android.providers.media/databases.
Now, the workaround (ull hafta reassign all ur ringtones/sounds after this... not like they worked anyway)...
1 - Delete the contents of the folder /data/data/com.android.providers.media/databases.
2 - Reboot and wait ~5 min after startup to let the media store reindex all ur media. DO NOT configure any app's ringtones/sounds just yet.
3 - In terminal, enter the following commands. You should see "x | y | z" after the checkpoint command... where x is 0 (database is ok), y is the number of modified pages, and z is the number of pages successfully committed to the database. y and z should be equal and much greater than 0. If the result is not as described, the database is probably screwed up and u were too late. Go back to step 1 and repeat.
$ su
# cd /data/data/com.android.providers.media/databases
# sqlite3 internal.db
> pragma wal_checkpoint(FULL);
> .exit
# exit
$ exit
4 - Trust the workaround and start configuring ur ringtones/sounds now... or reboot again and ensure the media store database stays fixed. I recommend the latter.
5 - 3 sir!
Sent from my SCH-I535 using my wit and brilliance
Click to expand...
Click to collapse
hhp_211 said:
Look here for a fix
Click to expand...
Click to collapse
Can't find "/data/data/com.android.providers.media/databases"
Edit: Found
Hello,
I also suffered this issue, i think the rom you flashed was to blame.
This issue has been long discussed in our Chinese fascinate forum.
I strongly recommend you flash the lastest cm10.
自由自我
hhp_211 said:
Look here for a fix
http://forum.xda-developers.com/showthread.php?p=42185823
Click to expand...
Click to collapse
Tried the workaround. Ringtones lasted longer, but stopped after a couple hours. Tried on latest Helly. Curious which roms it's working for others on.
dukeoid said:
Tried the workaround. Ringtones lasted longer, but stopped after a couple hours. Tried on latest Helly. Curious which roms it's working for others on.
Click to expand...
Click to collapse
well i'm currently on Slim 04/09 build -
previous Slim 3/17;; ParanoidAndroid March Builds;; Baked Bean, 6/7/8;;; HellyBean;;; AOKP PUB;;;
that gets me back all the way to the beginning of the year
I have had working ringtones on ALL of these as my daily use phone...
on my test phone I cant test ringtones cause [ its not activated] but notification tones for things like hangouts, twitter, gmail, etc have ALL worked without fail on every build I've loaded,,, [ which is virtually ""ALL"" the others at one point or another]
but kind of like that work around is saying I always wait after a clean/data wipe about 10 minutes [before setting ringtones] while figuring out my other settings, adding apps and what not, usually give at least 1 more reboot and wait again another 10 minutes then set ringtones,,, but I also have my 2 personal use ones [ringtone = pyxis ,,&,, Notification = cyanping] stored in a file on my sd card [a couple ROMs have not had these and I don't really care to use anything else right now] and always making sure to choose media player/server as the default app if I've wiped media storage settings data,,, [that way I can add them back into the appropriate folders if needed]
I did have this issue way back about August/September of last year running on AOKP builds, but I remember odin to stock, then THS 1/2 build then flashing to an older glitched build before the original partition changes or the later partition changes, and probably flashing new aokp,,, wiping data, etc and I got mine fixed...butt... it could have gone back to me waiting out those initial scanning times plus reboots ~ before ~ setting ringtones/data,,,
then again,,, some peoples fascinates have just given them major issues with this and they have rarely seemed to fix the problem,,, so it could be hardware tolerances and those are just really off on some setting somewhere...???
Good Luck
I really dont feel it is a ROM issue...maybe an Android issue, like the voicemail notification prompt problems [because we dont have LTE and that is coded into jb software now, so the fascinate freaks out when it cant find lte settings...]
.
---------- Post added at 05:48 PM ---------- Previous post was at 05:38 PM ----------
you could try ,,, now that it borked on you,,, clearing out the android.providers.media / data , boot into recovery, wipe dalvik and cache partition, and reboot then wait out the time, reboot and again wait out time,,, then set ringtones,,, and try...don't know what else to say...
Thanks for the suggestions. Will try them.
I have been experiencing a series of force closes. I am posting this to see if anyone else has experienced this, and whether anyone can suggest a fix. I'm pretty sure it was something I did, but I'm not sure what. I'm hoping that this can maybe narrow it down.
Device: SM-N900P
Firmware: OC5, stock, rooted, with several tweaks and modifications(detailed below).
The problem: I am getting several force closes. They only occur when I am trying to open certain settings. So, they aren't just popping up at random. They are slightly troubling, but not really problematic. Which is to say, aside from the actual force closes themselves, I don't really seem to be experiencing any major problems. Here are the FC's I am experiencing:
-Menu> Settings> General> Battery: This one results in a "Unfortunately, Settings has stopped" dialog box, and an immediate return to my home screen. So, I can't check out my battery usage. I'm not seeing any crazy battery drain. By opening Root Explorer and navigating to data> system> batterystats.bin, and deleting batterystats.bin, the problem is kind of fixed- I can open battery from the settings menu after that. But there is only battery level and state displayed, no usage information(just a message saying it is not available).
-Menu> Settings> General> Developer options> Process Stats: Results in the same dialog box, and the background turns black if I don't press "OK". I'm not even sure what this does, but after my Battery started force closing, I started checking the rest of the settings out.
-Menu> Settings> Connections> Data usage: Dialog box, immediate return to home screen.
The probable cause: hard to say, I've done a few things to it. Like I said, I was hoping that someone would be able to figure out what I've done from the following information about what I have done so far. So, here goes.
I was on NK4, running Priest Punch ROM. I reverted to stock and took the OTA about a week or so ago. I immediately rooted and installed TWRP using the method in this thread: http://forum.xda-developers.com/note-3-sprint/general/how-to-root-note-3-lollipop-t3089382 .
After rooting, I didn't see a whole lot of OC5 development, so I started poking around to see what kinds of mods I could use. First thing I wanted to do was remove bloat. I started off using Root Explorer, then I happened upon this thread featuring a bloatware removal tool for the T-Mobile variant: http://forum.xda-developers.com/note-3-tmobile/development/tool-utility-sgn3-sm-n900x-bloat-t2813036 . It worked. I removed a bunch of apps, but nothing I wasn't sure I could safely remove(I had to check Google a few times). I did not notice any problems at this time.
Then I installed this mod to pump sound out of both speakers: http://forum.xda-developers.com/note-3-sprint/development/mod-sm-n900p-surround-sound-t2966042 . I did not notice any problems at this time.
Next, I decided I wanted more fonts, so uninstalled the preloaded fonts and pushed the apk from this thread: http://forum.xda-developers.com/showthread.php?t=2752379 . Again, no problems.
I decided that a working hotspot would be nice, so I used the method in this thread to get one: http://forum.xda-developers.com/note-4-sprint/general/lollipop-hotspot-root-flashing-t3048163 . I tested it and it worked. No problems.
I really wanted to silence my shutter sound, and I happened upon this Galaxy S4 thread: http://forum.xda-developers.com/showthread.php?t=2261789 . It worked, and there were no issues. This was my first exposure to csc codes. I found a similar thread for the s6( http://forum.xda-developers.com/galaxy-s6-edge/general/quick-guide-enabling-hidden-features-t3087506 ), and followed the instructions. I was able to enable the camera during calls and enable call recording. No problems here. I tried a keyboard mod from the same thread, which had no effect at all(good or bad), so I reverted the code for that one back.
This is when I think I started to go off the rails a bit. I saw a thread for the Polish variant of the Note 3, N9005. http://forum.xda-developers.com/gal...camera-mod-note-3-n9005-lollipop-5-0-t3067827 -it had a neat sounding mod designed to improve camera quality, remove recording time and snapshot restrictions, and make 60fps HD the default camcorder mode. It took a little trial and error to get it installed, but I was making backups of files I was messing with, and was able to quickly and easily reverse any missteps. Again, the mod works fine, and I have noticed no issues. So, I started looking at the dev's other work. Which led me to this thread: http://forum.xda-developers.com/galaxy-note-3/themes-apps/secsettings-mod-17-swipe-charging-t3046032 . I wanted some different unlock effects, and I wasn't really finding them, so I tried his mod out. It was a 3 step process: replace a SecSettings app, copy paste some .ogg files, and finally, copy paste a SustemUI .apk. The first two steps went fine, but the third resulted in a persisitent, repetitive dialog box. I forget what this dialog box said, but it popped up almost as soon as I could press "OK", and I had to restore the backup of SystemUI to make it usable again. Oddly enough, about half of the new unlock animations still worked fine, and I wasn't seeing any problems after that, so I left everything else there. I liked the unlock animations, and they didn't seem to be causing any problems after I restored the original systemUi .apk.
Let's see, what else might be relevant? I was using the built-in task killer quite a bit. I'm also using SetCPU. I have 2 profiles: Screen on, 1728 MHz max, 300 MHz min, governor ondemand. And Screen off, 1036 MHz max, 300 MHz min, governor interactive. And I have installed the Material Power Menu from this thread: http://forum.xda-developers.com/android/apps-games/app-materialpowermenu-reveal-animations-t3059169 .
I started to notice the battery FC last bight. So, I wiped the battery stats as outlined above. Noticed it again today, wiped stats again, and kept checking it. After about an hour, it was force closing again. That's when I started poking around and found the others.
I dunno if anything can be done about this, or if anyone might know what's wrong. And, like I said, Aside from these FC's I'm not experiencing any real problems. I'm a little worried that they may get worse, or turn into something more serious, but I can always restore a backup if that happens. But if there is some kind of fix for these issues, I would use it. Thanks in advance to anyone who takes the time to read this wall of text, and tale of irresponsible phonery.
These are all settings that monitor usage.... should that tell me anything? I have tried wiping cache and dalvik, but that only seems to fix battery usage and data usage very temporarily(like, for a minute or less). And it doesn't seem to have effect on Process Stats.
My thoughts:
Seeing as you have flashed a lot of mods, it could be anything. If it were me, I'd start the rom from scratch. Then for the first step, instead of removing apps, I'd freeze them with titanium backup and give that a day or two to check the stability.
If that works, I'd continue with the mods one by one, giving a day or so for stability checks.
If you'd rather not do all that, you could use a logcat to find the origin of the problems.
Sent from my SM-N900P using XDA Free mobile app
jlechner said:
My thoughts:
Seeing as you have flashed a lot of mods, it could be anything. If it were me, I'd start the rom from scratch. Then for the first step, instead of removing apps, I'd freeze them with titanium backup and give that a day or two to check the stability.
If that works, I'd continue with the mods one by one, giving a day or so for stability checks.
If you'd rather not do all that, you could use a logcat to find the origin of the problems.
Sent from my SM-N900P using XDA Free mobile app
Click to expand...
Click to collapse
I'd probably try the logcat first. One, because I hate doing stuff over, and two, Ive neber done it before and it should be a learning experience. Is it complicated? I'm assuming there is a thread here on xda about it...
GAPO said:
I'd probably try the logcat first. One, because I hate doing stuff over, and two, Ive neber done it before and it should be a learning experience. Is it complicated? I'm assuming there is a thread here on xda about it...
Click to expand...
Click to collapse
It's fairly straight forward. I did one to see why an app wasn't loading, didn't need instructions. But that was a fairly simple check, yours sounds more complicated. I'd do a bit of reading on it.
Sent from my SM-N900P using XDA Free mobile app
jlechner said:
It's fairly straight forward. I did one to see why an app wasn't loading, didn't need instructions. But that was a fairly simple check, yours sounds more complicated. I'd do a bit of reading on it.
Sent from my SM-N900P using XDA Free mobile app
Click to expand...
Click to collapse
Will do. Thanks for your help!
Okay well I decided to re flash OC5 and start from scratch.
I took it back to stock and re rooted. Am now debloating....no isssues yet.
I have flashed everything except the Polish camera mod and the wallpapers. Having zero issues of any kind. I know it can take difficulties some time to manifest themselves, but I'm betting it is either the lock screen animations or the camera mod. Leaning towards the lock screen animations because it involves messing with system.ui...
Okay, made a new backup and flashed the camera mod. No issues. After every mod, I have been going back and checking for issues. This is all stil pretty new, but if everything is still fine after a couple of days, well, I will be convinced that it was the lock rings. Not surprising obviously that flashing stuff meant for foreign variants can wreck your sh*t, lol.
I say possible because the possible solution is basically disabling a system app, but this was after disabling other system apps and mucking around with settings, so it might be a combination of apps being disabled, but i dont think so
By the way, i can confirm that twrp from the here https://forum.xda-developers.com/nokia-1/development/unlocking-rooting-nokia-1-stock-rom-t3832230 works, and so does the latest magisk 17.
Twrp
Ive succesfully used the backup/install feature but havent had the courage yet to test the wipe and restore (data,system) feature, although following that ^ guide ^, looks like restore recovery/boot image works, so thats hopefully a good sign
Magisk
Following that guide, use twrp to flash, no major issues with installation.
Note, if you follow that guide and you come to the bit where the stock recovery only shows "no commands", hold press power button + up volume for a sec or two, or at least thats what i read somewhere, read somewhere else to just press these buttons continually on and off, which i did randomly, and eventually the stock recovery options appeared, dont know why this is this way
Anyways, the culprit, assuming im right barring the above reasons was........a system app called EMM or emmupdate (literately the apps name changed on my phone, i remembered it was emmupdate and now, after checking, its changed to emm, thats weird)
I used a root based logcat app
https://f-droid.org/en/packages/com.dp.logcatapp/
to try and see if there was anything to see, using a particular app i could reliably duplicate the issue with (swiping away from recents app would turn off this apps service removing its notification a couple seconds after being cleared from recents, this app being https://play.google.com/store/apps/...ite&pcampaignid=APPU_1_LUahW_D4DonSgAajx4y4Aw
Paused the logcat searched for the app, and saw a reference with this app, showing the emm app and references to "killing"
Solution
My particular solution was this app,(requires root)
https://play.google.com/store/apps/details?id=com.kunkunsoft.rootservicedisabler
(i dont think you can disable this emm app normally like some system apps, check, i could be wrong)
-in my brief researching this area, i saw discussions that you may be able to do this with adb(i dont know for sure, but might be worth looking into it yourselves, if you dont want to root, no guarantees)
The service disabler app lets you disable, well, services, and this emm app had one service attached to it called "MemoryManagerService", so maybe thats what did it, and not the disabling of the app, so i suggest that if you use this app, also disable the service as i did, for the emm app if disabling the app only, did nothing
IMPORTANT- Reboot the phone after, as thats when the change took affect for me
Ive rebooted, slept, and cleared recents and so far, multiple background apps that were continually being killed before, have NOT been killed
Hope this helps, hope it works.........silly that we have to do this
Well i did the same thing by analyazing the logcat through adb. What i found was that any app was killed after this so called emmservice in emmapp was run. After this the activity manager simple killed that app.
To check i choose emm app and turned d switch off under background apps in developer options. Also fc emm.apk. but still problem was there.
Ill check your workaround. It sounds more promising.
coolboyforeva said:
Well i did the same thing by analyazing the logcat through adb. What i found was that any app was killed after this so called emmservice in emmapp was run. After this the activity manager simple killed that app.
To check i choose emm app and turned d switch off under background apps in developer options. Also fc emm.apk. but still problem was there.
Ill check your workaround. It sounds more promising.
Click to expand...
Click to collapse
If you get the time, let us know if it works, that way anyone else with the same issue who comes across this thread at least has a way to make the phone multitask
An open source alternative to the disable services app, is an app called oandbackup on the fdroid store(like titanium backup), has a feature that lets you disable apps(requires root), aswell as backup/restore apps and their data, its very good
I just tried looking for a non root solution, but it seems that adb solution i briefly saw earlier also needs root
Besides that, like i said in my first post, it could have been the disabling of emmupdate/s service in the disable service app, so if disabling alone doesnt do it, try disabling the service aswell...........i kinda wanna know the least amount of steps to get it fixed, so if disabling did it alone, that would be worth knowing
Gd luck
Spoke to soon, seems like there might be a way to use adb without root to disable system apps https://www.androidpit.com/uninstall-system-apps-without-root, whether it works on oreo i dont know.
The article solution implies the this will uninstall the apps, but apparently, according to a commenter in that article, it deletes a part of the app in a certain place in android that essentially just disables it, if you did a factory reset, the app would return
If it works, at least users wont have to go through the trouble or risk of mistake in flashing twrp/root or any other modifications to fix it, assuming just disabling emm....... works.
banderos101 said:
If you get the time, let us know if it works, that way anyone else with the same issue who comes across this thread at least has a way to make the phone multitask
An open source alternative to the disable services app, is an app called oandbackup on the fdroid store(like titanium backup), has a feature that lets you disable apps(requires root), aswell as backup/restore apps and their data, its very good
I just tried looking for a non root solution, but it seems that adb solution i briefly saw earlier also needs root
Besides that, like i said in my first post, it could have been the disabling of emmupdate/s service in the disable service app, so if disabling alone doesnt do it, try disabling the service aswell...........i kinda wanna know the least amount of steps to get it fixed, so if disabling did it alone, that would be worth knowing
Gd luck
Spoke to soon, seems like there might be a way to use adb without root to disable system apps https://www.androidpit.com/uninstall-system-apps-without-root, whether it works on oreo i dont know.
The article solution implies the this will uninstall the apps, but apparently, according to a commenter in that article, it deletes a part of the app in a certain place in android that essentially just disables it, if you did a factory reset, the app would return
If it works, at least users wont have to go through the trouble or risk of mistake in flashing twrp/root or any other modifications to fix it, assuming just disabling emm....... works.
Click to expand...
Click to collapse
I tried. I can confirm the root method works. However, i also did the adb method. The adb too works. Apps are not killed by android now. No need to unlock bootloader, root or twrp. It just executing 2 commands
Code:
adb shell pm clear com.evenwell.emm
adb shell pm uninstall -k --user 0 com.evenwell.emm
And then reboot.
This clears the app data and disables the app for current user.
And, moreover it survives ota updates too. !!
Only thing to keep in mind is that if you factory reset, you have to re execute above 2 adb commands.
So now all sorted. Just a matter of executing 2 commands.
coolboyforeva said:
I tried. I can confirm the root method works. However, i also did the adb method. The adb too works. Apps are not killed by android now. No need to unlock bootloader, root or twrp. It just executing 2 commands
Code:
adb shell pm clear com.evenwell.emm
adb shell pm uninstall -k --user 0 com.evenwell.emm
And then reboot.
This clears the app data and disables the app for current user.
And, moreover it survives ota updates too. !!
Only thing to keep in mind is that if you factory reset, you have to re execute above 2 adb commands.
So now all sorted. Just a matter of executing 2 commands.
Click to expand...
Click to collapse
Very nice, now we know a solution
There you go folks, thanks to coolboyforeva's info, work, testing, and confirmation, anyone who comes across this annoying issue now has a non root solution to fix it, two adb commands.............not to bad, not to bad at all
Cheers CBF, for finding the specific adb commands, and the helpful info, hope it was'nt to much of a bother...........doing gods work pal
can confirm that the adb method works and can easily multitask now... thanks guys... no force closures of app now.....
Any you guys noticing a delay after reboot for your user apps to start, or just me.
Edit: even during operation(comes and goes), example app = Tasker
Edit2: mmmm, i have a suspicion it might be something to do with gaining root from magisk. Magisk has a few settings that changes how this works, so i might mess around with that first and see what happens. Might also just be tasker/oreo incompatibilities, or perhaps conflicting tasks
Probably gonna look into it, ill post here if i find anything, unless someone beats me to the punch, suspect its one of the manufactor's sytem "optimizing" apps..........
Was hoping we'd be swimming in custom roms, seing as our device SEEMS to be treble compatible and so cheap, a nice bloat free working lineage as daily driver..........guess ill have to stream line stock as much as possible until that day hopefully comes
banderos101 said:
Any you guys noticing a delay after reboot for your user apps to start, or just me.
Edit: even during operation(comes and goes), example app = Tasker
Edit2: mmmm, i have a suspicion it might be something to do with gaining root from magisk. Magisk has a few settings that changes how this works, so i might mess around with that first and see what happens. Might also just be tasker/oreo incompatibilities, or perhaps conflicting tasks
Probably gonna look into it, ill post here if i find anything, unless someone beats me to the punch, suspect its one of the manufactor's sytem "optimizing" apps..........
Was hoping we'd be swimming in custom roms, seing as our device SEEMS to be treble compatible and so cheap, a nice bloat free working lineage as daily driver..........guess ill have to stream line stock as much as possible until that day hopefully comes
Click to expand...
Click to collapse
Yes there is delay. Bt i think it would be there. Initially when apps were killed u had enough ram to quickly process any app. But now since apps reside, android ram management has to manage. And that delay in app starting maybe coz be hardware. Its a low grade mediatek chipset. I dont expect it to be quick. (Atleast it auto start apps after delay). But yes if you could find some clue to optimize , that would be good.
Meanwhile i am looking for a pie rom. treble rom works on our nokia 1. I flashed phh treble pie gsi. It boots normal. Only thing is you dont get notified of incoming calls, no rings. Outgoing calls work normal though. So it cant be used.
Link for rom : https://forum.xda-developers.com/pr...vice-development/aosp-9-0-phh-treble-t3831915
If this issue is resolved we could have a ready pie rom too.
coolboyforeva said:
Yes there is delay. Bt i think it would be there. Initially when apps were killed u had enough ram to quickly process any app. But now since apps reside, android ram management has to manage. And that delay in app starting maybe coz be hardware. Its a low grade mediatek chipset. I dont expect it to be quick. (Atleast it auto start apps after delay). But yes if you could find some clue to optimize , that would be good.
Meanwhile i am looking for a pie rom. treble rom works on our nokia 1. I flashed phh treble pie gsi. It boots normal. Only thing is you dont get notified of incoming calls, no rings. Outgoing calls work normal though. So it cant be used.
Link for rom : https://forum.xda-developers.com/pr...vice-development/aosp-9-0-phh-treble-t3831915
If this issue is resolved we could have a ready pie rom too.
Click to expand...
Click to collapse
Cheers buddy, nice to know these things, good to know that theres already an initial treble rom.
Gonna wait for incoming call ring support, might give it a couple of months actually, before trying out any rom that might come along, let the bugs get settled if any, assuming were lucky enough to get a maintainer
Edit
Commenting about the slow response time of user apps, normally i'd agree with you on the outdated hardware, but either the rom is very streamlined or the hardware is not so bad, as the phone is surprisingly snappy when its not stalling, which leads me to believe its a system app/service........ive had slow devices, and usually, everything is slow all the time, either because outdated hardware or heavy rom, so hopefully its a system app
Adb method works well here, tanks a lot. No UB, no root.
I'll be trying the ADB method when have enough charge as had to take Nokia 2.1 back and for that device having a Snapdragon I can confirm that this Nokia 1 is quicker by a mile
I done the adb method and it's worked!!!
thank you guys for this hack. multi-tasking is finally working and alot of overlays and apps are now working without closing.
I'll share with you something i found to make this phone really fast: in developer mode disable animations from x1 to OFF. Then turn ON gpu for 2d drawings. And reboot.
Now it will be buttery smooth!!