Frequently, when we install an Android application on our devices, we see an enormous number of permission requests. For example:
It’s great if you are dealing with an application from a famous and well-known developer whom you can trust. But imagine that you want to install a music player that requires, let’s say, information about your location. It looks very suspicious, doesn’t it? Or you have found a flashlight that requires access to your SMS and calls.
Some developers are trying to remove distrust by adding information about each of the required permissions on the application description page in Google Play.
By the time the sixth version of Android appeared, the situation had changed. Now such permissions have to be requested in runtime. How we use this new feature at Distillery and its main pitfalls are described further in this article.
Similarly to iOS, a system dialog window will appear, asking the user for permission.
The main difference is that after pressing the Deny button, such permissions won’t be totally blocked for the application like it happens in case of Apple. Such permission requests may be shown one more time, giving the user an option to Never ask again. After choosing this option, Deny will work similarly to Don’t allow in iOS.
All permissions can be divided into two categories (there are several more, but we are not interested in them right now):
Normal permissions can be provided during the installation process without any confirmation from the user (this is pretty controversial in our opinion because they could have notified the user about all permissions provided to the app). One can’t revoke such permissions from the application later. On the other hand, all dangerous permissions have to be requested during the operation of the application, and such permissions can be revoked at any time. The list of the most dangerous permissions can be found here.
You can see that internet access is not considered a dangerous permission. All of you who use advertising in your applications can breathe again because it’s impossible to disable it by revoking permission from the app (however, the user can simply disable the internet connection).
In order to revoke previously granted permission (or to provide it if you have chosen Never ask again), you have to open the application settings (Settings->Apps->*AppName*), go to the Permissions tab, and toggle required permissions. Here you can also check all permissions of the application by choosing All permissions in the contextual menu. You can also find the list of applications for specific permissions here (you can provide or revoke such permissions). In order to do so, you need to open the Apps section, click on the gear icon and choose App permissions. After that, you can choose any desired permission in order to see the list of applications that require it.
Let’s look at the main principles of interaction with the user. First of all, we have to deal with the permission request itself. We are not interested in the normal permissions because requesting them is the task for the application installer. The method that we are going to use to request dangerous permission depends on two main factors.
The first factor is the importance of such permissions for your application. It defines the right moment for request to be made. If a function is critical and the application won’t function properly without it, don’t hesitate—request permission right after the application’s launch. For example, if you are developing an SMS application, it won’t work without specific permissions, thus making the app totally useless. In case the user declines your permission request, you don’t need to let them in, giving them the possibility to show the permission request window again and providing thorough instructions.
If permission is only required by a secondary function, there’s no need to ask for it immediately. Such permission requests can be shown only in a case when the user wants to use a specific function.
The second factor is the clarity of user’s perception of such permission. Why would an SMS application access the calendar? It’s probably going to provide an amazing feature, allowing the user to import dates from SMS messages into the calendar and so on. But only you know about such a function, thus you have to explain to the user the main reasons for your permission request, the consequences, and main advantages. This factor is important for both main and secondary permissions.
If the user declines your request, you are not obligated to explain everything once again. If the user asks you not to show such requests once again by using the Never ask again option, but they try to use a related application function, you can offer them to open program settings and accept required permissions manually. This moment is very important if such permissions are critical for the normal operation of your app.
New permission systems shall attract the attention of the users to the permissions granted for applications. Such approach will help to reduce the overall number of malicious software, which was based on the lack of attention of the user. Furthermore, it increases the level of trust to the leading developers’ products and decreases the number of questions and issues for the users. No doubt that developers have to create more code in order to implement new features, using methods which are not perfect and elegant. Nevertheless, despite all of those difficulties, Google took a step in the right direction by implementing this feature, because it was simply necessary in order to make the operating system more convenient for the user. Have a mobile app idea our team could turn into reality? Let us know!
Maxim Kovalev is an Android development professional, working at Distillery since December 2014. His journey as a programmer started back in school when he wrote his first “Hello, World!” application using Turbo Pascal language. Since then, Maxim has been passionate about learning new technologies and platforms. Maxim spends his free time playing the bass guitar and airsoft.