All about Android Permissions

As soon as we hear android permissions we think o the above lines in the manifest. But now there is a lot more to the story.

But first for our newbie friend here’s a brief of exactly

What is android permissions

The purpose of permission is to protect the privacy of an Android user. Android apps must request permission to access sensitive user data (such as contacts and SMS), as well as certain system features (such as camera and internet). Depending on the feature, the system might grant the permission automatically or might prompt the user to approve the request.

Knowing how things work and Updates

With the release of Android 6 that changed, and every potentially dangerous permission would have to be requested and accepted in runtime. The user would be able to deny that permission (and use the Deny and don’t ask again option!), or even revoke it once it was accepted. More recently, with the release of Android 11, users can give permissions once or only while the app is running, and the operating system can revoke those permissions if the app hasn’t been used for a long time.

Following the Android best practices, we should:

• Wait until the user triggers an action that requires runtime permissions.
• Check if they have already granted them.
• Check if we should display a rationale to give some context to the user about why we require those permissions.
• Request the runtime permissions.
• Check if they accepted or denied them.
• Make our app react accordingly

Permissions are classified into two types in Android :

1. Normal permission
2. Dangerous permission

The 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. Check and change data connection: Include network state, Wi-Fi State, Bluetooth, Internet, etc.

The Dangerous permissions include nine permission groups where apps are somehow connected with the user’s privacy or security. In turn, each group contains several permissions an app can request.

Principles of working with Android permissions

It is recommended to follow these principles when working with Android permissions:

#1: Only use the permissions necessary for your app to work. Many times adding an implicit intent or back-grounding tasks does the work for us. In those cases, it is recommended not to ask for any permission.

#2: Pay attention to permissions required by libraries. When we include a library, we also inherit its permission requirements. So we should be aware of what you’re including, the permissions they require, and what those permissions are used for.

#3: Be transparent. When you make a permissions request, be clear about the permission you are asking about, and why, so users can make their call on it. Make this information available alongside the permission request including install, run-time, in the form of Toasts or dialogs.

Finally Code Time

In the example app, we are going to ask for the permissions just at the moment we click on the camera icon (as is the current suggestion, only requesting the permissions just when actually are needed), therefore we must add the use of it to the AndroidManifest.xml.

<uses-permission android:name="android.permission.CAMERA" />

Now, using Register Activity for Result API (registerForActivityResult()), we can have an object that let us launch it every time we ask for permission and we pass as parameter the proper contract to ask it (ActivityResultContracts.RequestPermission()) and the callback of the next parameter remains as a boolean lambda that indicates whether or not it was granted.

Right here then we would put the logic of what to do when the permission is or is not granted, including the scenario when the user denies it the first time (shouldShowRequestPermissionRationale) with the idea of properly explaining what happens if it is not granted (for versions prior to Android 11 it would show the Don’t ask again box):

private val cameraPermission =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted ->
    with(binding.root) {
    when {
    granted -> snackBar("Permission granted!")
    shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {
    //this option is available starting in API 23
    snackBar("Permission denied, show more info!")
    }
    else -> snackBar("Permission denied")
    }
    }
    }

Finally, to launch the permission under a certain action (as suggested), then when we click the camera button, we call the newly created permission object, and with the *launch* method we pass the permission that we want to request and it’s done

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(binding.root)

    binding.cameraIcon.setOnClickListener {
        cameraPermission.launch(Manifest.permission.CAMERA)
    }
}

and that’s all! we don’t need anything else. Thus, we could replace or include permission groups such as the Location or Read / Write of the Storage.

Ta-da!! Hope it helped. Keep Coding!!