Spent way too long on an Android crash with nothing in Metro. logcat had the answer the whole time

[u/royalraju907]

Posting this because I lost a stupid amount of time on it and I doubt I'm the only one.

App just closes on Android. No red screen, nothing in Metro, DevTools disconnects. I did what everyone does: rerun, clear cache, paste the code into AI a few times.

The reason was in logcat the whole time. Native code threw, the app died before JS could say anything, and the Android log had the exact line.

What worked for me:

- open the android folder in Android Studio and open Logcat (it picks up the app even if you started it with yarn run android)

- clear it, then reproduce the crash

- set the level to Error and search FATAL EXCEPTION

- read the exception message first, then the first line in the stack trace that isn't Handler / Looper / ActivityThread. Click it and it jumps to the code

One thing that got me: in the terminal, filtering by pid after a crash gives you nothing because the process is gone. adb logcat -d -s AndroidRuntime worked better.

Also the stack trace only told me where it died, not who passed the bad value. I needed a breakpoint for that part.

I made a small demo crash and recorded the whole thing for anyone who'd rather watch than read: https://youtu.be/oVYBmnOVaI8

What do you check first when Metro says nothing?

[u/speedoinfraction]

Welcome to RN where you need to know web, Android, and iOS debugging. I always go to logcat first on a hard crash. You can run it live. logcat -e <your app name>

[u/royalraju907 → u/speedoinfraction]

Totally agree 😂 React Native debugging eventually sends you into native territory.

I started with Logcat for this crash demo too. One thing I learned: -e matches log message text, not the package name itself. For app-specific logs, filtering by PID or package in Android Studio can be more targeted which I recorded.

Still, knowing how to read the raw crash before filtering everything out is a skill worth having!

[u/Huge_Pool7424 → u/speedoinfraction]

same here, and on a real device plain logcat is a firehose so filtering by your pid helps a ton. native crash first, js second.

[u/MobileXapps]

Good PSA. One more for native crashes that barely show in logcat: the tombstone. On a device you can pull it with adb bugreport, and running the stack through ndk-stack with your unstripped libraries tells you which native library and function crashed. That's usually the fastest way to find which package with native code is the culprit.

And for release builds, make sure the crash reporter you use uploads native symbols, otherwise the production crashes look like random addresses.

[u/royalraju907 → u/MobileXapps]

Thanks u/MobileXapps , good addition. I only covered Java/Kotlin exceptions, where logcat has the whole stack trace. The signal-style crashes in C++ libs are a different beast, and ndk-stack with unstripped libs is the right tool there. And yes on symbols for release builds, otherwise it's just addresses. Appreciate it.

[u/lassieCoder]

Good write-up. One more for the "PID filter shows nothing" problem: Android keeps a separate crash buffer, so `adb logcat -b crash -d` prints only the crash, and it's still there after the process has died. Run it right after the app closes.

A related trap: if JS shows "Cannot find native module 'X'", the real error is often a native one logged a moment earlier (NoClassDefFoundError, UnsatisfiedLinkError). Search the full log for those before debugging the JS side.

Disclosure: I made an open-source CLI that reads a saved logcat (`adb logcat -d > logcat.txt && npx rn-build-doctor analyze logcat.txt`). It pulls out the FATAL EXCEPTION block, and for "Cannot find native module" it shows the native error that came first.

Offline, nothing is uploaded: https://github.com/lassiecoder/rn-build-doctor