Google has changed the way that applications handle permissions. Before, we only dealt with permissions in
AndroidManifest.xml, but starting with Android 6.0, we need to check every time for permission-related tasks. Applications need to ask the permission at runtime while they are running and also have to provide enough context on why the permissions are required. Though we have to declare in manifest whenever an application wants to access APIs that need the runtime permission, apps have to check whether that permission has been granted or request the required permission using the support library.
There are two types of permissions: normal permissions and dangerous permissions.
Normal permissions do not directly affect the user’s privacy. If the application lists a normal permission in its manifest, then these permissions will be automatically granted by the system upon installation. Some of the most common normal permissions are check and change data connection, include network state, and include wi-fi state.
Here's an example:
Dangerous permissions give an application access to the user’s private data or affect the system and other apps. If you list a dangerous permission in manifest, then the user has to explicitly give permission to your application.
Advantages of Runtime Permissions
In Android 6.0, applications provide transparency to users. Users have to grant permissions to applications while the application is running rather than during installation. The phone asks the user to grant permission only when some specific function is being used within an app. At that point, users have to decide whether or not to grant their permission.
In the earlier versions of Android 6.0, a user had to grant all the app permissions before installing from the Play Store, and if he or she didn’t allow the permission, then the system wouldn’t install the application at all. As a result, many malicious apps were able to access user private data after granting the permission at installation time, which led to a major security breach.
In Marshmallow, the user can allow or deny individual permission and the application can continue run with limited efficiencies even if the user denies a permission request. In addition, users now have the option to revoke individual app permissions after he or she has granted them, but in the earlier versions to Marshmallow, the user couldn’t revoke individual app permissions.
Different types of permissions are separated into groups based on which data or resource it requests access for. Once permission from a group has been granted, then other permissions within that group do not need to be granted again.
For example, a permission group for SMS can send or receive the SMS. Those are two different permissions but the user only needs to allow one.
Android 6.0 Marshmallow has nine main groups of permissions:
Calendar: Read and/or write to the calendar.
Camera: Give the application the ability to access the camera.
Location: Access fine or coarse location.
Microphone: The ability to record audio.
Phone: Includes phone state; the ability to make calls, read, and write to the call log; and voicemail.
Sensor: The ability to use various sensors in the device, like a gyroscope.
SMS: Similar to how the phone is handled including sending and receiving texts. MMS and cell broadcasts.
Storage: Read and write to device’s external storage.
Manually Enabling and Disabling Runtime Permissions
The user can deny permissions at any time by going to the application’s Settings screen. There are some steps to enable and disable the app permissions given below.
Open your device’s Settings app.
Tap apps and find an app that you want to work with. Select it.
Tap applications permissions on the App Info screen.
You will see the list of permissions the app requests. Tap on the switch to turn it on or off.
Requesting Permissions at Runtime
In Android 6.0, users allow permissions to applications while it is running, not during installation. This approach streamlines the application install process since the user does not require grant permissions when they install or update the application. It also gives the user control over the application’s functionality. Since the permissions are requested individually, the user can allow some permission and deny others permissions. For example, user can grant camera permission but can deny location permission and the application may function seamlessly.
How to Check for Runtime Permissions
If your application requires runtime permission, you must check whether you have that permission enabled every time to perform an operation. The user is always free to revoke the permission.
Check the Target SDK Version
If the device running is former to Android 6.0, there is no need to call new runtime permission workflows.
Check if Permission Is Granted
- Check whether required permission is granted. Call the ContextCompat.checkSelfPermission (Context, String) method, Context current context and String Permission.
- If the application has the permission, the method returns PackageManager.PERMISSION_GRANTED and the application can proceed with the operation.
- If the application does not have the permission, the method returns Package Manager.PERMISSION_DENIED and the application have to explicitly ask the user for permission.
Handle "Never Ask Again"
ShouldShowRequestPermissionRationale (String permission) can be called to determine if the user denied this permission previously or not. If this method returns true, then it’s the perfect time to tell the user exactly why the permission is needed before requesting it again. If the user denies the permission request in the past and chooses the "Never ask again" option in the permission request system dialog, this method will return false. Next time we call requestPermissions, this dialog will not appear for this kind of permission anymore. Instead, it just does nothing.
The result of the rational dialog will be shown when this permission is requested for the first time and also be shown if the user has ever marked that permission as "Never ask again." For the next case, onRequestPermissionsResult() will be called with PERMISSION_DENIED without any permission grant dialog.
Request for Permission
If the application doesn’t have the permission which requires, the application must call requestPermissions(String [ ] permissions, int requestCode) methods to ask the appropriate permissions. Pass permission array and request code as parameters.
Example: The following code checks if the application has permission to use the location service and requests the permission if necessary.
Handle the Permissions Request Response
If the user has granted or denied the permission request, we have to handle response and execute the functionality according to response. This can be achieved by overriding the OnRequestPermissionsResult() in the Activity where the permission was requested. This method returns the result code for granted or denied permission.
Note: Suppose the user wants to use some APIs that need runtime permission that has not allowed yet. The function will immediately throw a SecurityException, which will cause the application to crash.
Runtime Permission is a must in Android Marshmallow. The user will be happier allowing permissions because they are much more likely to install your app without a wall of permissions at the installation. The aim of this new model is to give the user full control over application’s permissions. By using this, users will soon have a better understanding of exactly why apps need permission to access any features, which means less Play Store complaints and hopefully a higher download rate.
For more android blogs please visit : http://vmokshagroup.com/mobility/