Apps Keep Crashing on Android? The Complete Fix Guide

App crashes come in two completely different diseases that share a symptom. Disease one: a single app crashes, on open or mid-use, while everything else runs fine; the problem lives inside that app's data, its latest update, or its compatibility with your device. Disease two: many unrelated apps crash in the same period; the problem lives below the apps, in a shared component, and the prime suspect has a name: Android System WebView. Treating disease one with disease two's fixes, and vice versa, is how people spend a weekend achieving nothing.

Make the split in one minute. List what has crashed today: one name, or several? If several, do they share anything (all Google apps, all apps showing web content)? Then note when it started, because crashes that began on a specific day trace to something that changed that day: an app update, a system update, a new install, or storage crossing the critical threshold. The Play Store's update history and your notification history are your timeline witnesses.

Also rule out the impostor: an app that closes instantly at launch every single time, without the 'keeps stopping' popup, may be crashing, but a phone that is critically low on storage or memory kills apps silently too, which looks identical. Check free storage first (Settings, Storage): below about 1 GB free, fix storage before any app-level surgery, because storage starvation produces exactly this symptom and no cache clear will cure it.

Work the single-app ladder in order, testing after each rung, and stop when the crash stops. Rung one: force stop and reopen (Settings, Apps, the app, Force stop). This kills any corrupted running state and costs three seconds. Rung two: update the app in the Play Store; developers ship crash fixes constantly, and your crash may already be famous. Rung three, the classic: clear the app's cache (same screen, Storage, Clear cache), which deletes temporary files that corrupt with time and costs no data or logins.

Rung four escalates: Clear data (or Clear storage). This resets the app to its just-installed state, wiping its local settings and logins; your account and cloud content are untouched, but you will sign in again. Crashes born from corrupted local databases, extremely common after interrupted updates, die at this rung. Rung five: uninstall and reinstall, which additionally replaces the app's binaries; combined with a phone restart, this is the complete app-level reset.

Rung six is the honest check people skip: read the app's recent Play Store reviews. If the latest version crashes for everyone on your phone model, the fix is the developer's to ship, and your recourse is waiting, or rolling back by uninstalling updates if it is a preinstalled app. While waiting, check compatibility drift: an old app on new Android, or a new app on old Android, crashes legitimately; the app's Play Store page lists its requirements, and our device info tool shows what your phone offers. Nothing on your side fixes a genuine incompatibility.

Mass crashes across unrelated apps have a short suspect list, and Android System WebView leads it by reputation: it renders web content inside thousands of apps, and a bad WebView release famously took down half the app ecosystem for a day in 2021. The fix is always the same: open the Play Store, search 'Android System WebView', update it, and update Chrome alongside (they ship as a pair). If the Play Store itself is among the crashers, push the updates from play.google.com in a browser, signed into your account, using the remote install button.

Suspect two is Google Play services, the shared layer handling sign-ins, maps, notifications and APIs for most apps. Its failure signature includes the specific popup naming it, plus broad weirdness: locations failing, notifications dead, sign-ins looping. Clear its cache (Settings, Apps, show system, Google Play services, Storage), update it via its Play Store page, and if crashes persist, remove and re-add your Google account to mint fresh tokens. Our Play Store repair article in this section covers this layer in depth.

Suspect three is an overlay or 'helper' app interfering with everything it touches: screen filters, floating assistants, aggressive battery managers and shady VPNs inject themselves into other apps' rendering or networking and produce baffling crashes. The clean test is Safe Mode: hold the power menu's Power off button until Reboot to safe mode appears, confirm, and use the phone normally. Stable in Safe Mode means a third-party app is guilty; uninstall recent installs and overlay-type apps first on reboot. Unstable even in Safe Mode points at system storage or memory, and escalates toward the cache-partition wipe in Recovery and, ultimately, the factory reset with a hardware question mark.

Every crash writes its cause into the system log, and reading it converts guessing into knowing. The tool is logcat, and the workflow is simpler than its reputation: enable Developer options (tap Build number seven times), enable USB debugging, connect to any computer with Android Platform Tools installed, and run 'adb logcat' in the terminal while you reproduce the crash. The scroll is intimidating; the treasure is not: search for 'FATAL EXCEPTION', and the lines below it name the crashing app and the exact reason.

You do not need to understand Java stack traces to profit. The first lines after FATAL EXCEPTION contain the app's package name (confirming which app actually died, sometimes surprising) and a human-readable cause: OutOfMemoryError says the phone ran out of memory (storage/RAM pressure fixes apply); NetworkOnMainThread or timeout flavors implicate connectivity (test on Wi-Fi versus data); SecurityException or permission wording says a permission got revoked (check the app's permissions screen); database or corruption wording confirms the Clear data rung is the right medicine.

Paste the captured log into our Logcat Analyzer and the reading gets easier still: it colors lines by severity, counts fatal errors, and filters the noise so the FATAL block stands out. For intermittent crashes, capture in the moment matters, logcat's buffer wraps quickly, so reproduce the crash while capturing. And when the trace clearly blames the app's own code, attach the FATAL block to your report to the developer; a crash report with a stack trace gets fixed releases faster than a hundred one-star reviews.

Crash-resistant phones share four habits. Storage never critical: keep 15 percent free, because memory pressure is the silent parent of half of all instability; the monthly five-minute cleanup from our storage article maintains this automatically. Updates current, on Wi-Fi, automatically: app crashes are overwhelmingly bugs already fixed in versions you have not installed yet; auto-update over Wi-Fi (Play Store settings, Network preferences) closes the gap without data-plan pain.

App hygiene: install from the Play Store rather than random APK sites, skip cleaner-booster utilities entirely, and be slow to grant overlay and accessibility permissions, which let apps interpose on everything and are the mechanism behind the weirdest cross-app crashes. Review installed apps quarterly and uninstall the unopened; every removed app is a removed failure source. And restart weekly: leaked memory and wedged services accumulate in week-scale time on Android, and the restart is their scheduled funeral.

Finally, know your escalation map so future crashes cost minutes: one app misbehaving gets the ladder (force stop, update, cache, data, reinstall); many apps misbehaving get WebView and Chrome updates first, then Play services, then Safe Mode; and anything surviving all of that gets the logcat five minutes before any drastic step, because the log names the true culprit and routinely saves people from factory-resetting a phone whose only crime was one corrupted app database. The diagnostic tools live free in our Software and ADB category whenever you need them.