Android 6.0 Developer's use and practice of system permissions (Permissions Best Practices)

Permissions Best Practices

During the installation process, it is easy for users to ignore permission requests. If a user is frustrated with the app or is worried about leaking personal information, those users will not be using him or uninstalling it. How to avoid this problem?

consider Using an Intent In many cases, you might choose between two implementations, you can have a permission for your app, or you can intent another app to help you with the functionality. For example, an app needs a camera to get pictures, and you can ask for camera permissions, which allows your app to control the camera directly. Your app can control the camera and get pictures using the camera's API. This approach allows your application to take full control of the photo process and allow the camera interface to be fused into the application. However, if you do not need full control, you can use intent's action_image_capture to request a picture. When you send this intent, the system will provide several camera app options (provided the app is not set by default), the user can select a camera app and then get the return value via the Onactivityresult () method. Similarly, if you need to dial a phone, use a user's contact list, and so on, you can create a intent, or request permissions directly from the user. Every way has its pros and cons. If you apply for one of the user privileges:when you do an operation, your app controls the user's experience. However, excessive control increases the complexity of the application because you need to design the appropriate UI. at run time (api>=23) or at installation time, the user is prompted to grant permission. After that, your app does not have to interact with the user at all times without additional interaction. However, if the user does not grant permission or is revoked, your app will not function properly. If you use the intent method:you do not need to run the design UI. The app that handles the intent will provide the UI. However, because the other application is open, it means that you cannot control the user's interaction experience. In the app you launched through intent, the user's interaction is not under your control because it is not your own design interface. If you launch this app through intent, the user does not have a default app, and the system pops up a window to let the user choose an app. If the user does not set a default startup, a selection window pops up each time the operation is performed. Only Ask for Permissions you needevery permission request is forcing the user to make a choice. You should least ask the user for permission. If the user's version is greater than or equal to Android6.0, your app will pop up a request permission window whenever the user tries to use some new feature that requires permission. If it was in the earlier version, the permission list was prompted to the user at the time of installation. If the permissions list is too long or looks uncomfortable, the user may not be able to install the app. In order to deal with these problems, you should ask for the least amount of permission. you can replace it with a intent way. If your new feature requires a permission, you can have another app to help you with this feature. Don ' t overwhelm the Userif the user's system is greater than or equal to Android6.0, the user must grant permission when the program runs. If you allow a lot of permissions to face the user at once, you may be able to get your users hit and quit your app. Instead, you should use when and when you want the user to request. in an app, one or more permissions are often necessary. In this case, as soon as we start the app, we want the user to request. For example, you did a photographic application. This app requires the user's camera permissions. When users start the app for the first time, they won't be confused about your permission requests. But if this app has a feature of red energy, to your contacts friends wind the picture, you can not come up to request the user's R ead_contact permissions. You should ask the user for permission when sharing. If your app provides a wizard, it's a good idea to ask the user for permission after the wizard finishes. Explain why need Permissionswhen you call the Requestpermission () method, the system pops up a popup permission request pop-up, but there is no representation of why you need this permission. In many cases, users will be confused. A good note is to explain to the user why you need this permission before calling Requestpermission (). For example: A photography app that wants to use location services to mark images. An ordinary user may not understand why a picture needs to be used for positioning and will feel confused. In this case, a good idea is to explain to the user before Requestpermission (). In another way, you can merge permission requests into the wizard. In the wizard, you can show users the special feature points of the app and show them why you need this permission. Like what. This photo app will show you the feature "Share photos with your contacts" in the wizard, and then tell you that the user needs a contact list. Then apply to the user. The application can request permissions from the user by calling the Requestpermission () method. Of course, not every user will see your wizard, so you still want to use this feature when the user to detect whether the user is authorized, if not, and pop-up window to the user to request the permission. Test for Both Permissions Models

In Android6.0, the installation is replaced by requesting permissions at run time. For this reason, you have to test your application in a wider range of conditions. Before Android6.0 we had good reason to believe that our program was running and that we had sufficient permissions because these permissions were already declared in the manifest file. In the new permission model, this is not possible.

In cases greater than or equal to API23, you need to determine your permissions:

· IDentify your app ' s current permissions andthe related code paths.

· Test user flows across permission-protectedservices and data.

· Test with various combinations of Grantedor revoked permissions. For example, a-camera app might listcamera, read_contacts, and access_fine_location in Itsmani Fest. You should test the app with each of these permissions turned on Andoff, to make sure the app can handle all permission co Nfigurations gracefully.

· Use the adb toolto Manage permissions from the command line:

o ListPermissions and status by group:

$ adb shell pm list permissions-d-G

o Grantor revoke one or more permissions:

$ adb shell PM [Grant|revoke] <permission-name> ...

· Analyze your app for services, that usepermissions.

If you feel that my share is useful to you, sweep your attention to me.

Android 6.0 developer use and practice of system permissions (Permissions best Practices)