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

Question

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

jlipps opened this issue 3 years ago · 47 comments

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

Answer 1 · 2021-09-03T22:10:18.000Z

👍
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.

Answer 2 · 2021-09-04T04:51:19.000Z

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...?

Answer 3 · 2021-09-08T17:36:52.000Z

@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.

Answer 4 · 2021-09-17T16:38:01.000Z

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.

Answer 5 · 2021-09-17T18:13:14.000Z

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

Answer 6 · 2021-09-17T18:22:20.000Z

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

Answer 7 · 2021-10-11T15:14:06.000Z

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

Answer 8 · 2021-10-12T06:09:03.000Z

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.

Answer 9 · 2021-10-12T08:56:09.000Z

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

Answer 10 · 2021-10-12T11:29:03.000Z

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.

Answer 11 · 2021-10-12T15:03:59.000Z

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

Answer 12 · 2021-10-12T21:42:21.000Z

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

Answer 13 · 2022-01-27T11:13:07.000Z

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

Answer 14 · 2022-01-27T17:37:08.000Z

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

Answer 15 · 2022-02-02T15:13:56.000Z

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?

Answer 16 · 2022-02-02T17:46:55.000Z

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.

Answer 17 · 2022-02-04T14:47:13.000Z

@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

Answer 18 · 2022-02-04T15:07:10.000Z

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).

Answer 19 · 2022-02-08T21:13:22.000Z

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.

Answer 20 · 2022-02-09T10:40:05.000Z

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

Answer 21 · 2022-03-17T12:33:31.000Z

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?

Answer 22 · 2022-03-17T17:04:57.000Z

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

Answer 23 · 2022-03-17T20:18:30.000Z

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.

Answer 24 · 2022-09-01T00:19:50.000Z

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

Answer 25 · 2022-09-01T07:22:21.000Z

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(?))

Answer 26 · 2022-09-02T20:47:21.000Z

@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

Answer 27 · 2022-09-06T23:40:50.000Z

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...

Answer 28 · 2022-09-29T12:58:09.000Z

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

Answer 29 · 2022-10-01T19:35:47.000Z

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

Answer 30 · 2022-10-12T08:07:02.000Z

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

Answer 31 · 2022-10-13T07:19:28.000Z

To fix the issue where the iOS app doesn't restart with appium 2.0 👀

import { Simctl } from 'node-simctl';
const simctl = new Simctl();

export function resetApp() {
  if (driver.isAndroid) {
    // Android (ALL)
    driver.reset();
  } else if (browserstackExec) {
    // iOS (Browserstack)
    driver.terminateApp('my.super.package');
    driver.removeApp('my.super.package');
    driver.installApp('bs://xxxxx'); // midSessionInstallApps
    driver.launchApp();
  } else {
    // iOS (Local)
    driver.closeApp();
    driver.removeApp('my.super.package');
    driver.installApp('MySuperApp.ipa');
    // Trick is to use simctl (part of appium packages) to force the relaunch of the app
    simctl.udid = (driver.capabilities as any).udid
    simctl.launchApp('my.super.package');
    driver.launchApp();
  }
}

Answer 32 · 2022-10-13T08:01:54.000Z

With iOS it needs reinstall

For iOS, appium internally does the same thing to remove the local data since Apple does not provide the way. Btw, not sure the what the launchApp calls behind the method, it can be activateApp, or https://github.com/appium/appium-xcuitest-driver#mobile-launchapp (if you need to specify process arguments/env ver)

// Trick is to use simctl (part of appium packages) to force the relaunch of the app
simctl.udid = (driver.capabilities as any).udid
simctl.launchApp('my.super.package');

ah.. I read the simulator case. Actually it calls restarting simulator. I thought the simulator also did the same as a real device

Answer 33 · 2023-04-28T13:10:39.000Z

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

Answer 34 · 2023-04-28T16:16:01.000Z

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

Answer 35 · 2023-04-28T16:24:11.000Z

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

Answer 36 · 2023-07-20T05:38:28.000Z

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

Answer 37 · 2023-07-20T05:41:46.000Z

also

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

Answer 38 · 2023-09-02T15:03:32.000Z

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

Answer 39 · 2023-09-02T15:29:29.000Z

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

Answer 40 · 2023-10-19T06:29:37.000Z

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

Answer 41 · 2023-10-26T00:26:10.000Z

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

Answer 42 · 2023-10-26T07:10:30.000Z

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.

Answer 43 · 2023-10-26T18:42:56.000Z

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.

Answer 44 · 2024-02-05T11:17:52.000Z

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.

myapp will be installed if the current version of the program is not installed
myapp will get the necessary permissions
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?

Answer 45 · 2024-02-05T18:05:35.000Z

@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.

Answer 46 · 2024-02-05T19:41:52.000Z

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.

Answer 47 · 2024-02-06T06:22:35.000Z

@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...