AndroidDevOpsTools

Make Old Android Devices Fast Again: A Dev’s 4-Step Maintenance Script

UUnknown

2026-03-07

9 min read

Turn a 4-step cleanup into a reproducible shell toolkit to refresh Android test devices before automated runs.

Make old Android devices fast again: a dev’s 4-step maintenance script for test farms

Hook: If your automated tests slow to a crawl because test devices are clogged with leftover apps, caches, and background services, you don’t need to buy new phones — you need a reproducible, safe maintenance toolkit. This article turns a proven 4-step user routine into a shell-script toolkit that developers and QA teams can run automatically before test runs to restore responsiveness and cut flaky failures.

Why this matters in 2026

Device pools and physical test farms are back in focus in 2026. With increased emphasis on real-device testing for AI-driven UX, privacy-related behavior differences, and hardware-attached sensors, many teams maintain dozens or hundreds of legacy devices. Late-2025 platform changes (modular APEX updates, stricter package install policies) have tightened how system components are handled — but the core problem remains: cached state, unused apps, and accumulation of test artifacts make devices slow and flaky.

This guide gives you a reproducible 4-step routine plus ready-to-use scripts you can drop into CI (GitHub Actions, Jenkins, Buildkite). It works with Android device farms running Android 12–16 era builds and supports both non-root and optional root/bootloader flows for teams that manage reflashes.

The 4-step routine (developer version)

At a high level, convert the user routine into these actionable steps that are safe for automation:

Quick cleanse: clear app caches, kill runaway processes, and free /cache and /data/tmp without wiping user data.
Remove test cruft: uninstall or disable test-only apps and background services injected by previous runs.
Factory-level reset or reflash (optional but recommended for flaky fleets): perform a user data wipe or fastboot reflash to ensure a pristine system image.
Performance tuning & provisioning: set animation scales, disable throttling, provision required test certificates and install the test APKs.

When to choose quick vs full refresh

Quick refresh: run between short test cycles or on devices used interactively — fast and non-destructive.
Full refresh / reflash: schedule nightly or weekly for devices that run many different test suites or show increasing flakiness — destructive and slower but guarantees consistency.

Practical scripts: ready-to-run boilerplate

Below are three shell scripts that implement the 4-step routine. Each is written for Linux/macOS environments with platform-tools in PATH. They include safety checks, logging, and non-interactive flags for CI.

Prerequisites

Install Android platform-tools (adb, fastboot) on your CI runner or machine.
For reflashing: unlocked bootloader or vendor-signed fastboot workflow.
Udev rules on Linux so devices show up without sudo, or run CI runners with proper permissions.
Device-specific images if you reflash — keep them in a secure artifact store.

1) quick-refresh.sh — non-destructive, safe

# quick-refresh.sh
set -euo pipefail
LOG=/tmp/device-refresh-$(date +%s).log
DEVICE=${1:-}

if [ -z "$DEVICE" ]; then
  echo "Usage: $0 " >&2
  adb devices
  exit 2
fi

echo "Starting quick refresh for $DEVICE" | tee $LOG
adb -s "$DEVICE" wait-for-device

# 1. Stop animations to speed UI
adb -s "$DEVICE" shell settings put global window_animation_scale 0.0
adb -s "$DEVICE" shell settings put global transition_animation_scale 0.0
adb -s "$DEVICE" shell settings put global animator_duration_scale 0.0

# 2. Clear app caches for installed user apps (non-root)
PKGS=$(adb -s "$DEVICE" shell pm list packages -3 | sed 's/package://')
for p in $PKGS; do
  echo "Clearing cache for $p" | tee -a $LOG
  adb -s "$DEVICE" shell pm clear $p | tee -a $LOG || true
done

# 3. Force-stop and remove stray background processes
adb -s "$DEVICE" shell "ps -A -o pid,comm | grep -E 'uiautomator|monkey|rerun' || true"
# (Add device-specific kill commands here if needed)

