need to remove autoLanch=false, launchApp(), closeApp(), and resetApp()

[jlipps]

This suite of functionality is outdated and confusing and dangerous. We should remove the routes and driver implementations for these. In their place, users should rely on standard Appium session management (new session + caps, delete session), and the now-reliable app management functions (terminateApp, installApp, activateApp, startActivity, etc...)

---

[update by Kazu]

Alternative

• terminate_app and activate_app to restart the app process
  • Other methods: examples: mobile: terminateApp, mobile: activateApp, mobile: launchApp, mobile: startActivity
• uninstall/install the app to clean the local data In iOS (iOS does not have clear the local data api, so it requires uninstalling the app to do it)
  • For iOS simulators, mobile: clearApp could help -> https://appium.github.io/appium-xcuitest-driver/latest/execute-methods/#mobile-clearapp
• https://github.com/appium/appium-uiautomator2-driver#mobile-clearapp to clear the local data in UIA2
• Espresso driver hasn't supportted resetApp at the beginning

[KazuCocoa]

👍
I forgot since, but non-app and bundleid/apppackage in caps behaves as same as autoLaunch=false.

So, appium has no issue for WPA case as well after removing autoLaunch=false. On iOS, it is just a shortcut of safari on a home screen. It has no bundleid, so to automate it, a user should start a session with homescreen and find the icon, and click it.

[KazuCocoa]

for autoLaunch:

Is it good to remove the caps from https://github.com/appium/appium/blob/2.0/packages/base-driver/lib/basedriver/desired-caps.js#L23-L25 and add this in the migration guide...?
after this, we can remove relevant code https://github.com/search?q=org%3Aappium+autoLaunch&type=code

---

other commands:

Remove them from route.js or return errors first...?
Maybe returning an error message...?

[jlipps]

@KazuCocoa yes sounds like a good plan. as for the other commands, i think we should remove them from basedriver now, without any need for deprecation notice. that will be in the migration guide. then we can remove them from the drivers once the crossover to 2.0 is complete in 6 months or whenever. so if you're using 2.0 now with 2.0 basedriver, you won't have access, but with appium 1.x there will be access until the EOL period.

[nextlevelbeard]

I would argue against the removal ofresetApp.
Strongly.

---

It seems to me that it is working perfectly fine and it is perfectly maintainable for Android.
I realize the same can't be said for iOS/XCUITest/WDA.

Correct me I'm wrong but the app state is clean, including things like local storage, sessions.
This type of cleaning does not occur when using just installApp / removeApp / activateApp, does it?
It's a crucial piece for the test life cycle.

Instead of removing resetApp couldn't we focus on improving / refactoring it?

---

Another thing: Creating sessions takes time and resetApp is a huge time saver

Using resetApp is currently a hell of a lot faster than creating new sessions.
Especially when using cloud vendors.

There's often a limit to concurrent sessions.
There's the very real problem of cloud users competing for public hardware.
Wait times for session creation can be long.

If a user wishes to clean the app state while reusing the same session, for whatever reason, making tests atomic or to speed up test runs, they will be left without any options.

Seems the devs are a bit disconnected from the reality of owning and maintaining an Appium test suite.

---

I don't see enough of an argument to remove this functionality, even if it's for a major version.
Not without addressing these issues and providing alternatives.

[mykola-mokhnach]

This type of cleaning does not occur when using just installApp / removeApp / activateApp, does it?

It does. Actually on iOS uninstalling an app is the only way to cleanup its data

[mykola-mokhnach]

Especially when using cloud vendors.

resetApp is just a workaround for the general session startup performance issue there. I assume cloud vendors could improve their logic for stopping/starting sessions. Basically, if we are talking about pure performance then resetApp call would anyway lose to uninstall/install APIs in scope of a single session

[kdthomas2121]

What is to be used as an alternative to resetApp() in situations where we want resets between tests within the same spec file?

[KazuCocoa]

It depends on your scenario.
If the reset means uninstall/install the app, then you can call uninstall/install APIs.
If you'd like to close/create a new session again as the old espresso driver does, then you can call quite and create again.

