crash - Android app suddenly does not react without having changed anything

Question

I have a really strange issue. I have an android app with some imagebuttons. When you press the imagebuttons (depending on which imagebutton) the app navigates to a new fragment using the JetPackNavigation. Basically I have been using the app (while developing it) for more than 4 months and the navigation had never been a problem.

Now all of a sudden when clicking some imagebuttons the app in the App Emulator of Android Studio does not react anymore. This is really strange because I did not change anything (I made sure by using the local history of Android Studio). Further for some ImageButton it still works perfectly.

So my question is bascially, whether there is a way to find out what causes the problem? In the logcat there is no error message whatsovever. I only get a timeout report after some while without any hint, as you can see here

2021-01-09 11:31:57.067 542-31149/? E/ActivityManager: ANR in com.example.td.barapp (com.example.td.barapp/.MainActivity)
    PID: 31101
    Reason: Input dispatching timed out (deb7f58 com.example.td.barapp/com.example.td.barapp.MainActivity (server) is not responding. Waited 5005ms for MotionEvent)
    Parent: com.example.td.barapp/.MainActivity
    Load: 0.71 / 0.83 / 1.35
    ----- Output from /proc/pressure/memory -----
    some avg10=0.00 avg60=0.00 avg300=0.00 total=46655214
    full avg10=0.00 avg60=0.00 avg300=0.00 total=3766399
    ----- End output from /proc/pressure/memory -----
    
    CPU usage from 1ms to 6375ms later (2021-01-09 10:31:50.651 to 2021-01-09 10:31:57.025):
      93% 31101/com.example.td.barapp: 75% user + 17% kernel / faults: 2812 minor
      31% 542/system_server: 3.7% user + 27% kernel / faults: 7660 minor
      6.7% 2702/com.android.systemui: 5% user + 1.7% kernel / faults: 4875 minor
      5.6% 277/[email protected]: 0.1% user + 5.4% kernel
      4.7% 3858/com.google.android.gms.persistent: 2.6% user + 2% kernel / faults: 2653 minor
      0.1% 424/media.codec: 0% user + 0.1% kernel / faults: 3235 minor
      0.1% 426/media.swcodec: 0% user + 0.1% kernel / faults: 3265 minor
      2.1% 1102/com.android.phone: 0.9% user + 1.2% kernel / faults: 1428 minor
      2% 374/adbd: 0% user + 2% kernel
      1.8% 947/com.android.networkstack.process: 1.4% user + 0.4% kernel / faults: 1128 minor
      0.1% 149/logd: 0% user + 0.1% kernel / faults: 2 minor
      0.1% 410/media.extractor: 0% user + 0% kernel / faults: 1490 minor
      0.1% 1650/com.android.emulator.multidisplay: 0% user + 0% kernel / faults: 913 minor
      0% 1629/com.android.ims.rcsservice: 0% user + 0% kernel / faults: 904 minor
      1% 295/[email protected]: 0% user + 1% kernel
      0% 1082/com.android.se: 0% user + 0% kernel / faults: 871 minor
      0% 1/init: 0% user + 0% kernel
      0.7% 10/rcu_preempt: 0% user + 0.7% kernel
      0% 2033/com.android.bluetooth: 0% user + 0% kernel / faults: 112 minor
      0% 251/tombstoned: 0% user + 0% kernel
      0.4% 363/logcat: 0% user + 0.4% kernel
      0% 30392/logcat: 0% user + 0% kernel
      0.3% 168/jbd2/vdc-8: 0% user + 0.3% kernel
      0.1% 9/ksoftirqd/0: 0% user + 0.1% kernel
      0.1% 16/ksoftirqd/1: 0% user + 0.1% kernel
      0.1% 109/kworker/1:1H-kblockd: 0% user + 0.1% kernel
      0% 153/vndservicemanager: 0% user + 0% kernel
      0.1% 266/statsd: 0% user + 0.1% kernel / faults: 47 minor
      0% 267/netd: 0% user + 0% kernel / faults: 36 minor
      0.1% 326/[email protected]: 0% user + 0.1% kernel
      0.1% 340/audioserver: 0.1% user + 0% kernel / faults: 41 minor
      0.1% 348/surfaceflinger: 0% user + 0.1% kernel / faults: 40 minor
      0% 383/cameraserver: 0% user + 0% kernel / faults: 43 minor
      0% 385/drmserver: 0% user + 0% kernel / faults: 40 minor
      0% 413/mediaserver: 0% user + 0% kernel / faults: 42 minor
      0.1% 421/wificond: 0% user + 0.1% kernel
      0.1% 919/[email protected]: 0% user + 0.1% kernel
      0.1% 30400/kworker/u4:0-phy0: 0% user + 0.1% kernel
      0.1% 30858/kworker/0:1-events_power_efficient: 0% user + 0.1% kernel
      0% 30977/kworker/1:2-mm_percpu_wq: 0% user + 0% kernel
     +0% 31151/crash_dump32: 0% user + 0% kernel
    96% TOTAL: 55% user + 40% kernel + 0% iowait + 0.3% softirq
    CPU usage from 49ms to 796ms later (2021-01-09 10:31:50.699 to 2021-01-09 10:31:51.446):
      61% 542/system_server: 0% user + 61% kernel / faults: 287 minor
        57% 31149/AnrConsumer: 1.7% user + 56% kernel
      99% 31101/com.example.td.barapp: 99% user + 0% kernel
        99% 31101/ample.td.barapp: 99% user + 0% kernel
      4.6% 277/[email protected]: 0% user + 4.6% kernel
        6.1% 1167/[email protected]: 0% user + 6.1% kernel
      1.5% 295/[email protected]: 0% user + 1.5% kernel
        1.5% 349/: 0% user + 1.5% kernel
      2.1% 3858/com.google.android.gms.persistent: 0% user + 2.1% kernel
    87% TOTAL: 51% user + 36% kernel

