ADB

adb shell pm list packages: Listing and Filtering Installed Apps

Published: July 6, 2026 • Applies to: Android 4.0 and later, no root required

The Play Store app list shows names, not package identifiers, and most Android settings screens hide preinstalled system apps by default. When the actual task is scripting an install, an uninstall, or a permission check, the package name is the only thing that matters, and pm list packages is the fastest way to get it without opening a single settings menu.

Listing Every Installed Package

adb shell pm list packages

Output is one package:com.example.app line per app, covering both user-installed apps and every system component, which on a modern phone easily runs past 300 entries. Piping through grep narrows it to a guess at the name:

adb shell pm list packages | grep spotify

Filtering to Just Third-Party Apps

adb shell pm list packages -3

The -3 flag restricts the list to apps not part of the system image — effectively "everything the user or a previous owner installed," which is the list most people actually want when auditing what is on a device. The complementary flag, -s, shows only system packages instead.

Filtering by Enabled or Disabled State

adb shell pm list packages -d
adb shell pm list packages -e

-d lists only disabled packages, useful for confirming that debloating steps (disabling rather than uninstalling a system app) actually took effect. -e lists only currently enabled packages, the inverse view.

Showing the APK File Path

adb shell pm list packages -f

This appends the APK's on-device install path to each line, in the format package:/data/app/~~hash==/com.example.app-hash/base.apk=com.example.app. It is the fastest way to confirm whether an app is a system APK living under /system/app or /product/app versus a user-installed one under /data/app, without needing root file browser access at all.

Going the Other Direction: Label to Package Name

If the visible app name does not obviously map to a package (a common problem with system apps and OEM-renamed utilities), dump the full package info for a suspected match and check the versionName and applicationInfo block, or cross-reference against dumpsys package packages which prints the full package list along with each entry's declared label in most cases:

adb shell dumpsys package packages | grep -B 2 "com.example.app"

Combining With pm uninstall

Once the exact package name is confirmed, remove it for the current user without root:

adb shell pm uninstall --user 0 com.example.bloatware

Running the list command first before any uninstall attempt avoids the single most common mistake in debloating scripts: guessing a package name from a forum post that was written against a different OEM skin or Android version, and silently failing (or worse, removing the wrong package) because the guessed name does not match this specific device's build.

Scripting a Batch Check Across Multiple Devices

For fleet or lab environments with several connected devices, target each by serial and log results to separate files:

for s in $(adb devices | tail -n +2 | cut -f1); do
  adb -s "$s" shell pm list packages -3 > "packages_$s.txt"
done

This produces one file per device serial, letting a quick diff reveal exactly which third-party apps differ between two otherwise identically provisioned phones — a common need when chasing down a bug that only reproduces on one unit in a test batch.

Checking a Package's Version and Requested Permissions

Once a package name is known, its declared version and permission list are visible without opening the app at all:

adb shell dumpsys package com.example.app | grep -E "versionName|versionCode"

This is a fast way to confirm exactly which build is installed on a device during a bug report, especially when a user reports "the latest version" without specifying what that actually is, and the visible app-store listing does not match the version genuinely running on the affected phone.

Packages Hidden From the Launcher Entirely

Many system packages returned by pm list packages -s have no launcher icon at all and never appear anywhere in the app drawer, since they exist purely as background services, OEM diagnostics tools, or carrier-provisioning components. Seeing an unfamiliar package name in this list does not by itself indicate anything suspicious; cross-referencing the package name against its declared vendor in dumpsys package output is the more reliable way to judge whether an unrecognized system package is legitimate before assuming it needs to be removed.