Home » Android » Android Studio, logcat cleans after app closes

Android Studio, logcat cleans after app closes

Posted by: admin March 11, 2020 Leave a comment

Questions:

I’m having a problem with my logcat since update 1.2 Beta for Android Studio. When I run my app it logs everything like it normally did, then I get at the point where my app crashes with the app saying: unfortunately, Game has stopped.

After a few seconds android closes that message. When that happens my logcat also gets fully cleared meaning that I barely get anytime to read the error. I did found some info about a buffer, but it seems that Android Studio doesn’t have the option to increase it besides the fact that I doubt that being the problem.

Something that may be useful is that after it clears and stuff the process changes to Android.process.core and the message I get in my logcat is:

04-13 10:28:13.394  12259-12265/android.process.acore D/dalvikvm﹕    
Debugger has detached; object registry had 1 entries

Edit: I did read about breakpoints, so disabled focus application on breakpoints in Settings-build, execution, deployment-debugger but it didn’t have any effect.

How to&Answers:

I had the same issue, but looks more like a feature than a bug:

In AndroidStudio, the default setting for the Logcat window seems to be “Show only selected Application” (top right corner of the Logcat window)… which is looking at the log of the selected process (your current launch by default). So when your app crashes during testing, that process is gone, so the filter clears the log.

Instead, select “Edit Filter Configuration…” and set up a filter for your app, eg:

  • FilterName: MyApp
  • PackageName: com.example.myapp (<< replace with your app’s package name)

…and then select that filter for future runs. This should keep the log there for you, even after the app crashes.

Answer:

Switch “Show only selected application” to “No filters”. This way, you can see logcat output from a process even when that process isn’t running.

The downside is that your logcat will be filled with more spam from other processes.

Answer:

My App was crashing and restarting. I also had some problems on reading the logcat to know what was happening. I then noticed that in the drop down menu, next to the Device dropdown it had something like “com.mypackage.myapp (‘some number’)” and when my app crashed there was another option that said “com.mypackage.myapp (‘some number’) [DEAD]”. If you select the “Dead” option, it will show you the logcat of the previous instance.

Dead LogCat

Answer:

In case of crash see the Run tab at the bottom of IDE.

You can see the crash reason in this part (even in logcat clean case).

Note: If the above trick not works try to produce a crash and immediately disconnect the mobile cable (if you use the real device for the test). you can see the error before it cleaned.

Update: If also above trick not works, try to attach and detach phone and hopefully problem solved.

Update2: If again not work, try to Invalidate catches and Restart then start debugging again.

Update3: As The last way, try to remove the app and install it again then start debugging (if you do not lose that condition you want to test)

Answer:

i have faced the same issue and this is the solution :-

1- Tools –> Android –> Enable ADB Integration.

and now you can see the logcat and the crashes as normal

Answer:

The filter clears the log once the app gets crashed. So select “Edit Filter Configuration” and create your own custom filter with filter name. This will save the log with informations even when the app is crahed.

Answer:

In Android Studio 2+

  1. Click Run

  2. Click Edit Configurations

  3. In the Run/Debug Configurations window select the Miscellaneous tab

  4. Make sure the Clear log before launch checkbox is not checked

Answer:

It is 2018 and this can still happen. Close Android Studio and reopen.

Answer:

This bug seems to be fixed with the new release of Android Studio version 1.2.2

Answer:

I ran into the same problem and none of the answers could help me, until I realized my app was causing an OutOfMemoryException. That’s a probable root cause as well.