Running Instrumented Tests via ADB — am instrument without Gradle

adb shell am instrument is the underlying command Gradle invokes; running it directly is the right tool for CI scripts that already manage their own APKs, for sharding fan-out across many devices, and for tight-loop debugging of a single test method. The pitfall most CI scripts fall into: omitting -w, which makes the exit code meaningless. The second-most-common pitfall: flipping the orchestrator-target relationship.

When to use this skill

• The user wants a single test method to run from a script: adb shell am instrument -w -r -e class com.example.MyTest#myMethod ....
• The user wants to shard a test suite across N devices using numShards / shardIndex.
• The user is wiring AndroidX Test Orchestrator with clearPackageData true and gets the target/targetInstrumentation order confused.
• The user's CI script reports green when tests actually failed because $? is 0 even though INSTRUMENTATION_STATUS_CODE: -2 shows a failure.
• The user wants the on-device runner to wait for a debugger attach before running tests.

When NOT to use this skill

• The user wants to install or reset the app under test — use ../../apps/installing-and-managing-apps/SKILL.md.
• The user wants to choose a device, wait for boot, or set up Wi-Fi debugging — use ../../devices/connecting-to-devices/SKILL.md and ../../devices/connecting-over-wifi/SKILL.md.
• The user is writing the JUnit4 / AndroidJUnit4 test class itself — use ../../../instrumentation/runner/running-instrumented-tests-with-androidjunit4/SKILL.md.
• The user wants Gradle to do the run for them (./gradlew connectedDebugAndroidTest) — that path also reads instrumentation runner args from testInstrumentationRunnerArguments.