Handling Android Runtime permissions in UI Tests in SUSI.AI Android
With the introduction of Marshmallow (API Level 23), in SUSI.AI it was needed to ensure that: It was verified if we had the permission that was needed, when required The user was requested to grant permission, when it deemed appropriate The request (empty states or data feedback) was correctly handled within the UI to represent the outcome of being granted or denied the required permission You might have written UI tests. What about instances where the app needs the user’s permissions, like allow the app to access contacts on the device, for the tests to run? Would the tests pass when the test is run on Android 6.0+ devices? And, can Espresso be used to achieve this? Unfortunately, Espresso doesn’t have the ability to access components from outside of the application package. So, how to handle this? There are two approaches to handle this : 1) Using the UI Automator 2) Using the GrantPermissionRule Let us have a look at both of these approaches in detail : Using UI Automator to Handle Runtime Permissions on Android for UI Tests : UI Automator is a UI testing framework suitable for cross-app functional UI testing across system and installed apps. This framework requires Android 4.3 (API level 18) or higher. The UI Automator testing framework provides a set of APIs to build UI tests that perform interactions on user apps and system apps. The UI Automator APIs allows you to perform operations such as opening the Settings menu or the app launcher in a test device. This testing framework is well-suited for writing black box-style automated tests, where the test code does not rely on internal implementation details of the target app. The key features of this testing framework include the following : A viewer to inspect layout hierarchy. For more information, see UI Automator Viewer. An API to retrieve state information and perform operations on the target device. For more information, see Accessing device state. APIs that support cross-app UI testing. For more information, see UI Automator APIs. Unlike Espresso, UIAutomator can interact with system applications which means that you’ll be able to interact with the permissions dialog, if needed. So, how to do this? Well, if you want to grant a permission in a UI test then you need to find the corresponding UiObject that you wish to click on. In our case, the permissions dialog box is the UiObject. This object is a representation of a view - it is not bound to the view but contains information to locate the matching view at runtime, based on the properties of the UiSelector instance within it’s constructor. A UiSelector instance is an object that declares elements to be targeted by the UI test within the layout. You can set various properties such as a text value, class name or content-description, for this UiSelector instance. So, once you have your UiObject (the permissions dialog), you can determine which option you want to select and then use click( ) method to grant/deny permission access.…
