Fix "App" Keeps Stopping Error on Android — Fast Triage Guide

The App Won't Stay Up

Your app crashes on launch — or mid-session — and Android plasters a dialog on the screen: "App" keeps stopping. The user taps OK. It crashes again. They tap OK again. You get a Slack message at 2 AM.

This dialog fires when the Android runtime catches an unhandled exception or ANR (Application Not Responding) that kills the process. Root causes range from corrupted cache to OOM kills to a botched APK install. Three very different problems, one identical dialog — so step one is always reading the log.

Quick Debug: Read the Crash Log First

Don't touch any settings yet. Connect the device, enable USB debugging, and pull logcat. The answer is usually staring back at you in the first 10 lines.

# Connect device, enable USB debugging, then:
adb logcat -d | grep -E "(FATAL|AndroidRuntime|E/ActivityManager)" | tail -50

# If the app crashes on launch, watch live:
adb logcat *:E | grep -v "^-"

A typical crash looks like:

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: java.lang.NullPointerException: ...
E AndroidRuntime:   at com.yourapp.MainActivity.onCreate(MainActivity.java:42)

That stack trace points to the exact line. An OutOfMemoryError needs a very different fix than a NullPointerException — don't skip this step.

Check for ANR separately

# ANR traces on older Android versions:
adb pull /data/anr/traces.txt .

# On Android 11+:
adb bugreport bugreport.zip
unzip bugreport.zip && grep -r "ANR" bugreport/

Fix 1: Clear App Cache and Data

Corrupted cache is the most common culprit — especially after an OTA update or an interrupted install that left stale bytecode behind.

# Via ADB — this clears BOTH cache and user data:
adb shell pm clear com.example.yourapp

# To clear cache only (non-root), use the UI:
# Settings → Apps → [App Name] → Storage → Clear Cache

Note: pm clear wipes everything including login sessions and preferences. Use it when you want a fully clean slate. For keeping user data intact, stick to the UI path above.

Verify: Launch the app. Opens clean? Cache was the issue. Still crashes? The log will now show a fresh error without stale state masking it.

Fix 2: Force Stop, Then Relaunch

The process might be stuck — crashed mid-write, holding a file lock, or caught in a partially initialized state. Force-stop kills it cleanly.

# Force stop via ADB:
adb shell am force-stop com.example.yourapp

# Relaunch:
adb shell monkey -p com.example.yourapp -c android.intent.category.LAUNCHER 1

Crash gone after force-stop? Suspect a threading bug or a resource leak from the previous session. It won't fix itself — but now you know where to dig.

Fix 3: Reinstall the APK

A botched install can leave a broken APK on disk that fails on every launch. Common triggers: interrupted download, full storage mid-install, filesystem corruption.

# Uninstall cleanly:
adb uninstall com.example.yourapp

# Reinstall:
adb install -r yourapp.apk

# Or from Play Store: uninstall → reinstall from scratch

For Play Store apps, check whether an overnight auto-update pushed a broken version. Disable auto-updates for that app temporarily, then downgrade to the previous APK from a trusted mirror like APKMirror.

Fix 4: Check Available Storage

A full disk breaks things quietly. Android can't write databases, unpack dex files, or create temp files when /data is nearly full — and the crash log often doesn't make that obvious.

adb shell df -h /data

# Example output:
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/block/...  64G   63G  0.4G  99%  /data  ← This will cause problems

Above 95% used? Clear cache across multiple apps or offload files before retesting. On Samsung and Xiaomi devices, the "low storage" notification sometimes doesn't fire until you're already past the crash threshold.

Fix 5: OOM Kill (Developer Builds)

No clean stack trace in logcat? The process might not have crashed at all — it may have been evicted by Android's low memory killer.

# Check if OOM killer was involved:
adb logcat -d | grep -i "lowmemory\|lmk\|killed"

# Look for entries like:
I ActivityManager: Killing 12345:com.example.yourapp/u0a123 (adj 900): cached #1

That's not a crash. It's eviction. Reduce your app's memory footprint, implement onTrimMemory() callbacks to release bitmaps and caches proactively, or test on a device with at least 4 GB RAM. Bumping the emulator's RAM allocation is a quick workaround during dev.

Fix 6: Compatibility Issue After OS Update

Post-update crashes often hit apps that haven't kept pace with API changes. Pull the target SDK first:

adb shell dumpsys package com.example.yourapp | grep -E "(targetSdk|versionCode|versionName)"

An app targeting Android 6 (API 23) running on Android 14 (API 34) spans 8 major versions of behavior changes. Background process limits, permission handling, and intent restrictions have all tightened significantly across those releases. Either update the app or report to the developer with the exact OS version and device model.

Verification Checklist

App launches without dialog after clearing cache/data
adb logcat shows no FATAL EXCEPTION for the package
App survives background → foreground transition (press Home, return)
App survives orientation change (if applicable)
No lmk / OOM entries in logcat during normal use

Lessons Learned

The "App" keeps stopping dialog is Android's catch-all for process death. Crashes, ANRs, OOM kills — all three look identical to the user. Read logcat before touching device settings. The fix is almost always in the first 10 lines of the stack trace.

In production, don't wait for a bug report. Wire up Thread.setDefaultUncaughtExceptionHandler or drop in Firebase Crashlytics or Sentry. Setting up crash reporting takes about 5 minutes. Reproducing a silent crash locally without one can take days.