How does the UI automator2 noReset behave from v2.7.0 vs v2.4.7

[Auto81]

appium/appium-uiautomator2-driver#537

Having just updated to uiautomator2 driver (v2.7.0 from 2.4.7) how does the above change now affect devices under test

Have been using

noReset:true
forceAppLaunch:true

Which kept our app under test registered on a device (noReset), and always started our app up into the login screen (forceAppLaunch)

This was applicable to the windows driver and the XCUITest driver too. ie all 3 drivers would force the app to open to the login screen as expected.

however now the android app is staying logged in rather than relaunching the app to the login screen on android.

looks like there is now disparity between the drivers?

[RSM-SBA]

hmm i have never seen that the app is reseted by appium without uninstalling it.
Therefore i use adb for resetting the app

https://appium.io/docs/en/writing-running-appium/android/android-shell/

                      List<String> resetAppArgs = Arrays.asList(
			 "clear",
			 "bundleId"
		 );
		 Map<String, Object> resetAppCmd = ImmutableMap.of(
			 "command", "pm",
			 "args", resetAppArgs
		 );
		 driver.executeScript("mobile: shell", resetAppCmd);

[Auto81]

Yeah we aren't looking to reset the app, just relaunch it. It's been this behaviour across all 3 drivers for years at this point for what i've seen.

Given uiautomator2 = @2.4.7
And test A has left the app logged in after it finishes
When test B driver starts with noReset:true and forceAppLaunch:true
Then test B app should be at the login screen with username already populated, as the app hasn't been reset, just relaunched
**PASSES**

Given uiautomator2 = @2.7.0
And test A has left the app logged in after it finishes
When test B driver starts with noReset:true and forceAppLaunch:true
Then test B should be at the login screen with username already populated, as the app hasn't been reset, just relaunched
**FAILS: The app is still logged in after the test B driver starts. it should be on the login screen with username already populated, as the app hasn't been reset, just relaunched**

[RSM-SBA]

hmm ok no idea sorry. Maybe the app is not killed at the end of the test so that the new test only brings it up to front again in the state the last test has left the app ? That would be my approch, terminateApp() at the end and than at the next test starts activateApp()

[Auto81]

Thanks, i'm sure plenty of options to hack around the change are available, but want to check/confirm before having to do such hacks just for android.

Really more concerned about the changes having resulted in feature disparity between drivers now. Up until this point they've all done the same thing, now uiautomator2 has changed that.

Will wait and see if Appium team have thoughts

[Yurii-Kucheriavyi-WDC]

In my case android app is being terminated each time I quit the driver,
despite I use following capabilities:

"appium:noReset": true,
"appium:forceAppLaunch": false,
"appium:shouldTerminateApp": false

and I would like it to keep running after I quit the driver.

iOS works as expected.

[Yurii-Kucheriavyi-WDC]

@Auto81

"appium:forceAppLaunch": false,

is an iOS ONLY capability
full list: https://github.com/appium/appium-xcuitest-driver#desired-capabilities

You can use

"appium:dontStopAppOnReset": true

from here for UIAutomator2 : https://github.com/appium/appium-uiautomator2-driver#capabilities

[jlipps]

however now the android app is staying logged in rather than relaunching the app to the login screen on android.

This seems like the correct behaviour. noReset means not to reset any app data. So depending on how your app is built it will retain user sessions. If you want to make sure that the app starts in a logged out state, either rely on Appium's reset features, or make sure you log out in the previous session.

[Auto81]

Yeap, have read around a few options, looks likes we can just use a combo of terminateApp() and activateApp() to get the desired starting state.

Thanks for info everyone!