adb shell am force-stop: Stop Android Apps from the Command Line

To force-stop an Android app from your computer, run:

adb shell am force-stop com.example.app

That kills every process and service belonging to com.example.app immediately, as if you had opened Settings and tapped "Force stop." It does not delete any of the app's data. This post explains the command, how to find the package name, and how force-stop differs from pm clear and am kill — three commands that look similar and do very different things.

What force-stop actually does

am is the Activity Manager; force-stop tells it to terminate the whole app. Every process, background service, and scheduled alarm registered by that package is torn down. The next time the app launches it starts cold. Crucially, force-stop leaves the app's stored data untouched — accounts, preferences, databases, and cache all survive. Use it when you want a clean restart of the app without losing state: reproducing a cold-start bug, clearing a stuck foreground service, or resetting an app during testing.

You need the package name, not the app's display name. To find it:

adb shell pm list packages

That lists every installed package. Filter it:

adb shell pm list packages | grep whatsapp

Add -3 to list only third-party (user-installed) apps, which is usually what you want:

adb shell pm list packages -3

pm is the Package Manager — the counterpart to am for anything about installed packages.

force-stop vs pm clear vs am kill

These three get confused constantly. The difference is what they destroy.

force-stop — stop, keep data

adb shell am force-stop com.example.app

Terminates all processes. Keeps all data. This is the "turn it off and on again" command.

pm clear — stop and wipe data

adb shell pm clear com.example.app

Stops the app and deletes all of its data — the same as Settings → Apps → Storage → "Clear storage." Accounts are logged out, databases are gone, the app is back to a fresh-install state. Reach for this when you want to test onboarding or reproduce a first-run bug. It is destructive: there is no undo.

am kill — gentle, background only

adb shell am kill com.example.app

Kills the app only if it is safe to kill — roughly, only background processes the system could have reclaimed anyway. If the app is in the foreground, am kill does nothing. It is the least aggressive of the three: useful for simulating memory pressure without the hard teardown of force-stop.

Quick reference

Command	Stops the app	Deletes data	Works on foreground app
am force-stop	Yes	No	Yes
pm clear	Yes	Yes	Yes
am kill	Background only	No	No

Common gotchas

• "Unknown package". You passed the display name instead of the package name. Find it with pm list packages.
• No device found. Check adb devices. The device must be connected with USB debugging enabled and the connection authorized.
• Multiple devices. Target one with -s: adb -s <serial> shell am force-stop com.example.app.
• The app restarts itself. Some apps are woken by push messages or scheduled jobs right after a force-stop. That is expected — force-stop is a point-in-time kill, not a permanent disable.

Scripting it

Because these are one-liners, they slot into test scripts easily. A common reset-between-runs snippet:

adb shell am force-stop com.example.app
adb shell pm clear com.example.app   # only if you want a fresh state
adb shell am start -n com.example.app/.MainActivity

The last line relaunches the app by its main activity.

force-stop vs swiping the app away

Swiping an app off the Recents screen is not the same as force-stopping it. The system may keep some of the app's processes alive, and background jobs or push handlers can wake it again moments later. force-stop is a hard stop: it tears down the processes and holds the app's scheduled alarms and jobs until you launch it again. When you need certainty that the app is truly stopped — before a test, or to clear a wedged state — reach for force-stop, not the Recents swipe.

Do you need root?

No. force-stop, pm clear, am kill, and pm list packages all run over a normal ADB connection with USB debugging enabled. No rooted device or special build is required. That is what makes these commands the fastest way to reset an app during day-to-day development and testing.

Where to go next

If you drive Android testing or device automation with an AI assistant, encoding these commands as a reusable instruction set saves repeating them. Browse the skills catalog or the development category for automation and testing helpers, and check the blog for more command-line notes.