Differences between activateApp, terminateApp, closeApp, launchApp driver methods

Hello everyone!
There are the following driver methods which are available for mobile automation: installApp, closeApp, removerApp, terminateApp, launchApp, activateApp.
Could you please describe the main key points of each method and the differences between them?
Or maybe there’s a resource where it is possible to get this info?
If I am using “appium:app” capability (with path to .apk or .ipa file) should I need to use launchApp before each test?

installApp: install the app from the given path or URL to the device under test. Works similarly to the app capability with the difference that the app installation could be performed mid-session. Useful to test app upgrade.

closeApp: closes the automation session, similar to driver.quit API. This API is obsolete and must not be used

removeApp: uninstalls given app identifier from the device under test mid-session. In combination with installApp might be useful to reset app data (iOS does not support any other ways to do that)

launchApp: does things similar to session startup with the provided capabilities. This API is obsolete and must not be used

terminateApp: stops the given app on the device under test if it was running before. Could be useful in combination with activateApp to verify app restart

activateApp: puts the app to foreground if it was minimized or starts a new instance if it was not running. Useful to test minimize/restore scenarios or switching between apps

1 Like

@mykola-mokhnach, thank you for information! Could you, please, clarify one moment:
If I want to install and remove my test app before and after each test, then I can just use installApp and removeApp methods as well, yes? And I do not need to set appium:app capability?
Or another variant is to set appium:app capability instead of installApp method?

These both methods are only callable after the session is created. This means if app capability is provided then app install is performed as part of the session session init procedure.

You may also start a session without app or bundle Id. This way it would be even faster.

the final decision depends on what you want to achieve or to test. Also, note that the support of installApp may vary for different cloud providers

@mykola-mokhnach, thanks for clarification!
The last question:
I have set noReset:false and app capabilities for session. I need to make sure that when I get new .apk or .ipa files from developers team and replace the current .apk/ .ipa file with new one in app capability and start new session then exactly the new app build will be installed on my test device.
Does it work in such way?

It depends on which driver you use.
UIA2 and xcuitest drivers don’t reinstall the app by default if a newer or the same version of it is already installed. This default baviour could be modified in capabilities though

Yes, I am using exactly these drivers. So, for make sure that new app version will be installed I need to use capability fullReset instead of noReset?

@QA_Account I have the same requirement, right now, I have the application stored in my project only and thus it install the app, runs the test and then uninstalls it and closes the emulator. But, my senior is asking me to create a pipeline where, it uploads the new app build instead of old one. I am not sure how to do that?

fullReset will work, although it does many more things. If you only want to enforce app install then try the enforceAppInstall capability

1 Like

@Sparsh_Goyal, sorry, but I don’t know answer on your question. On my project we have launched autotests for mobile app locally and do not use any of CI/CD tools for now.