Skip to content

Commit

Permalink
docs: Document unlock better (#734)
Browse files Browse the repository at this point in the history
  • Loading branch information
mykola-mokhnach committed Feb 7, 2024
1 parent bb0cace commit f12004e
Show file tree
Hide file tree
Showing 4 changed files with 100 additions and 5 deletions.
10 changes: 5 additions & 5 deletions README.md
Expand Up @@ -143,11 +143,11 @@ appium:noSign | Set it to `true` in order to skip application signing. By defaul

Capability Name | Description
--- | ---
appium:skipUnlock | Whether to skip the check for lock screen presence (`true`). The default driver behaviour is to verify the presence of the screen lock (e.g. 'false' value of the capability) before starting the test and to unlock that (which sometimes might be unstable). Note, that this operation takes some time, so it is highly recommended to set this capability to `true` and disable screen locking on device(s) under test.
appium:unlockType | Set one of the possible types of Android lock screens to unlock. Read the [Unlock tutorial](https://github.com/appium/appium-android-driver/blob/master/docs/UNLOCK.md) for more details.
appium:unlockKey | Allows to set an unlock key. Read the [Unlock tutorial](https://github.com/appium/appium-android-driver/blob/master/docs/UNLOCK.md) for more details.
appium:unlockStrategy | Either 'locksettings' (default) or 'uiautomator'. Setting it to 'uiautomator' will enforce the driver to avoid using special ADB shortcuts in order to speed up the unlock procedure.
appium:unlockSuccessTimeout | Maximum number of milliseconds to wait until the device is unlocked. `2000` ms by default
appium:skipUnlock | Whether to skip the check for lock screen presence (`true`). The default driver behaviour is to verify the presence of the screen lock (e.g. 'false' value of the capability) before starting the test and to unlock that (which sometimes might be unstable). Note, that this operation takes some time, so it is highly recommended to set this capability to `true` and disable screen locking on device(s) under test. Read the [Unlock tutorial](./docs/unlock/main.md) for more details.
appium:unlockType | Set one of the possible types of Android lock screens to unlock. Read the [Unlock tutorial](./docs/unlock/main.md) for more details.
appium:unlockKey | Allows to set an unlock key. Read the [Unlock tutorial](./docs/unlock/main.md) for more details.
appium:unlockStrategy | Either 'locksettings' (default) or 'uiautomator'. Read the [Unlock tutorial](./docs/unlock/main.md) for more details.
appium:unlockSuccessTimeout | Maximum number of milliseconds to wait until the device is unlocked. `2000` ms by default. Read the [Unlock tutorial](./docs/unlock/main.md) for more details.

### MJPEG

Expand Down
95 changes: 95 additions & 0 deletions docs/unlock/main.md
@@ -0,0 +1,95 @@
# Unlock

UiAutomator2 driver allows to deal with the Android lock screen using various APIs.
This article describes the available APIs and their options.

## Unlock On Session Startup

UiAutomator2 provides the following [capabilities](../../README.md#device-locking) 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.

### appium:unlockStrategy

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.

### appium:unlockSuccessTimeout

Maximum number of milliseconds to wait until the device is unlocked. `2000` ms by default

### appium:skipUnlock

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.

### appium:unlockType and appium:unlockKey

This capability supports the following possible values:

#### pin

Assumes the 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`.

#### pinWithKeyEvent

Same as [pin](#pin), but uses ADB instead of UiAutomator framework to enter the actual pin value.

#### password

Assumes the the device is protected with a password. Expects the `appium:unlockKey` to contain a valid password consisting
of latin characters, for example `abcd1234`.

#### pattern

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

##### Example

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

<img src="./screen1.png" />

We treat the pattern pins similarly to numbers on a digital phone dial. So, in this case the *unlockKey* is `729854163`

<img src="./screen2.png" />

and capabilities are:

```json
{
"appium:unlockType": "pattern",
"appium:unlockKey": "729854163"
}
```

## Mid-Session Unlock

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:

- [mobile: lock](../../README.md#mobile-lock)
- [mobile: unlock](../../README.md#mobile-unlock)
- [mobile: isLocked](../../README.md#mobile-islocked)
Binary file added docs/unlock/screen1.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/unlock/screen2.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit f12004e

Please sign in to comment.