# 4. Clear system caches where possible
adb -s "$DEVICE" shell su -c 'rm -rf /data/cache/* /cache/* /data/tmp/*' || true

# 5. Reboot to settle changes
adb -s "$DEVICE" reboot
adb -s "$DEVICE" wait-for-device

echo "Quick refresh completed for $DEVICE" | tee -a $LOG

Notes: This script targets non-root devices and falls back gracefully where commands require elevated privileges. It’s intended for a pre-test hook that finishes within a minute on responsive devices.

2) full-refresh.sh — factory reset + provisioning (destructive)

# full-refresh.sh
set -euo pipefail
DEVICE=${1:-}
if [ -z "$DEVICE" ]; then
  echo "Usage: $0 " >&2
  exit 2
fi

echo "Starting full refresh (factory reset) for $DEVICE"
adb -s "$DEVICE" wait-for-device

# Ensure ADB is authorized
adb -s "$DEVICE" shell getprop ro.build.version.release || true

# Wipe user data (factory reset)
adb -s "$DEVICE" shell am broadcast -a android.intent.action.MASTER_CLEAR

# Wait for device to boot back up (this can take a few minutes)
adb -s "$DEVICE" wait-for-device

# Optional: install provisioning APKs and test suite
# adb -s "$DEVICE" install -r /path/to/test-provision.apk

# Reboot to ensure a clean state
adb -s "$DEVICE" reboot
adb -s "$DEVICE" wait-for-device

echo "Full refresh completed for $DEVICE"

Notes: Use the MASTER_CLEAR broadcast with caution: it wipes user data and some settings. Some OEMs block this; in that case you may need recovery-based wipes or fastboot commands.

3) reflash.sh — when you need a pristine system image

# reflash.sh
set -euo pipefail
DEVICE=${1:-}
IMG_DIR=${2:-}

if [ -z "$DEVICE" ] || [ -z "$IMG_DIR" ]; then
  echo "Usage: $0  " >&2
  exit 2
fi

echo "Preparing to reflash $DEVICE with images from $IMG_DIR"

# Reboot to bootloader
adb -s "$DEVICE" reboot bootloader
sleep 3

# Wait for fastboot
fastboot -s "$DEVICE" devices

# Example flash sequence (device/vendor specific)
fastboot -s "$DEVICE" flash boot "$IMG_DIR/boot.img"
fastboot -s "$DEVICE" flash system "$IMG_DIR/system.img"
fastboot -s "$DEVICE" flash vendor "$IMG_DIR/vendor.img" || true
fastboot -s "$DEVICE" erase cache
fastboot -s "$DEVICE" reboot

# Wait for device online
adb -s "$DEVICE" wait-for-device

echo "Reflash completed for $DEVICE"

Notes: Flash sequences differ by OEM. Many modern devices require signed images or special flashing tools. Reflashing is the most robust way to eliminate flaky system-level issues.

Automation patterns and CI integration

Integrate these scripts as a pre-test job to guarantee consistency across runs. Best practices:

Run quick-refresh as a pre-test step for every suite run (10–60s).
Schedule full-refresh nightly or after batches that fail above a threshold.
Keep a signed-system artifact repository if you reflash; snapshot images with dates to reproduce failures.
Expose per-device metadata (model, Android version, last refresh time) via a small inventory DB to pick targets smartly.
Log outputs centrally so you can correlate a device’s refresh history with test flakiness.

Sample GitHub Actions step (concept)

jobs:
  refresh-device:
    runs-on: ubuntu-latest
    steps:
      - name: Setup platform-tools
        uses: reactivecircus/android-emulator-runner@v2
      - name: Refresh device
        run: ./scripts/quick-refresh.sh "$DEVICE_SERIAL"

Advanced strategies & tuning (2026)

In 2026, several trends affect how you maintain devices:

