In Appium, what is the difference between the appium:noReset and appium:fullReset capabilities?

juniorshould knowfreq 66%

answer

two capabilities, three reset states
both default to false
one skips clean-up, one uninstalls
Android clears in place, iOS reinstalls

basics

~20 s

appium:noReset tells the driver to skip its between-session clean-up, so the app keeps whatever it stored. appium:fullReset does the opposite and uninstalls the app before the session, so nothing at all survives on either Android or iOS.

solid answer

~40 s

Both are core Appium capabilities read by every driver, both default to false, and both still carry the vendor prefix: appium:noReset and appium:fullReset. Leave both false and the driver does its normal between-session clean-up, so the test begins on the state of a fresh install — on Android that is a data clear in place, on Apple platforms it comes from reinstalling the app the session supplies. Set appium:noReset to true and the driver skips that clean-up and leaves the app installed at teardown, which is the fast, dirty option. Set appium:fullReset to true and the driver removes the app before the session, which is the strongest guarantee and the most expensive one. Setting both true asks for two contradictory things; decide which one you mean.

Both are core Appium capabilities read by every driver, both default to `false`, and both still carry the vendor prefix: `appium:noReset` and `appium:fullReset`. Leave both false and the driver does its normal between-session clean-up, so the test begins on the state of a fresh install — on Android that is a data clear in place, on Apple platforms it comes from reinstalling the app the session supplies. Set `appium:noReset` to `true` and the driver skips that clean-up and leaves the app installed at teardown, which is the fast, dirty option. Set `appium:fullReset` to `true` and the driver removes the app before the session, which is the strongest guarantee and the most expensive one. Setting both true asks for two contradictory things; decide which one you mean.

code

json · 6 lines

json

{
  "platformName": "Android",
  "appium:automationName": "UiAutomator2",
  "appium:noReset": true,
  "appium:forceAppLaunch": true
}

go deeper

for a junior

Be ready to state the defaults and the direction of each flag: both are false out of the box, appium:noReset keeps the app's data, appium:fullReset removes the app first. Know that both need the appium: prefix.

for a middle

Explain what the driver actually does under each setting on Android versus Apple platforms, and why a clean state is a data clear on one and a reinstall on the other.

for a senior

Show that you treat appium:noReset false as a promise worth verifying on Apple hardware, and that you can price a full reset per session on a real-device lane before proposing it.

for a principal

Own where isolation lives: in a driver capability the two platforms honour differently, or in an explicit step your suite runs and can prove. Say which, and defend the run-time cost of the choice.

Two capabilities, one job

noReset and fullReset are declared by Appium's base driver, which means every mobile driver in the family reads the same two names: the Android drivers behind UiAutomator2 and Espresso, and the XCUITest driver on Apple platforms. They are not W3C standard capability names, so a session request sends them prefixed — appium:noReset and appium:fullReset — or nested inside appium:options. Both default to false.

Neither flag describes the app. They describe what the driver may do to the app around the edges of a session, before the first command and after the last one. That is why they belong to session start-up and teardown rather than to anything a test calls while it is running.

The three states you can actually be in

Both false — the default. The driver performs its normal between-session clean-up, so the test begins on the state of a freshly installed app.
appium:noReset: true. The driver skips that clean-up and also leaves the app installed when the session ends. Everything the previous session wrote — databases, preferences, caches, a stored login — is still there when the next one starts.
appium:fullReset: true. The driver removes the app before the session, so nothing survives: not the data and not the binary, which means the build has to be put back for the session to run at all.

Setting both to true asks for two contradictory things at once — skip the clean-up, and uninstall — so read it as a configuration bug rather than a stronger version of either flag.

What the clean-up means is platform-specific

This is where the pair stops being a simple two-position switch, and it is the part an interviewer pushes on. The flags express intent; each platform's driver supplies a mechanism, and the two mechanisms are not equivalent.

	Android drivers (UiAutomator2, Espresso)	XCUITest on Apple platforms
default clean-up, both flags false	the app's data is cleared in place through the package manager, and the app stays installed	a clean container comes from reinstalling the app the session supplies
`appium:noReset: true`	no data clear, app left installed at teardown	no reinstall, app left installed at teardown
`appium:fullReset: true`	the app is removed before the session starts	the app is removed before the session starts
in-session escape hatch	`mobile: clearApp` clears that package's data	`mobile: clearApp` exists but is simulator-only

Read the first row twice. On Android, clean is something the platform can do to an installed app at any moment, so the default costs a second or two and always works, on an emulator and on a phone alike. On Apple platforms the driver's only real lever on a device is install and uninstall, so clean is a side effect of putting the build on again. A session that identifies the app by an already-installed bundle and hands the driver no artifact has nothing to reinstall, and it quietly starts on the previous run's data even though appium:noReset was false.

The Android-only knobs that sit next to them

Two more capabilities live in this neighbourhood on Android and have no Apple twin, which is itself a useful thing to be able to say:

appium:forceAppLaunch — start the app under test again at session start even when appium:noReset is true. You keep the stored data and still get a predictable first screen instead of whatever screen the previous case abandoned.
appium:dontStopAppOnReset — do not stop the app before the session begins, for the cases where killing the process is precisely what you are trying to avoid.

Neither of these changes what is stored on disk; they change whether the process is restarted around it. Confusing them with the reset pair is a common slip, and the absence of an Apple equivalent is why one shared capability block rarely serves two lanes.

Choosing between them for a ferry timetable app

Take a ferry timetable app whose first screen depends on a saved home port and a signed-in account:

