extracting-test-artifacts

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?”