Android 60 multiple permissions

The launch of Android 6.0, codenamed Marshmallow, marked a pivotal moment in mobile operating system history, fundamentally reshaping how applications interact with user data and device resources. Prior to this update, users granted all necessary app permissions at the time of installation, often without fully understanding the implications, leading to widespread concerns about privacy and data security. However, with the introduction of runtime permissions, Android 6.0 multiple permissions management shifted from an all-or-nothing approach to a dynamic, user-controlled model. This change empowered users to grant or revoke specific permissions while an app is running, offering unprecedented transparency and control over their personal information and device capabilities. It significantly enhanced user trust and demanded a more thoughtful approach from developers in handling sensitive data access.

The Paradigm Shift: Understanding Android 6.0’s Permission Model

Before Android 6.0 Marshmallow, the app permission model was relatively straightforward but lacked granular control. Users would see a comprehensive list of all required permissions during installation. Accepting these terms meant granting the app full access to everything it requested, even if some permissions were only needed for obscure features or rarely used functionalities. This approach often led to “permission fatigue,” where users blindly accepted permissions without scrutinizing them, potentially exposing their data to malicious or poorly designed applications.

Android 6.0 multiple permissions introduced a revolutionary change: runtime permissions. Instead of granting all permissions at install time, users now grant or deny permissions as the app needs them, in context. This new permission model applies specifically to “dangerous” permissions, which are those that could potentially affect the user’s privacy or the operation of other apps. For instance, an app might request access to the camera only when the user attempts to take a photo, rather than having persistent access from the moment of installation. This change significantly improved user privacy by making permission requests transparent and contextual.

The core philosophy behind this update was to give users more control over their data. Google categorized permissions into “normal” and “dangerous.” Normal permissions are granted automatically at installation because they pose little risk to user privacy or device operation. Dangerous permissions, however, require explicit user approval at runtime. These dangerous permissions are further organized into permission groups. If a user grants permission for one member of a group, they implicitly grant permission for all other members of that group without additional prompts. This streamlines the user experience while maintaining security.

Navigating Dangerous Permissions: What Developers Need to Know

Developers faced a significant learning curve with Android 6.0 multiple permissions, as their applications needed to be adapted to gracefully handle permission requests and user responses. Dangerous permissions include categories like accessing the camera, contacts, location, microphone, phone state, sensors, SMS, and storage. For example, an app requesting android.permission.READ_CONTACTS or android.permission.ACCESS_FINE_LOCATION falls under this “dangerous” classification and requires explicit user consent during app execution.

For developers, the key is to anticipate when an app will need a dangerous permission and request it at the appropriate moment, providing a clear explanation of why the permission is necessary. This context is crucial for user acceptance. For instance, a messaging app should request microphone access only when the user initiates a voice message, not at startup. Failing to handle permission requests properly can lead to app crashes or a poor user experience, as the app won’t function as expected without the necessary grants.

Moreover, developers must implement robust error handling for scenarios where a user denies a permission. An app should not simply crash but instead provide a graceful fallback, perhaps by offering an alternative way to complete the task or explaining why the feature is unavailable. As stated by a Google spokesperson regarding the Marshmallow update, “The new permissions model empowers users with more choices and transparency, but it also requires developers to build more resilient and user-friendly apps.” This highlights the dual responsibility of enhancing security and maintaining usability in the new permission management landscape.

Implementing Runtime Permissions: A Step-by-Step Guide ------------------------------------------------------

For developers, integrating Android 6.0 multiple permissions requires a structured approach to ensure smooth user interaction and app functionality. The process involves checking if a permission has already been granted, requesting it if not, and then handling the user’s response. This proactive permission check prevents unnecessary prompts and ensures the app behaves predictably. It’s a fundamental shift from the previous model where permissions were assumed to be granted post-installation.

To effectively manage runtime permissions, developers typically follow these steps:

Check if you already have the permission: Before performing any operation that requires a dangerous permission, use ContextCompat.checkSelfPermission() to determine if the user has already granted that specific permission to your app. If the permission is already granted, the app can proceed with the protected operation.
Request the permission if necessary: If checkSelfPermission() returns PERMISSION_DENIED, your app must explicitly request the permission from the user. Use ActivityCompat.requestPermissions() to display a standard Android dialog. This dialog informs the user about the permission and allows them to grant or deny it. It’s good practice to provide a clear rationale for the request before showing the dialog, especially if the permission isn’t immediately obvious.
Handle the user’s response: After the user responds to the permission dialog, the system calls your app’s onRequestPermissionsResult() callback method. This method provides the result of the permission request, indicating whether the user granted or denied the permission. Your app must implement this callback to react appropriately, enabling the feature if granted or gracefully handling the denial.
Provide rationale (optional but recommended): For permissions that might not be immediately obvious to the user, like accessing location services for a weather app, it’s beneficial to use ActivityCompat.shouldShowRequestPermissionRationale() before requesting the permission. If this method returns true, it means the user previously denied the request and didn’t select “Don’t ask again,” giving you an opportunity to explain why the permission is needed before re- Question & Answer :
I know that Android 6.0 has new permissions and I know I can call them with something like this
```
if (ContextCompat.checkSelfPermission(this, Manifest.permission.WRITE_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[] { Manifest.permission.WRITE_EXTERNAL_STORAGE }, PERMISSION_WRITE_STORAGE); } 
```
Today I saw a Google app which needs 3 permissions: contacts, sms and camera. It’s making a page 1-3 and calls them all together at the same time to activate.

Can anybody tell me how I can call 4 permissions to activate at the same time like sms, camera, contacts and storage?

Example (forgot the name of the google app :( )
The app needs sms,contacts and camera

the app asked me (and made a dialog page1-3) activate sms, activate contacts and then camera. So this google app was calling all 3 required permissions together and my question is how can i achive the same ?

Just include all 4 permissions in the ActivityCompat.requestPermissions(...) call and Android will automatically page them together like you mentioned.

I have a helper method to check multiple permissions and see if any of them are not granted.
```
public static boolean hasPermissions(Context context, String... permissions) { if (context != null && permissions != null) { for (String permission : permissions) { if (ActivityCompat.checkSelfPermission(context, permission) != PackageManager.PERMISSION_GRANTED) { return false; } } } return true; } 
```
Or in Kotlin:
```
fun hasPermissions(context: Context, vararg permissions: String): Boolean = permissions.all { ActivityCompat.checkSelfPermission(context, it) == PackageManager.PERMISSION_GRANTED } 
```
Then just send it all of the permissions. Android will ask only for the ones it needs.
```
// The request code used in ActivityCompat.requestPermissions() // and returned in the Activity's onRequestPermissionsResult() int PERMISSION_ALL = 1; String[] PERMISSIONS = { android.Manifest.permission.READ_CONTACTS, android.Manifest.permission.WRITE_CONTACTS, android.Manifest.permission.WRITE_EXTERNAL_STORAGE, android.Manifest.permission.READ_SMS, android.Manifest.permission.CAMERA }; if (!hasPermissions(this, PERMISSIONS)) { ActivityCompat.requestPermissions(this, PERMISSIONS, PERMISSION_ALL); } 
```