Storage discrepancy between devices on same Blueprint causes Pipeline app update failure

Android

When multiple devices share the same Blueprint but have different amounts of available storage, app updates triggered through a Pipeline can fail on devices where free space is too low to stage and install the APK.

Why this happens

A Blueprint enforces policy settings and app versions, but does not reclaim storage consumed at runtime. Over time, individual devices accumulate app cache, residual APK staging files from interrupted installs, and OEM diagnostic data at different rates — so two devices on an identical Blueprint can end up with significantly different free-space levels. When a Pipeline attempts to push an app update, Android requires enough contiguous free space to download and stage the APK before installation begins; devices below that threshold will fail the update job.

Step 1: Identify which packages are consuming storage

In the Esper Console, go to Devices & Groups → [Device Name] → Overview and select Request Bug Report. This captures a point-in-time snapshot of disk and package state directly from the device.
Download the generated report from Devices & Groups → [Device Name] → Logs & Bug Reports and open it in a text editor.
Search the report for the sections labelled dumpsys diskstats and dumpsys storage. These sections list per-package storage consumption and will show which app is occupying the most space.
Repeat steps 1–3 for each affected device, then compare results side-by-side to confirm which package or packages are responsible for the discrepancy.

Step 2: Clear app cache via ADB

Enable remote ADB on the device if it is not already active, then connect. Confirm the device is visible:
```
adb devices
```
Confirm the exact package name of the app identified in Step 1:
```
adb shell pm list packages
```
Clear the cache for that package. Replace com.example.app with the actual package name. This removes only cached data and does not affect app settings or user data:
```
adb shell pm clear com.example.app
```
Verify available storage has increased:
```
adb shell df -h
```
Confirm the target partition shows at least the APK file size plus 20% additional headroom before proceeding.

Step 3: Re-trigger the Pipeline update

In the Esper Console, go to Pipelines → [Pipeline Name] and select Run. Re-running the same Pipeline stage targets only devices that previously failed, so devices that succeeded are not affected.
Monitor progress under Pipelines → [Pipeline Name] → Run History until the job status shows Success.
Confirm the app version is current on each previously affected device by navigating to Devices & Groups → [Device Name] → Apps and checking the installed version number.

Step 4: Reduce the chance of recurrence

Check whether the offending app has a built-in cache management setting — some apps can be configured to auto-clear cache on restart.
Schedule periodic reboots at the device level via Devices & Groups → [Device Name] → Settings → Reboot, or at the fleet level by updating the Blueprint to include a reboot schedule. Regular reboots allow Android's cache trimming routines to run and reclaim staging fragments from interrupted installs.
After updating the Blueprint reboot schedule, push the updated Blueprint to all affected devices and confirm each device shows In Sync in the Devices & Groups view.

Verify: The Pipeline Run History for the affected Pipeline should show a Success status for all previously failing devices within 10 minutes of re-triggering the run. Each device's Apps tab should reflect the updated app version, and the Activity Feed for each device should log a successful install event.

If this doesn't resolve it

If the Pipeline update continues to fail after freeing storage, the cause may be unrelated to disk space — for example, a corrupted APK in the Pipeline stage, a network timeout during download, or a version conflict in the app configuration. Before contacting support, collect the following:

The Pipeline name and the specific Run ID that failed, visible in Pipelines → [Pipeline Name] → Run History
The device serial number and the output of adb shell df -h at the time of failure
The bug report downloaded from Devices & Groups → [Device Name] → Logs & Bug Reports
A screenshot of the failure status and any error message shown in the Run History detail view

Submit these to Esper Support so the issue can be investigated with full context.

Still need help?

If you're experiencing Pipeline app update failures due to storage discrepancies on your devices, submit a support ticket and include your Blueprint configuration, the specific storage values for each affected device, and the error messages from your failed Pipeline updates.