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?

[KazuCocoa]

Do non-app and bundleid/appActivity instead of autoLaunch not help? Then http://appium.io/docs/en/commands/device/app/install-app/ can install an app.

[pedrorfernandes]

@KazuCocoa yes they do work locally and in our grid, the only issue is with cloud vendors such as browserstack, they enforce an app in the capabilities that was previously uploaded and verified through their API. Basically, installing the app during a test is forbidden.

So without autoLaunch: false, the only way around this is to close the app after the session starts and open it again when the test begins

EDIT: https://www.browserstack.com/docs/app-automate/appium/advanced-features/test-app-upgrades Actually it seems that it's possible to install the app during the test with this workaround

[jlipps]

Yeah I was going to say, better for cloud services to figure out how to support commands like installApp and starting sessions without apps (or using just built in apps).

[jlipps]

another option could be for cloud providers to implement their own handling of some cloud:autoLaunch=false scenario, though that would be more work for them.

[pedrorfernandes]

tbh the cloud vendors should perfectly be capable of handling the missing app capability, if browserstack has browserstack.midSessionInstallApps, then this is perfectly possible, they simply did not implement it, so i'll raise that ticket with them.

Don't know about other vendors, but I guess that if app capability is not mandatory as an appium standard, they should respect that

[nextlevelbeard]

If we are using simply the bundleId to run tests, without an app capability, how do we clean the app state between tests? Assume you don't have a local app file (.app or .ipa) that matches the exact revision of the installed version.

Before I would invoke resetApp, the app state would be cleaned for the next test. Now, to invoke removeApp, is fine, but you can't re-install it...

How to handle this use case?

[KazuCocoa]

https://github.com/appium/appium-uiautomator2-driver#mobile-clearapp is for UIA2. iOS cannot clean the local state without reinstalling it.

[jlipps]

If we are using simply the bundleId to run tests, without an app capability, how do we clean the app state between tests?

@KazuCocoa is right, you can't. I would be surprised if resetApp actually did anything in that scenario on iOS.

[MishkaTheCub]

Similar situation as @nextlevelbeard described. We are using bundleId to launch a session and resetApp() is used to basically kill and relaunch the app to retry a test if something went wrong. Right now it works on iOS using Appium 1.22.3 server and java-client 7.6.0. So how come this won't work anymore? This change will break a lot of existing tests. We will need a KB page somewhere on how to transition the tests to the new version that has a lot of things that work deprecated

[KazuCocoa]

Did terminateApp/activateApp work?

I thought java client was already showing deprecation marks for long, https://github.com/appium/java-client/blob/bd66144e8a15ec9bbe1af8a4c25087d527b79e90/src/main/java/io/appium/java_client/SupportsLegacyAppManagement.java#L44 (potentially it was since v8(?))

[MishkaTheCub]

@KazuCocoa I'm currently using java_client v7 and it's not showing deprecation marks. Once I switch to v8 these methods just don't exist and I can't figure out a workaround for them. I see they are in InteractsWithApps class but don't understand how to call them

[jlipps]

I'm not sure about the Java client, but both the iOS and Android drivers offer much better and more targeted ways of closing apps. Look in the docs for those drivers for mention of things like terminateApp, launchApp, startActivity, etc...

[hariabhay1353]

removeApp method is not showing in Appium 2.0.is there any replacement method for that.

[KazuCocoa]

removeApp should remain. What driver did you use? (if you have the appium log, can you share it as GIST?) @hariabhay1353

[amedvedjev]

what about reset app as part of test NOT driver start? It really easy and fast for Android. With iOS it needs reinstall. for iOS it works for me: removeApp -> terminateApp -> launchApp