Through some experimentation and remembering having installed an app on my D1 called "Watchdog" (mentioned I think earlier in this thread?) before my D1's screen stayed black - common among a lot...
See more...
Through some experimentation and remembering having installed an app on my D1 called "Watchdog" (mentioned I think earlier in this thread?) before my D1's screen stayed black - common among a lot of older MotoDroid models. Watchdog has improved vastly since then (2 years ago at least), and running it, I have found - for me - a few runaway apps. One is a seriously RAM-leaker called Xiialive, believe it or not. GReat Internet Radio Streamer, but leaks like a sive, and I now have Watchdog kill it. Another app that is large and if its Notifications are set to ON, will fill your phones main mem of 40-45MB, the app itself is only 14MB! Wha!? Well, it happens. A lot. Now, with the paid version, I can blacklist (paid version only) these apps when they reach high CPU. Unfortunately, the REAL monitoring we need is RAM consumption kills. THAT would be useful, but in general High CPU usually translates into High RAM in smaller devices. So, in short, these constant reboots are INDEED caused by too much RAM comnsumed too fast. One way to monitor this is to use any App Killer, and as soon as the phone boots enough so you can get into that app, manually Kill alll the apps that popup during the remaining bootup - you will see apps you never thought would be running, how much RAM they take up, and which apps might need some settings tweaks. I have been running tests with Watchdog, and it has warned me indeed of these three mentioned culprits. <Content deleted per the TOS> Since starting these experiments I have also noticed that now, when I turn my D4 off, it actually STAYS OFF. This makes some sense as RAM will retain its charge when the device cycles off, but if RAM is not killed properly, there may still be code within that causes the reboot on purpose, could actually be some safe-mode thing: in that I also notice after a cycle of device-induced reboot, that on return, the SD and Internal stires are NOT prepared aswith a normal boot - why? Becuase of the RAM charged retention - the bits are still there, havent been cleared - bad OS coding if ya ask me, and ya didnt! Until I implemented the manual app killing (using App Killer) while the boot process was still underway (after being able to unlock the phone after the initial bootup phase), I was chasing my tale with all kinds of two-button, three-button dances, until the phone would finally "settle". The only reason the devices will finally "settle" is probably due to the nature of Anroid OSes, where I hear they are supposed to monitor and log-compare their own behavior, including sandboxing and booting. Apparently they also need to Shut Off sequences to the code base. <Content deleted per the TOS> Message was edited by: Verizon Moderator