What problem does it solve?
Solving “adb pull permission denied” by correctly choosing where test artefacts are written and which extraction path to use (run-as, exec-out, or TestStorage) so CI reliably receives screenshots, logs, databases, and other files.
Core Features & Use Cases
- Moves files device↔host correctly: Uses modern
adb pull/adb push flags like compression (-z/-Z), incremental sync (--sync), and attribute preservation (-a) to speed up repeated transfers.
- Fixes permission failures with the right strategy: Applies the path-permission rules (e.g.,
/data/local/tmp/, /sdcard/, /data/data/<pkg>/ via run-as, and /sdcard/Android/data/<pkg>/files/ for app-owned artefacts on API 30+).
- Retrieves binary artefacts safely: Uses
adb exec-out for binary-clean stdout (including run-as ... cat for single files and run-as ... tar | tar xf - for directory pulls from /data/data/<pkg>/).
- Uses the modern artefact API: Routes per-test outputs through
androidx.test:services TestStorage with -e useTestStorageService true so Gradle collects artefacts into connected_android_test_additional_output/ automatically.
Quick Start
Tell the AI: “I need to pull a failing test screenshot and a binary SQLite DB from my connected device—how should I use adb pull/push, run-as, and exec-out (or TestStorage) so the bytes are not corrupted and CI permissions don’t fail?”