Google I/O provided us again great insights and new information on how greatly Android is going forward. From developers and testers point of view one of the most interesting change in Android – provided with version ‘M’ or Macadamia Nut Cookie or Marshmallow – was the new application permission model which focus on streamlining the process for users to install and upgrade apps. For example, users are not required to grant any permission on install time anymore but app will request permission when it needs them.
Sounds great, but how does this impact on existing apps out there already — and what developers and testers should know about this change?
I have to start by highlighting that everything described and discussed in this blog are based on observations and information from Android ‘M’ Developer Preview (or Android ‘M’, API 22, MNC preview). When new releases gear towards the official one, behavior and use cases will surely change – but fundamentally the new runtime permission system will change the way apps are getting implemented – and especially how those apps are being tested.
The big change is at installation. Users are not prompted to grant any permissions at install time anymore. When any app (or game) requests a permission, the system will show a dialog to the use and after user has approved it application’s callback function notifies whether the permission was granted. If a user grants this permission asked runtime, the application is given all permissions in that functional area that were declared in the manifest file. Declaring permission hasn’t changed from the prior versions, but the new thing is permission groups that can include variety of actions enabled for certain application.
How Will Current Apps Work With Android ‘M’ Devices
Google’s Android ‘M’ documentation provides some information about forwards and backwards compatibility, but in a nutshell: If your application is targeting for Android ‘M’ (API 22, MNC preview) you must use the new permissions model. However, if devices where app is executed are not running on ‘M’, the system asks the user to grant all declared permissions at install time. Naturally, if devices that are used for testing are running on Android ‘M’ all permissions should be granted on runtime.
This might have an impact for your local environment, but within Bitbar Testing products we’ve solved this for you already and you can decide whether all permissions will be granted when app is getting installed or you may want to use it like your local test environment (and grant all permissions separately).
If your application is targeting for some older platform/API level, the application continues using the old permission model even on devices running on Android ‘M’ – but as we’ve experienced that these sort of changes can make some existing test scripts run strange, you should consider the following options to ensure you don’t have to change your tests.
For example, you can install an app using the following parameters with ADB:
$ adb pm grant com.example.myapp android.permission.<PERMISSION>
$ adb install -g <com.your.app>
So, when you create test locally you might want to consider giving permissions to your app and apply the same practice when you run it at Bitbar Public Cloud.
New Permission Groups with Android Marshmallow
As said, the new permission model is only available on devices running Android ‘M’. Your app can first check on what version of Android it is executed on by checking the value
Build.VERSION.CODENAME. If the device is running Android ‘M’ developer preview, the codename is
"MNC". When the user tries to do something that requires a permission, the app checks to see if it currently has permission to perform this operation (by calling
The following table illustrates permission groups and what permissions are associated in those groups:
One new thing in the new permission system is the runtime revoke option of permissions. This can be also done via ADB. To revoke a permission, use the package manager’s
$ adb pm revoke <package_name> <permission_name>
Implications to Existing Test Assets
The new permission system in Android does have an impact for test automation. As you want to avoid unnecessary notifications during the test execution, the mentioned practices are recommended and you should consider granting all permissions when installing application. Furthermore, when you develop your app (or game) you should consider carefully what permission will be prompted for user: if user declines the permission request, this will have an impact for you app and reduces the functionality and usability of it. The very same applies for tests as you have to predict WHEN is that permission request prompted and HOW will your test script handle that. Nevertheless, you should always try to minimize the number of times you make these user requests.
But don’t worry – we’ve taken care of permission change in Testdroid and you’ll have a smooth experience to run your tests as you’ve done before. Happy Testing with Macadamia Nut Cookie (or Android Marshmallow)!