Disabling a system/preloaded app via Blueprint Preloaded App State

Android

Title: Preloaded app stays enabled after Blueprint change — how to fix

When a system or preloaded app remains active on a managed device after a Blueprint update, the app continues to appear in the device's app drawer and can still be launched by users.

Why this happens

Blueprint changes to preloaded app states are not applied automatically — the device must receive a Converge command after the Blueprint is published. Additionally, if the package name entered in the Blueprint does not exactly match the app's system package name, the Esper Agent silently skips that entry and leaves the app unchanged.

Before you begin

Confirm the exact package name of the app you want to disable. Package names are case-sensitive. Run the following ADB command to list all system packages on the device:

adb shell pm list packages -s

Locate the package name in the output before making any changes in the Esper Console.

Steps to disable a preloaded app via Blueprint

Open the Esper Console and navigate to Blueprints. Open the blueprint assigned to the target device or group.
Locate the Set State for Preloaded Apps section within the blueprint. This setting controls system and OEM-preloaded apps separately from sideloaded or Play Store apps, which are managed under Apps & Configuration.
Add the exact package name of the app (for example, com.google.android.tag) and set its state to Disabled.
Select Save, then Publish the blueprint. Publishing stages the change but does not yet push it to devices.
Navigate to Devices & Groups, select the target device or group, and trigger a Converge. This pushes the published blueprint configuration to the device and applies all pending changes.

Verify: Once the Converge completes, the app should no longer appear in the device's app drawer. To confirm at the system level, run the following ADB command — the package should appear in the output:

adb shell pm list packages -d

The Converge status in Devices & Groups → [Device Name] should show In Sync within a few minutes of triggering.

Troubleshooting

App is still enabled after Converge: Verify the package name in the blueprint matches the output of adb shell pm list packages -s exactly, including capitalization. Then check the device's compliance status in Devices & Groups → [Device Name]. A non-compliant status may indicate the Esper Agent needs updating via Esper Software Updates, or the device requires a reboot before the change can be applied.
Package name is correct but app remains enabled: Some OEM firmware versions restrict disabling certain system packages regardless of MDM commands. This is enforced at the firmware level and cannot be overridden by the Esper Agent.
Device is offline: The Blueprint change is queued. It will be applied automatically the next time the device comes online and syncs — no further action is required.

Important notes

This feature applies only to system and preloaded apps. Manage sideloaded or Play Store apps under Apps & Configuration in the blueprint instead.
Disabling an app hides and deactivates it — it is not uninstalled. Setting the state back to Enabled in the blueprint and triggering a Converge will restore it.
The target device must be provisioned with Device Owner privileges. Devices without Device Owner cannot apply preloaded app state changes.

If this doesn't resolve it

If the app remains enabled after a confirmed Converge and the package name is verified, collect the following before contacting support:

Device model and OEM firmware version
Esper Agent version (visible in Devices & Groups → [Device Name])
Output of adb shell pm list packages -d
A screenshot of the Set State for Preloaded Apps section in the blueprint
The Activity Feed for the device showing the most recent Converge result

Submit these details to Esper Support for further investigation.

Still need help?

If the steps above don't resolve the issue, submit a support ticket with your device model, Android version, Esper Agent version, and a description of what you've already tried — this helps the support team investigate without a follow-up.