Working With Android 10

Android 10, by and large, works the same way with Appium as any previous version. There is one important change to be aware of from an automation perspective, however. If the app you're testing has a target SDK version of less than 23 (Android 6.0), then when you launch it on Android 10, you might see a fancy new permissions interstitial before your app launches. Something like this:

Presumably this is because of Android 10's new, more fine-grained app permissions model. Because these older apps haven't been coded with an eye to the new permissions model, Android needs to pop up this annoying interstitial in order to make sure everything's cool, permissions-wise. This is a slight annoyance for users, with a great gain in terms of privacy. However, it can be devastating for automation if your code isn't expecting it. You have three options for what to do about this.

Test your Android apps on real remote devices seamlessly with HeadSpin

Option 1: Automate the Permissions View

The first option is the big hammer: you could just use Appium to automate this dialog by tapping the "Continue" button. But this means you have to throw a conditional in your test code for Android 10, and potentially waste a bunch of timing waiting for a "Continue" button that doesn't exist on versions of Android less than 10. So I don't recommend it.

Option 2: Update your app's targetSdkVersion

Every Android app can specify 3 different Android SDK versions. Somewhat confusingly, they are:

• minSdkVersion: This is the minimum version of Android your app will launch on.
• compileSdkVersion: This is the version of Android that your app will be built with, which determines which APIs your code has access to as you are compiling it. It also determines which compilation errors and warnings will be logged.
• targetSdkVersion: This is kind of a weird one. By targeting a certain SDK, you are telling Android which SDK you have tested, so Android is free to apply system-wide behavior changes to your app. For example, imagine that your app has a targetSdkVersion of 21---in that case, the Android OS might decide that your app doesn't support Dark Mode, even though Dark Mode is available more generally on the device which is running your app. Essentially, it clues Android into which system behaviors your app is designed to support.

If you have access to your app's source code, or can convince your developers to do this, you could always update your app's targetSdkVersion to 29 (the SDK version of Android 10), and this will do away with the interstitial. Though of course you'll need to participate in the new permissions system, and that might require some code updates throughout the app.

Read: Mastering Automation of Android TV Apps with Appium

Option 3: Use autoGrantPermissions

The final, and in my opinion most straightforward, option is to use the autoGrantPermissions capability. If you include this capability and set it to true, Appium will attempt to automatically grant your app all permissions from the system perspective, so that when it comes time to launch your app, Android already thinks that all permissions have been requested and accepted.

Using this capability is nice because you might need it already (as a way to do away with dialogs popping up throughout the execution of your test), but also because you don't need to update the app in order to use it. Of course, you should still bug your developers to update the target SDK version for your app so that it stays current!

Appium 1.15 is the most current release that supports Android 10, so make sure you download it whenever you need to automate apps on this Android platform. As of the time of writing, Appium 1.15 is currently in the Release Candidate stage, and should be generally available soon!