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.