First of all I wanted to ask, whether you see anything in this timeout report that might cause the problem (I doubt this). Moreover, I'd be happy if you could share your experience on such strange mistakes that occur without having changed anything. It seems that the app gets into a deadlock situation or a not ending loop. What is your approach for solving such issues in general.

I'd be happy, if you could share your experience and I would highly appreciate it.

question from:https://stackoverflow.com/questions/65641711/android-app-suddenly-does-not-react-without-having-changed-anything

Answer 1

This answer is the synthesis of the discussion we had in the comment section which eventually led to a solution.

Before we do anything in such a situation, it is vital to double-check whether there was some change after all that we did not see for some reason. It is important not to omit this double-check, because this does not take much time, while the systematic approach that leads to the solution involves a lot of effort. So, with this double-check we have a lot of potential gain with virtually no risk/cost. I personally use git as a version control system, but any system that is reliably showing such differences will do the job.

Seeing many not working image buttons looks overwhelming, we need to focus our research to a manageable and understandable problem-space. So, we need to choose one of the not working image buttons and find out why that does not work. If we are lucky, then solving that problem will either automatically solve the others, or give us some strong hints for the others. Naturally, we could have multiple very different problems, which off course means that we need to repeat the process outlined in this answer.

A very important hint is that not all the image buttons show this behavior, so we know that the problem is unlikely to be related to image buttons and it's more likely related to actions triggered by events on the image buttons.

Some debugging and logging is always helpful. Debugging shows us what happens, so if we do debug, we might find some bad behavior at some point which might well be the issue itself. If we do some logging, then we can see what happens while the program is running. We can do either or both.

In some cases there is no solution. For example a remotely working API might stop working, which is an unsolvable issue. In this case detecting this situation is vital. If there is no solution, then at least we need to find this out as quickly as possible, so we do not sweat on it too much.

Some steps towards the solution:

1. Reduce the problem space to a small, manageable size (and possibly provide more information into your question)
2. Define your problem well (Currently you link your problem to image buttons, but you are wrong to do so, since the fact that some image buttons work disproves the hypothesis that image buttons would work wrongly)
3. Look into the undivideable units of work, in your case the actions, choose one of them as a current focus and redefine the problem into an even smaller size)
4. Log and debug to collect information
5. From the list of the information you have collected plan a few experiments
6. Sequentially try all your hypotheses
7. If the solution is not yet found, then you might start all over from point 1. or you might decide to remove the action (temporarily) and gradually implement it back, until you either find what the problem is or accidentally solved it