Users are well aware of the application permissions but don’t have control over them. One of the biggest additions to Android 6.0 is the new permissions system. Now, Android 6.0 users can easily turn individual app permissions on and off. This allows users to better grasp the reasons why an application may be requesting specific permissions. This blog will step you into the bright and dark sides of the new permissions model.
Let’s look at the bright side first. Your existing applications will still work on all Marshmallow devices and request all permissions at the time of installment just as it would on any device running on a previous version.
And, here is the dark side. Users now have the ability to turn off permissions. If the app behaves as if that permission is turned on, this may lead the app to an inconsistent state and cause a crash if a user revoked a permission.
Tip: Even if it’s not on the top of your list to optimize your apps in line with this new permission model, it would be safe to add some new test cases to your sanity test suite. In my experience, most of the old apps tend to fall into this inconsistent state easily and the negative impact on the user experience can be quite significant.
With the new permissions system, permissions are requested at runtime. Users are more likely to allow permissions when they really want to use the feature it enables. However, this type of runtime permissions require Marshmallow devices. Apps which are targeting the new SDK and installed on a 6.0 device won’t ask for permissions at the time of installment.
Well, how does this new addition to android 6.0 impact those pre-Marshmallow devices and applications which don’t target the new Marshmallow SDK?
Under the new permissions model, updates don’t require user acceptance, allowing users to update the application seamlessly.
When a user opens the application, permission request dialogs can be quite frustrating, therefore, app developers must be familiar with the best practices and know when to show and ask for runtime permissions. Permission flows can follow two different behaviors.
First Behavior: App waits until a feature is invoked to request a permission for it.
Too many permissions can act as a barrier, preventing users to experience smooth mobile experiences. It is important to provide an immediate response to users when they grant a permission. Basic principle is that if a user allows for something, they expect to get something in return. For instance, Android applications developed with our e-commerce platform t-appz, ask for permission to use the camera when the user attempts to activate the QR code reader.
Second Behavior: App asks for all permissions up-front when the application is first launched on splash screen.
Avoid double prompting. When users deny a permission, only ask for it again if they attempt to use a feature which requires the permission they denied. You can also explain why you are asking for such permissions by providing a short tutorial to the user.
Once a user denies a permission request, the app should warn the user that this permission is being denied permanently. The users need to be aware that they will not be able to use that feature before allowing the permission request. In this case, it is a best practice to forward the user to the app permissions settings page and request them to change their settings.
All these factors will impact how users interact with your application. Permission workflows should always aim to improve the user experience of the app and in my opinion this is one of the most important features that comes with Android 6.0 Marshmallow. Most people are keen on using this feature already.
If you’re using one of tmob’s mobile app building platforms, tappz or MAGMA – great news! With the new permission model, you’ll be able to deliver better app experiences to your customers, through your existing and new applications.