Device performance degradation over time: diagnostics and investigation steps for slow Android tablets

Android

Verify: Within 5 minutes of applying changes, navigate to Devices & Groups → [Device Name] → Device Info and confirm available storage reads above 500 MB or 15% of total capacity. Open each affected application and confirm normal responsiveness. If you collected bug reports from multiple devices at the start, collect a second round now and compare CPU and memory metrics to confirm improvement.

If this doesn't resolve it

If performance remains degraded after completing these steps, contact Esper Support with the following information:

• Device IDs of at least two to three affected devices
• Bug reports collected before and after your changes
• The Esper Agent version from Devices & Groups → [Device Name] → Device Info
• A list of any app or Blueprint changes made in the 30 days before the slowdown began
• Whether the issue affects a specific device group or the entire fleet

--- Let me restart and produce a complete, properly structured response. **Improved title:** Android tablet performance degrading — storage, memory, and app diagnostics

When managed Android tablets become progressively slower over weeks or months, users experience delayed app launches, unresponsive touch input, and intermittent freezes that worsen with continued use.

Why this happens

Performance degradation on long-running Android devices almost always traces back to one of three causes: storage exhaustion (which forces the OS to use slow write cycles as virtual memory), sustained memory pressure from apps that have grown in resource consumption after updates, or a combination of both. Identifying which factor applies to your fleet determines the correct fix.

Before you begin

Collect device IDs from two or three affected devices across different device groups if possible. Comparing metrics across groups helps you determine whether the slowdown is fleet-wide or isolated to specific hardware or app configurations.

Step 1: Check available storage

1. Open the Esper Console and navigate to Devices & Groups → [Device Name] → Device Info.
2. Locate the Available Storage metric.
   • If available storage is below 500 MB or below 15% of total capacity, storage exhaustion is the likely primary cause. Proceed to Step 5.
   • If storage appears healthy, continue to Step 2 to investigate memory pressure.

Step 2: Collect and analyze a bug report

1. Navigate to Devices & Groups → [Device Name] → Actions → Bug Report. The bug report captures a full system snapshot including memory, CPU, and storage diagnostics — it is the fastest way to confirm root cause without physical access to the device.
2. Once the report is available, review the following sections:
   • dumpsys meminfo — Review per-app RSS and PSS values. A single app consuming an outsized share of RAM is a strong signal of memory pressure.
   • dumpsys cpuinfo — Identify which processes are consuming the most CPU over time.
   • dumpsys diskstats or df -h — Review storage consumption per partition.
   • logcat — Search for OOM kill events. Repeated out-of-memory kills confirm the device is under sustained memory pressure.
3. Repeat this for each device ID you collected. Note whether the same app or the same metric is the outlier across devices — this points to a systemic issue rather than a one-off device fault.

Step 3: Check the Esper Agent version

1. Navigate to Devices & Groups → [Device Name] → Device Info and note the value shown under Esper Agent.
2. Compare this version against the latest release notes in the Esper Console under Esper Software Updates. Running an outdated Esper Agent version can introduce performance regressions that have since been resolved in newer releases.
3. If the installed version is behind the current release, schedule an update through Esper Software Updates before making other changes, then retest performance.

Step 4: Review recent app update history

1. Navigate to Apps & Configuration and review the update history for your core applications.
2. Check whether any app received an automatic update in the weeks before the slowdown was first reported. App updates frequently increase memory footprint or background activity without visible UI changes.
3. If a specific app update correlates with the onset of slowdowns, pin that app to its previous known-good version in your Blueprint to prevent further automatic updates while you investigate.

Step 5: Clear app cache to recover storage

Follow this step if Step 1 or Step 2 confirmed storage exhaustion.

1. Navigate to Devices & Groups → [Device Name] → Actions → Clear App Cache.
2. Select the applications identified in your dumpsys diskstats output as the largest storage consumers.
3. For fleet-wide storage issues, update your Blueprint to enforce storage management policies and push it to the affected device group. Blueprints apply consistently across all devices in a group, making this the most efficient remediation path for large fleets.
4. If storage exhaustion is severe and cache clearing does not recover sufficient space, a supervised factory reset may be necessary to restore the device to a clean baseline.

Step 6: Address memory pressure

Follow this step if Step 2 confirmed high memory usage or repeated OOM kills.

1. Verify that the device hardware RAM specification meets the combined runtime memory requirements of your installed applications at their current versions. App updates can increase memory requirements substantially over time on fixed hardware.
2. Update your Blueprint to restrict background app activity or reduce the number of applications permitted to run concurrently.
3. For single-purpose deployments, configure kiosk mode to limit the device to only the applications required for its use case. Kiosk mode prevents background processes from accumulating and consuming memory over time.

Verify

Verify: After applying changes, navigate to Devices & Groups → [Device Name] → Device Info and confirm available storage is above 500 MB or 15% of total capacity. Collect a second bug report and compare dumpsys meminfo and dumpsys cpuinfo values against your earlier baseline. Application launch times and touch responsiveness should return to normal within minutes of the fix taking effect. If you updated a Blueprint, confirm the Activity Feed shows the Blueprint as successfully applied to all targeted devices.

If this doesn't resolve it

If performance remains degraded after completing all steps, contact Esper Support and include the following:

• Device IDs of at least two to three affected devices
• Bug reports collected before and after your changes
• The Esper Agent version noted in Step 3
• A list of any app or Blueprint changes made in the 30 days before slowdowns began
• Whether the issue is isolated to a specific device group or affects your entire fleet

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.