Runtime Permissions

All good!

So we got now to the mobile: started a set of the course "Developer Android" . Another small milestone and a completely new direction. Our teacher, Simon Pilunts, shares some of his reflections on the matter on this subject.

If your application runs on Android 6.0 (API level 23) or higher, and you need some special permissions, then you will need to do a little more work to use them. Starting with Marshmallow, users grant permissions for applications while the application is running, not when installing the application (in versions prior to Marshmallow, you can simply declare what permission you will use in the manifest file). A new concept was called permissions at runtime. This approach simplifies the installation process of the application, since the user does not need to be granted permissions when installing or updating the application. It also gives the user more control over the functionality of the application; for example, the user can select access to the camera in the application for shooting, but not to the location of the device. The user can cancel permissions at any time by going to the application settings screen. The idea behind them is to inform the user about which permissions you will use, because many applications use many unnecessary permissions.
')


In some cases, you can help the user understand why your application needs this or that permission. In the above example, if a user starts an application for a photo, the user is probably not surprised that the application requests permission to use the camera, but the user may not understand why the application wants to access the user's location or contacts. Before requesting permission, you should consider providing an explanation to the user. Keep in mind that you do not want to overwhelm the user with explanations; if you provide too many explanations, the user may find the application disappointing and delete it.
Now let's figure out how to do it.

System permissions are divided into two categories: normal and dangerous :

• Normal permissions do not directly affect user privacy. If your application displays the normal resolution in its manifest, the system automatically grants the permission.
• Dangerous permissions can provide an application with access to sensitive user data. If you specify a dangerous permission, the user must explicitly provide approval to your application.

In all versions of Android, your application must declare both the normal and dangerous permissions it needs in the application manifest. However, the effect of this declaration depends on the system version and the target SDK of your application:

• If the device is running Android 5.1 or lower, or the target SDK of your application is 22 or lower: if you specify a dangerous permission in the manifest, the user must grant permission when installing the application; if he does not grant permissions, the system will not install the application at all.
• If the device is running Android 6.0 or higher, and the target SDK of your application is 23 or higher: the application must display permissions in the manifest, and must request every dangerous permission it needs while the application is running. The user can grant or deny each permission, and the application can continue to work with disabilities, even if the user rejects the permission request.

If your application requires dangerous permission, you should check to see if you have this permission every time you perform an operation that requires this permission. The user can always cancel the permission, so even if the application used the camera yesterday, it cannot assume that it still has this permission today.

To check if you have permission, call the ContextCompat.checkSelfPermission () method. For example, this snippet shows how to check if the action has permission to write to the calendar:

* CODE FRAGMENT> *

If the application has permission, the method returns PackageManager.PERMISSION_GRANTED , and the application can continue the operation. If the application does not have permission, the method returns PERMISSION_DENIED, and the application must explicitly request permission from the user.

If your application does not yet have the required permissions, the application must call one of the requestPermissions () methods to request the appropriate permissions. Your application passes the permissions it needs, as well as the integer request code that you specify to identify this permission request. What is the request code? When we process user responses to our request, we can ask for multiple permissions several times in the same action, so we need to select these requests, and we do this by request code. So how do we handle user responses to our requests? When your application requests permissions, the system provides the user with a dialog box. When the user responds, the system calls the onRequestPermissionsResult () method of your application, passing it the user response. Your application must override this method to find out if permission has been granted. The callback is passed by the same request code that you passed to requestPermissions () . When the system asks the user to grant permission, the user has the opportunity to tell the system not to request this permission again. In this case, anytime the application uses requestPermissions () to request this permission again, the system immediately rejects the request. The system calls your onRequestPermissionsResult () callback method and sends PERMISSION_DENIED, just as if the user had explicitly denied your request. This means that when you call requestPermissions () , you cannot assume that there has been any direct user interaction.

THE END

As always, we are waiting for your feedback and questions here or at an open lesson , where you will familiarize you with the familiarization with the Android Studio development environment and the Android Virtual Device (AVD) Manager and its capabilities.