On a Samsung Galaxy Ace II, whenever the system is about to finish its booting up process, an “Application system is not responding” dialog-box shows up, therefore allowing the user to kill the process or to wait for it to respond. Before appearing this dialog-box, the system appears to be frozen – although some input from the user is expected to work, it does take a long time to process and experiences erratic behaviour -.
This issue is well-known in the Android community. Using part of its terminology, this issue is called an ANR or Application Not Responding. Thus, the application “system” appears to stop working or there is something that makes it to wait for a huge period of time, that huge, that an ANR is fired by the system. Because this happens at boot time, the entire system seems to freeze and it is not until the user kills this application that the terminal finishes its booting procedure and makes itself available to the user once again. From time to time, though not always, this odd behaviour can end up in an unexpected reboot.
Thus, the best way to determine all about this ANR is by connecting our terminal to a GNU/Linux box using the micro-USB cable and establishing a shell connection to it thanks to the adb utility, included in the Google SDK package. Android does include a log analyzer, called logcat, that can be used to look for ANR messages. Thus:
# logcat -v time |grep ANR
This is what came up after switching the terminal on:
01-12 18:00:57.048 E/ActivityManager( 1709): ANR in mobi.infolife.cwwidget
01-12 18:01:18.700 E/ActivityManager( 1709): ANR in mobi.infolife.cwwidget
01-12 18:01:40.800 E/ActivityManager( 1709): ANR in system
01-12 18:02:59.280 E/ActivityManager( 1709): ANR in mobi.infolife.cwwidget
01-12 18:03:21.010 E/ActivityManager( 1709): ANR in mobi.infolife.cwwidget
It is crystal clear that the ANR dialog box is refereed to the “system” application, that is, the third line (stressed in bold) in the previous listing. However, we have to bear in mind that the “system” application has not been altered since the last system upgrade. Therefore, it must be quite out of the question to think there is something wrong with it out of the blue. Besides, there is a large number of ANRs involving the process “mobi.infolife.cwwidget”, as clearly shown in the previous listing. Just because these ANRs do happen before the system’s ANR, it seems fairly plausible that the process mobi.infolife.cwwidget is the one affecting the system process. It immediately follows that we have to focus on this process, not on the system one!
Next screen shot shows what our terminal looked like after booting up and by-passing the ANR dialog box:
Determining what mobi.infolife.cwwidget is
So our first approach is to determine where this process resides and what it does. Our intention is to disable it and test the terminal without this process running. Because of its name, it seems quite obvious that it must be a widget. To accomplish that, we can use the ES File Explorer application, available on Google Market. Due to the fact that our process is called mobi.infolife.cwwidget, we have to look for an application called this way: mobi.infolife.cwwidget*.apk. So, before running the ES File explorer directly on our terminal, we use the adb shell once again:
# find / -name mobi.infolife.cwwidget"*".apk /data/app/mobi.infolife.cwwidget-1.apk
Now, using the ES File Explorer application, we navigate to /data/app and get some information about this app:
Easy as pie. So, it is our Clock & Weather widget, nonetheless! We decided to remove it from the desktop, therefore expecting the process mobi.life.cwwidget not to be run again.
Fixing it …
Despite the fact we did not have this widget visible on our HOME screen, we still got ANRs concerning it. Oddly enough, the process system was still freezing. Another use of our adb shell revealed to us that the widget was still running, even when it was not visible and, in fact, we did not want to use it! Clearly the entire android environment is not reliable enough, right?
So we de-installed the entire widget and then we rebooted the terminal by issuing this command from the adb shell, in order to determine whether, without this widget running, there were no more ANRs happening:
Jackpot! Our terminal was not issuing more ANRs, and the system process ran just fine. Finally, we decided to re-install the widget and everything was working without problems once again. Maybe another course of action would have been to clear the cache or even the widget’s data.