Both flags false is the honest default for the Android lane: every session starts on an empty data directory for a couple of seconds' cost.
appium:noReset: true is the fast lane. It is right when session setup dominates run time, or when the cases deliberately build on each other — but isolation is now your suite's responsibility, not the driver's.
appium:fullReset: true is the strongest and the slowest, and it earns its cost on the handful of cases that are genuinely about a first run: the empty timetable, the onboarding screen, the migration from no stored data.

The mistake that survives into production suites is picking one of these once, for both platforms, and assuming the guarantee travels with the value. It does not: the same false that means cleared on Android can mean untouched on an iPhone.

## Two capabilities, one job `noReset` and `fullReset` are declared by Appium's **base driver**, which means every mobile driver in the family reads the same two names: the Android drivers behind UiAutomator2 and Espresso, and the XCUITest driver on Apple platforms. They are not W3C standard capability names, so a session request sends them prefixed — `appium:noReset` and `appium:fullReset` — or nested inside `appium:options`. Both default to `false`. Neither flag describes the app. They describe **what the driver may do to the app around the edges of a session**, before the first command and after the last one. That is why they belong to session start-up and teardown rather than to anything a test calls while it is running. ## The three states you can actually be in - **Both `false` — the default.** The driver performs its normal between-session clean-up, so the test begins on the state of a freshly installed app. - **`appium:noReset: true`.** The driver skips that clean-up and also leaves the app installed when the session ends. Everything the previous session wrote — databases, preferences, caches, a stored login — is still there when the next one starts. - **`appium:fullReset: true`.** The driver removes the app before the session, so nothing survives: not the data and not the binary, which means the build has to be put back for the session to run at all. Setting both to `true` asks for two contradictory things at once — skip the clean-up, and uninstall — so read it as a configuration bug rather than a stronger version of either flag. ## What the clean-up means is platform-specific This is where the pair stops being a simple two-position switch, and it is the part an interviewer pushes on. The flags express **intent**; each platform's driver supplies a **mechanism**, and the two mechanisms are not equivalent. | | Android drivers (UiAutomator2, Espresso) | XCUITest on Apple platforms | |---|---|---| | default clean-up, both flags false | the app's data is cleared **in place** through the package manager, and the app stays installed | a clean container comes from **reinstalling** the app the session supplies | | `appium:noReset: true` | no data clear, app left installed at teardown | no reinstall, app left installed at teardown | | `appium:fullReset: true` | the app is removed before the session starts | the app is removed before the session starts | | in-session escape hatch | `mobile: clearApp` clears that package's data | `mobile: clearApp` exists but is **simulator-only** | Read the first row twice. On Android, clean is something the platform can do to an installed app at any moment, so the default costs a second or two and always works, on an emulator and on a phone alike. On Apple platforms the driver's only real lever on a device is install and uninstall, so clean is a side effect of putting the build on again. A session that identifies the app by an already-installed bundle and hands the driver no artifact has nothing to reinstall, and it quietly starts on the previous run's data even though `appium:noReset` was false. ## The Android-only knobs that sit next to them Two more capabilities live in this neighbourhood on Android and have no Apple twin, which is itself a useful thing to be able to say: - `appium:forceAppLaunch` — start the app under test again at session start **even when `appium:noReset` is true**. You keep the stored data and still get a predictable first screen instead of whatever screen the previous case abandoned. - `appium:dontStopAppOnReset` — do not stop the app before the session begins, for the cases where killing the process is precisely what you are trying to avoid. Neither of these changes what is stored on disk; they change whether the process is restarted around it. Confusing them with the reset pair is a common slip, and the absence of an Apple equivalent is why one shared capability block rarely serves two lanes. ## Choosing between them for a ferry timetable app Take a ferry timetable app whose first screen depends on a saved home port and a signed-in account: 1. **Both flags false** is the honest default for the Android lane: every session starts on an empty data directory for a couple of seconds' cost. 2. **`appium:noReset: true`** is the fast lane. It is right when session setup dominates run time, or when the cases deliberately build on each other — but isolation is now your suite's responsibility, not the driver's. 3. **`appium:fullReset: true`** is the strongest and the slowest, and it earns its cost on the handful of cases that are genuinely about a first run: the empty timetable, the onboarding screen, the migration from no stored data. The mistake that survives into production suites is picking one of these once, for both platforms, and assuming the guarantee travels with the value. It does not: the same `false` that means *cleared* on Android can mean *untouched* on an iPhone.

On Android, which Appium capability relaunches the app under test even when appium:noReset is true?
`appium:forceAppLaunch`. With `appium:noReset` true the Android drivers will attach to the app as they find it, which can mean mid-flow on whatever screen the previous case left. Setting `appium:forceAppLaunch` to true starts the app again anyway, so you keep the stored data and still get a predictable first screen. There is no Apple-platform equivalent capability.
What does appium:fullReset cost on a real-device lane, and when is that price worth paying?
Every session pays a removal plus a fresh install of the build, which on real hardware is tens of seconds and needs the artifact reachable from the session. What it buys is the only guarantee that nothing the previous run wrote survives. Pay it for the few first-run or empty-state cases that need it, not for a whole suite.

saying these in an interview costs you the question

Thinks appium:noReset uninstalls the app before each session
Says a full reset only clears data and never removes the app
Sets both flags true and expects a stronger clean start
Assumes the two capabilities mean the same thing on Android and iOS
Believes a reset wipes device state outside the app under test

In Appium, what is the difference between the appium:noReset and appium:fullReset capabilities?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two capabilities, one job

The three states you can actually be in

What the clean-up means is platform-specific

The Android-only knobs that sit next to them

Choosing between them for a ferry timetable app

▾common follow-ups2 questions

▾red flags5 flags

Two capabilities, one job

The three states you can actually be in

What the clean-up means is platform-specific

The Android-only knobs that sit next to them

Choosing between them for a ferry timetable app

answer

go deeper