What does Appium's mobile: clearApp remove on Android, and what does it leave behind?

## The mechanism, and which driver owns it `mobile: clearApp` on Android is declared by `appium-android-driver` — the base driver that the **UiAutomator2** driver and the **Espresso** driver both extend — so the command is there whichever of the two you are driving with. It is not one of the commands the UiAutomator2 driver declares in its own execute-method map; that map carries its gesture and window commands. Underneath, the driver performs a **package-data clear**, the `pm clear` operation against the package you name, and it behaves the same on an emulator and on a real device. The parameter is the package identifier of the app under test. For the **museum audio-guide app** that is the same package you would name in `appium:appPackage`. ## What goes A package-data clear empties the package's private data directory. For the audio-guide app that means: - The database of downloaded tours and bookmarked exhibits. - Shared preferences: the chosen language, the resume position in the Renaissance-wing tour, the onboarding-seen flag. - The cache directory, including audio segments the app pre-fetched over wifi. - The files directory and any webview data kept for the in-app exhibit pages. - Anything else the app wrote inside its own sandbox, whichever storage API it used. The app comes back in a first-run state: language picker, empty bookmark list, the prompt offering the first tour download. ## What stays - **The APK.** The app is still installed, still the same build, still signed the same way. This is a wipe, not an uninstall. - **Other packages' data.** Only the package you named is cleared. - **Anything outside the package sandbox** that the app can still reach on the next launch. - **Server-side records.** If the museum's backend still holds the visitor's membership session, a device-side clear says nothing about it — arranging that belongs to the test-data subject. ## Two consequences that show up as flaky cases 1. **The process is stopped.** A package-data clear force-stops the package, so when the call returns the audio-guide app is not running and not in the foreground. A case that clears and then immediately looks for the language picker is querying whatever the device happens to be showing — a launcher, a blank screen, a stale hierarchy. Bring the app back to the foreground before the first find. 2. **Runtime permission grants go with the state.** The microphone grant the audio-guide app needed for exhibit voice search does not survive the clear. The case has to arrange it again; how you grant a permission is the permissions subject, but knowing the clear drops them is squarely this one. ## Using it in a suite - Put the clear at the **start** of a case rather than the end, so a case that dies halfway does not leave the next one guessing what state it inherited. - Pair the clear and the relaunch in the same helper; they are one logical step and separating them is how the empty-hierarchy failure gets in. - Do not use it to paper over ordering assumptions that belong in case design. If a case only passes because another case ran first, clearing state is treating the symptom. - Remember the platform asymmetry when the same helper runs on Apple targets: there the equivalent is a data-container delete, and it exists only on a Simulator. | | Removed by the Android clear | Left behind | |---|---|---| | App binary | no | the APK stays installed | | Private data directory | yes, in full | nothing of it | | Runtime permission grants | yes | nothing of them | | Other packages' data | no | untouched | | Server-side visitor record | no | unchanged | One more distinction is worth holding on to, because interviewers probe it. This is a wipe you perform **inside a running session**, on demand, as many times as a case needs it. It is not the reset policy a session is created with — the capabilities that decide whether a fresh session starts from existing data are a separate mechanism with a separate owner, and they act once per session rather than whenever you ask. Nor is it the Apple mechanism: there the driver deletes the app's data container instead, and only on a Simulator. Keeping those three apart in your head is most of what this subject asks of you, and mixing them up is the fastest way to describe a suite that cannot exist. The short answer for an interviewer: it empties the package's own storage and nothing else, it leaves the app installed but not running, and the permission grants go with the data.