[kdthomas2121]

So my scenario is closing and creating a new session each time. Just to clarify this is driver.quit() and driver.create()? Thanks!

[jlipps]

So my scenario is closing and creating a new session each time. Just to clarify this is driver.quit() and driver.create()? Thanks!

This will depend on the client you are using. What @KazuCocoa is saying is that you can just quit and start a new session. You are already doing this. If you want to do it multiple times within one test you might need to rearchitect your test suite so that it happens internally rather than on setup/teardown of each test. That's all up to you; your test architecture is not related to Appium.

[kdthomas2121]

So yea currently we do do that interally, but the actual code which resets the app is the driver.reset(). What I'm asking is what should we migrate to when that's gone? Using WDIO, XCUI and UIAutomator2 currently

[KazuCocoa]

Then, uninstall the app -> install the app -> launch the app should be enough.

[ashokkumarg]

Then, uninstall the app -> install the app -> launch the app should be enough.

@KazuCocoa is there a way to maintain the state of application when performing the above operation. I tried with full reset = false and no reset = true but could not get

[KazuCocoa]

Do you mean via https://appium.io/docs/en/commands/device/app/app-state/ ?

[pedrorfernandes]

I understand the issue regarding session management and this does seem like a better approach, however, I have a use case for autoLanch=false

In my Android + iOS native app test suites, devs use the following setup:

• the autoLaunch=false capability is set
• browser.installApp() the app after the session starts
• test scenario sets up network mocks in a mockserver for the app initial boot
• The app is started (through mobile: launchApp + mobile: startActivity)

If autoLaunch=false is removed, then the app always immediately boots before the test is running, so the mocks can only be set later and then browser.reset() must be called to restart the app, wasting some time

Is this not a valid use case to keep autoLanch=false and the test chooses when to start the app?

[Dor-bl]

@jlipps @KazuCocoa, Should I remove the ResetApp from the dotnet-client or not?

[KazuCocoa]

Eventually yes. Some clients may show deprecation warning. appium/dotnet-client#562 is for the dotnet client.

[Dor-bl]

Yes, I'm aware of that open issue. just I saw some questions whether to keep that one or not.

[slice-karven23]