Zero-touch provisioning & ephemeral profiles: Many fleets adopt ephemeral device profiles that re-provision on boot — ideal for test farms.
Increased sandboxing and APEX modules: System components can be updated separately. When you reflash for consistency, ensure matching APEX modules.
Privacy and install restrictions: Android tightened sideload and app-install policies in late 2025; make sure provisioning passes through test signing or enterprise provisioning if needed.

Use these extra tuning knobs where allowed:

Disable background jobs and battery optimizations for test users: adb shell dumpsys deviceidle and battery settings toggles.
Set animation scales to 0.0 (already in quick-refresh) to speed UI interactions.
Pre-warm ART by installing and invoking your test app’s main flows, reducing first-run JIT/dexopt spikes.

Optional root/privileged steps

If your lab manages rooted devices, you can add more deterministic cleanup:

Delete Dalvik/ART caches: rm -rf /data/dalvik-cache/* or use recovery wipe.
Change CPU governor or thermal throttling for repeatable performance (be mindful of hardware safety).
Use pm uninstall --user 0 to remove preinstalled system apps from the primary user.

Pro tip: Don’t change CPU/thermal settings on shared production hardware unless your hardware owner agrees — you can introduce non-deterministic behavior if throttling is disabled.

Troubleshooting and common pitfalls

ADB authorization fails: ensure device has RSA keys accepted, or use USB multiplexers with per-run pairing configs.
Factory reset blocked by device owner: OEM or MDM policies can block wipes; coordinate with your fleet manager or use profile-specific resets.
Fastboot not accessible: Many devices use locked bootloaders or vendor-specific tools — keep device-specific instructions in your repo.
Reflashed device missing OTA/Apex mismatch: make sure to flash matching vendor/system images and include vendor bootloader combos.

Case study: stabilizing a 50-device lab

In our programmatic test lab, a handful of older Pixel 3/4 and mid-range devices became sources of 30–60% of flaky UI failures. After codifying the above 4-step routine into a nightly full-refresh and a per-run quick-refresh, we observed:

Substantial drop in first-run timeouts (most reduced by 40% within two weeks).
Faster median device response time during UI tests thanks to disabled animations and cleared caches.
Cleaner test artifacts and fewer hidden permission dialogs — provisioning APKs installed in the post-reset phase solved intermittent permission prompts.

Key lesson: automation of device maintenance is as important as automation of tests. Treat device state as part of your test fixture — and version it.

Actionable takeaways & checklist

Implement a non-destructive quick-refresh step for every test run (clear caches, disable animations, reboot).
Schedule nightly full-refresh runs that factory-reset and reprovision devices used for cross-suite testing.
Use reflash only when you need pristine system-level reproducibility; maintain image artifacts and vendor compatibility notes.
Integrate scripts into CI and log per-device refresh events so you can correlate with test outcomes.
Keep non-root flows first; add root/bootloader steps only for dedicated lab devices with clear ownership policies.

Downloads & boilerplate

Grab the scripts above and a companion README that documents device-specific flash sequences and CI examples. Keep versions of each script alongside the images they operate on and the device metadata.

Final warnings and best practices

Back up any important logs or configuration before full wipes.
Don’t reflash production devices — use a dedicated test pool.
Document device-specific exceptions in your maintenance repo so new team members can follow safe procedures.

Next steps (call to action)

Start by dropping the quick-refresh.sh into your CI pre-test step this week. If you manage a larger fleet, schedule a weekly full-refresh and track flakiness trends for 30 days. Want the full boilerplate (CI snippets, udev rules, device inventory schema)? Download the tested repo on our resources page, try the scripts on a single sacrificial device, and share results in our developer community for feedback.

Join the conversation: share your device model quirks and flash sequences — we’ll curate a vendor compatibility matrix so teams can reuse safe defaults. If you want the scripts adapted to your lab (Windows runner, cross-platform runner, or air-gapped lab), reply with your device inventory and CI environment and we’ll provide a tailored starter.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.