Google is on the roll with one new thing out of its pocket after another. From Android M to BoringSSL and finally to Android Experiments. Now it has reached a brand new twist that coincides with the expected entry of Android M and BoringSSL. Runtime Permissions! This will bring a great change in the life of Android 6+ user’s and the app makers at the same time.
Android 6.0 Marshmallow introduces one of the largest changes to the permissions model with the addition of runtime permissions, a new permission model replacing the existing install-time permissions model when you target API 23 and the app is running on an Android 6.0+ device.
Getting Runtime Permissions for Your Android App
When installing an app, you remember going through a little process wherein when you click the ‘install’ button, there are a couple of permissions asked from you, depending on the apps’ usage. Now runtime permissions give your app the ability to control when and with what context you’ll ask for permissions.
This means users will not be required to accept a list of permissions before installing the app. It also means that if your app adds new permissions, app updates will not be blocked until the user accepts the new permissions. Your app can ask for the newly added runtime permissions as needed.
The right time to ask for the runtime permissions, can also impact on app’s user experience. It should be simple, transparent, and understandable. For example asking the permissions at up-front, is the common thing.
Your permissions strategy depends on the clarity and importance of the permission type you are requesting. These request patterns offer different ways of introducing permissions to the user.
Critical permissions should be requested up-front. Secondary permissions may be requested in-context.Permissions that are unclear should provide education about what the permission involves, whether done up-front or in context.
Below are certain design and permission patterns as mentioned by Android officials.
In many cases, you can avoid permissions altogether by using the existing intents system to utilize other existing specialized apps rather than building a full experience within your app. An example of this is using ACTION_IMAGE_CAPTURE to start an existing camera app the user is familiar.
Keep in mind that users can revoke permissions at any time through the system settings so you should always check permissions denied every time.
Explain why the app needs permission
The dialogue boxes that open, asking for permission needed, should show why this permission is required. If a new UI design is set, wherein the ‘why’ is answered, in brief, then nothing better, to make this Runtime Permissions a success. To provide extra information or explanation, the system provides a method shouldShowRequestPermissionRationale()
The actual availability of the Runtime Permissions, is yet to be given to the Android users and Android developers. In a way, this journey has not even begun and the pre preps of the red carpet walk of Android M, BoringSSL and Runtime Permissions; is creating ripples of earthquakes at every user/ developers’ feet.
So get your app ready for Android 6.0 and these updates. If you want to know how to make the app better and updated, read the android developer guidelines or simply talk to us!