UiAutomator2 driver allows dealing with the Android lock screen using various APIs. This article describes available APIs and their options.
UiAutomator2 provides the following capabilities to deal with the system lock screen:
- appium:unlockStrategy
- appium:unlockSuccessTimeout
- appium:skipUnlock
- appium:unlockType
- appium:unlockKey
These capabilities could be used to unlock the device under test during the driver session initialization as well as deal with different lock screen types.
Either locksettings
(default since Android 8/API level 26) or uiautomator
(legacy).
The locksettings
strategy uses adb shell locksettings
CLI to deal with different
types of device lock screens. It is fast, reliable, but has one downside: the actual
pin, pattern or password must be temporarily removed in order to unlock the device and restored afterwards.
Setting the strategy to uiautomator
will enforce the driver to use UiAutomator framework in order
to interact with the device's lock screen for various unlock types. It might be slower and less stable in comparison
to the locksettings
strategy, although there is no other alternative if tests are being executed on an older Android version
or the application under test requires the device to constantly maintain display lock settings.
Maximum number of milliseconds to wait until the device is unlocked. 2000
ms by default
The appium:skipUnlock
capability is enabled by default and makes the driver to detect and handle the lock screen
upon session startup if it is present. If the lock screen cannot be detected upon session startup then nothing will be
done. By default, it is assumed the device has a "simple" lock screen, which could be removed by waking up the device.
In case the device has a different type of the lock screen configured in its settings then the information about it
must be provided in the below capability values.
This capability supports the following possible values:
Assumes the device is protected with a PIN code. Expects the appium:unlockKey
to contain a valid pin consisting
of digits in range 0-9, for example 1111
.
Same as pin, but uses ADB instead of UiAutomator framework to enter the actual pin value.
Assumes the device is protected with a password. Expects the appium:unlockKey
to contain a valid password consisting
of latin characters, for example abcd1234
.
Assumes the device is protected with a secret pattern. Check the example below for more details on the appium:unlockKey
value for this particular unlock type.
Let say you have a device that is locked with a pattern similar to the one on the image below, and you want to run a test over that device.
We treat the pattern pins similarly to numbers on a digital phone dial. So, in this case the unlockKey is 729854163
and capabilities are:
{
"appium:unlockType": "pattern",
"appium:unlockKey": "729854163"
}
There is also a possibility to interact with the device's lock screen while the test session is running. Use the following mobile extensions for this purpose: