What is Android Test Orchestrator and how does it isolate tests?

WHAT THIS TESTS: This question probes whether you understand the difference between test runner architecture and process isolation on Android, specifically why the default shared Instrumentation process makes large UI suites brittle. Interviewers want to see that you can connect a testing tool to the underlying OS process model and explain cascading failure modes in concrete terms.

A GOOD ANSWER COVERS: First, define the Android Test Orchestrator as a testing tool that works with AndroidJUnitRunner to execute each UI test in its own Instrumentation process. Second, identify the core problem it solves: shared process state across tests means a crash, native heap corruption, or unclosed resource in one test can terminate the entire test run or leak into subsequent tests. Third, explain the isolation mechanism: because the Orchestrator starts a fresh process per test, a fatal exception in test A kills only that process; the Orchestrator then starts a new process for test B, preventing cascading failures. Fourth, mention the trade-off: per-test process startup adds overhead, so suite execution time increases compared to running all tests in a single process.

COMMON WRONG ANSWERS: Calling the Orchestrator a replacement for AndroidJUnitRunner rather than a wrapper that invokes it. Claiming it fixes flaky tests caused by timing or synchronization issues rather than process-level state pollution. Describing the isolation as thread-based instead of process-based, which misses the fundamental OS boundary. Saying it only helps with memory leaks without acknowledging crash recovery. Asserting there is no performance cost.

LIKELY FOLLOW-UPS: How would you decide whether to enable the Orchestrator in your CI pipeline given the runtime cost? What other strategies complement process isolation for test stability, such as clearing application data between tests or using test fixtures? How does the Orchestrator interact with code coverage collection across multiple processes?

ONE CONCRETE EXAMPLE: Imagine a UI test that exercises a camera flow and accidentally leaves a native camera service connection open. In a standard single-process run, the leaked handle persists in the Instrumentation process and causes the next test to fail with a permission or resource conflict. With the Orchestrator enabled, the leaking test finishes, its process dies, and the following test starts in a clean process with no stale handles, so the suite completes successfully.

Source: developer.android.com