we are using WebdriverIO for the mobile automation, facing issue with iOS while terminating or activating the app i'm encountering the following error :
Error: Need to implement 'codeFor_activateApp()': undefined at t.getCodeString (file:///Applications/Appium%20Inspector.app/Contents/Resources/app.asar/dist/renderer.e31bb0bc.js:16:1230) at m (file:///Applications/Appium%20Inspector.app/Contents/Resources/app.asar/dist/renderer.e31bb0bc.js:144:596) at c (file:///Applications/Appium%20Inspector.app/Contents/Resources/app.asar/dist/renderer.e31bb0bc.js:144:666) at renderWithHooks (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:16305:18) at updateFunctionComponent (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:19588:20) at beginWork (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:21601:16) at beginWork$1 (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:27426:14) at performUnitOfWork (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:26560:12) at workLoopSync (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:26466:5) at renderRootSync (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:26434:7) at recoverFromConcurrentError (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:25850:20) at performSyncWorkOnRoot (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:26096:20) at flushSyncCallbacks (/Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:12042:22) at /Applications/Appium Inspector.app/Contents/Resources/app.asar/node_modules/react-dom/cjs/react-dom.development.js:25651:13

[slice-karven23]

also

• app is not getting reset even if i use the noReset capability,
• browse.closeApp() is not closing the app

[Portium]

Hi, just a short note about my Appium expirence using real Android devices:

• Appium 1.x using driver.quit was closing the app and the driver
• Appium 2.x with java client 7.x using driver.quit is not closing the app (stays in foreground), so I added before driver.closeApp additonally
• Appium 2.x with java client 8.x using driver.quit is not closing the app, so I added a http api call …appium/close/app additonally

Or is there another way to close (bring in background) the app at test end using java client 8.x on real device?

Regards

[mykola-mokhnach]

@Portium Try shouldTerminateApp capability if you are talking about UIA2 driver

[mykola-mokhnach]

For now the deprecation is done for all major driver but UIA2
Also the API has been removed from major clients

[MishkaTheCub]

There's still no clear instruction on how to replace the driver.resetApp() command when only bundleID is used (.i.e. the app does not get removed and reinstalled before each test; 'bundleId' capability is used instead of 'app'.
Seems like driver.terminateApp(<bundleId>) + driver.activateApp(<bundleId>) does the trick, is that right? We basically try to simulate killing and relaunching the app on iPhones

[KazuCocoa]

yes, terminate/activate is ok for the process restart generally. In case you wanted to clear the local data, you might need to uninstall the app once as iOS. I made some suggestions at the top of this issue #15807 (comment)
Some client deprecation warnings also may have alternative commands.

[hassanabbaskazmi]

hey guys, was navigating through google searches for my problem and i stumbled across this thread. i'll keep it short;

i'm doing some test automation for a hybrid app (based on both Android & iOS) through appium 2.1 with python and python client, on macOS Ventura. a little piece of my struggles led me here which is, 'cleaning the cache/resetting the state' of the app on the iOS platform after each test script/case. initially what i've understood from reading this thread, there is no way of doing said task except removing the app and installing it again. but then again, we're on v2.1 of appium, there might've been a way that i've missed. need some guidance regarding this issue.

Also, i'm making a hybrid automation test suite. meaning, same test script, but will run on iOS or Android depending on whichever platform is detected at the start of the script.

PS.
i'm running test scripts on iOS with just the bundleId, not the app.

[fleytman]

Look to this capabilities

{
  "platformName": "iOS",
  "appium:platformVersion": "16.4",
  "appium:deviceName": "iPhone 13",
  "appium:automationName": "XCUITest",
  "appium:app": "/Users/username/IdeaProjects/myproj/my.app",
  "appium:enforceAppInstall": false,
  "appium:autoLaunch": false,
  "appium:permissions": "{\"en.myapp\": {\"userTracking\":\"YES\", \"location\":\"YES\", \"calendar\":\"YES\", \"camera\":\"YES\", \"contacts\":\"YES\"}}"
  }

In this case.

1. myapp will be installed if the current version of the program is not installed
2. myapp will get the necessary permissions
3. myapp will not launch

If I remove "appium:autoLaunch": false then the app will launch. How can I install the application, get the permissions but not use the autoLaunch function? How can I check that the current version of a program is not installed, but not launch that application?

[eglitise]

@fleytman for checking installation I would probably run ideviceinstaller -l | grep en.myapp. Not sure about permission retrieval, but perhaps libimobiledevice provides some way to extract that, too.

[KazuCocoa]

Perhaps mobile:installApp can have enforceAppInstall option to behave the same installation. (should be a new feature request right now)

Then, starting a new session without app/bundle Id and autoLaunch create a session with do nothing. Then, the session calls mobile:installApp and sets permission/s via mobile:setPermission. You could get what app in installed and the version etc via mobile:listApps for real devices in a session. Internally appium checks the CFBundleVersion value for the version check.

[fleytman]

@fleytman for checking installation I would probably run ideviceinstaller -l | grep en.myapp. Not sure about permission retrieval, but perhaps libimobiledevice provides some way to extract that, too.

Yes, there are ways to implement it yourself, although not very obvious (there is no mobile:shell analog for ios). In my case I use a simulator. But to manage the same permichins, appium has logic when to use simctl and when to use applesimutils. But KazuCocoa correctly suggested that I could mobile:setPermission to use. Alas, there is no convenient java-client wrapper for this, so unless you get into xcuitest-driver's doc it's not so obvious that there is a way.

P.S. I want to make sure that when I make changes to the appium code I don't lose the functionality that is there. In this case it looks like the case I mentioned with enforceAppInstall was not taken into account. But the very situation with the refusal of capabilities requires a lot of changes in the code of current projects, so much so that there are discussions whether it is worth switching to the latest versions of appium at all...