In Appium on Android, when should a test start a named activity instead of activating the whole app?

## Two different meanings of *start* on Android The Android drivers give a suite two ways to put the app under test in front of the user, and they are not variations of each other. - `mobile: activateApp` works at whole-app granularity. Given the package name it brings that app forward: if a task already exists, it resumes on the screen it left; if nothing is running, the app starts at its normal entry point. - `mobile: startActivity` works at component granularity. It asks the platform to start one named screen of the app, which is the same idea the `appium:appActivity` capability expresses when it tells a session which screen to open at start. The difference matters because they answer different questions. *Get me back into the app* is `mobile: activateApp`. *Get me onto this specific screen without walking there* is `mobile: startActivity`. A suite that reaches for the second when it meant the first quietly loses the resume behaviour that a background-and-restore case depends on. ## What starting a component buys, and what it costs In a driver-facing school bus tracking app, the route-map screen sits behind a depot sign-in and a route picker. A case about map rendering that walks those two screens every time pays for them on every device in the matrix. Starting the route-map activity directly removes that cost. The bill arrives elsewhere: - **Coupling to internals.** The suite now names a component the app team considers private and may rename in any refactor, with no contract and no deprecation. A locator break is obvious; a component-name break looks like an infrastructure failure. - **Missing state.** The screens you skipped were doing work — selecting a route, priming a session, caching a stop list. Entering part-way means that work did not happen, and arranging it another way is a test-design decision rather than a driver one. - **Not every screen is startable.** Whether a given activity can be started from outside the app is a property of the app's own manifest, which is the Android platform's subject rather than Appium's. A screen the app never intended to expose may simply refuse. - **Two drivers, two signatures.** The UiAutomator2 driver and the Espresso driver each declare their own `mobile: startActivity`, with their own argument shapes. Read the reference for the driver you are actually running rather than assuming one signature covers both. ## The Apple platforms have no twin The XCUITest driver ships `mobile: launchApp`, and that command starts the app — the whole app, at its own entry point. There is no XCUITest execute method that starts one inner screen the way `mobile: startActivity` does. Getting into an Apple build part-way through a flow is a URL-entry problem and belongs to that part of the toolkit, not to the lifecycle commands. This is a real asymmetry, not a gap to paper over. A cross-platform suite that offers a single *open the route map* helper will have one implementation that starts a component and one that does something structurally different, and pretending otherwise hides the difference exactly where a reader needs to see it. ## Choosing between them A usable rule for a mixed suite: 1. Default to `mobile: activateApp`. It is portable, it resumes rather than restarts, and it does not know anything about the app's internals. 2. Reach for `mobile: startActivity` only when the walk-there cost is large **and** the case is genuinely about the target screen rather than about the journey to it. 3. Keep every component name in one place in the framework. When the app team renames a screen, one file changes. 4. Never let a component start silently substitute for the setup the skipped screens performed. If the case needs that state, arrange it explicitly. 5. Do not build an Apple branch that pretends to do the same thing. Name the difference in the code. ## Confirming where you landed On Android, `mobile: getCurrentActivity` and `mobile: getCurrentPackage` tell you which component is actually in front, which turns *the tap did nothing* into *we were never on that screen*. Both are Android-only. On Apple platforms the equivalent confidence comes from `mobile: queryAppState` for the app as a whole plus an assertion on something the target screen owns. Either way, confirm the landing before the first find: a component start that quietly failed and an element that has not rendered yet look identical from a find failure alone.