MDM allow-list basics: Android package names for administrators

Every Android management tool, whether it is an enterprise mobility suite, Google's Android Management API or a simple kiosk launcher, identifies apps by package name. A policy that says "allow Samsung Wallet" or "block the carrier app" needs the exact name behind it. This guide covers the names that matter, the ones a managed device cannot lose, and how to pull a device's list so your policy matches the hardware.

Why do allow-lists need package names?

A display name is a label that changes with language, region and version. A package name, such as com.android.vending for the Play Store, is the app's fixed ID on every device. Management APIs act on that ID: install it, block it, allow it in lock task mode, or set it as the default for an action. Get one character wrong and the policy silently does nothing.

The package lookup returns the package name for a display name and the reverse, and every package page has a stable URL you can cite in a policy document.

Which packages does a managed Android device need?

Whatever your allow-list says about user apps, these must stay enabled on a Google-certified device:

• com.google.android.gms: Google Play services. Enrollment, account sign-in, push messages, location, Play Integrity checks and Play Protect run through it.
• com.android.vending: the Play Store. Managed Google Play installs and updates approved apps through it, even when users never see the store.
• com.google.android.apps.work.clouddpc: Android Device Policy, the device policy controller used by the Android Management API and many management suites. Your suite may use its own controller instead.
• com.google.android.gsf: Google Services Framework, which supports account and messaging services.
• com.google.android.webview: Android System WebView. Many apps, and many sign-in pages, render web content through it.
• A keyboard, such as com.google.android.inputmethod.latin (Gboard). A device with no enabled keyboard cannot take a password.
• com.android.systemui and com.android.settings, even on kiosks. Lock task mode can hide them from the user without disabling them.
• The phone stack on devices with a SIM: com.android.phone and the dialer. Emergency calls must keep working.

Play Protect is not a separate app. It is part of Play services and the Play Store, so it stays on as long as those two are allowed.

How do kiosk and dedicated-device policies use package names?

With the Android Management API, each entry in the applications list of a policy has a packageName and an installType:

• FORCE_INSTALLED installs the app and stops the user removing it.
• PREINSTALLED installs the app but lets the user remove it.
• AVAILABLE lets the user install it from managed Google Play.
• BLOCKED prevents installation and uninstalls it if it was installed under an earlier policy.
• REQUIRED_FOR_SETUP makes setup fail unless the app installs.
• KIOSK runs the app as the device's only home screen.

The policy's Play Store mode decides the default: with an allow-list mode, only apps named in the policy are available and anything else is removed; with the block-list mode, everything is available except apps marked BLOCKED.

Outside that API, Android's own lock task mode works the same way. A device policy controller passes a list of package names to the system, and only those apps can run while the device is locked to a task. Any app that the kiosk app opens, such as a browser or a payment app, has to be on the list too.

What breaks if I block the wrong system package?

The common failures:

• Enrollment fails or stalls when Play services, the Play Store or the device policy controller is disabled.
• Apps stop updating when the Play Store or the maker's update client is blocked.
• Sign-in screens go blank when WebView is disabled.
• Users cannot type a password when the only keyboard is blocked.
• Emergency calls fail when the dialer or telephony packages are removed from a kiosk with a SIM.

Each package page on this site carries a verdict. Anything marked Keep or Do not remove belongs on your never-block list.

How do I export a device's package list?

Use ADB from a computer with USB debugging turned on (see how to set up ADB). For the system packages, then for everything with the file each one lives in:

adb shell pm list packages -s > system-packages.txt
adb shell pm list packages -f > all-packages-with-paths.txt

A work profile is a separate user with its own number. Find the number, then list that user's packages:

adb shell pm list users
adb shell pm list packages --user 10

To record the version of one package for change control:

adb shell "dumpsys package com.google.android.webview | grep versionName"

Most management consoles also export an app inventory per device. Compare the two lists the first time to make sure the console sees system apps.

How should I handle different brands?

Google and Android packages are the same across brands. Maker packages are not: Samsung, Xiaomi, OnePlus and Motorola each ship their own launcher, update client, security services and extras, and carrier models add more. Export the list from one device of each model and Android version you deploy, then paste it into the package-list audit to see the verdict for each line. The brand hubs, starting with Samsung, list every documented package by category, and the category hubs group them by job, such as telephony or security.

Samsung devices also support Knox, which adds its own controls for apps and system features. Treat any package with knox in its name as Keep.

In a work profile, Android enables only a small set of system apps by default. If users need a system app inside the profile, such as the camera or the calendar, enable it through your policy rather than expecting it to appear.