Use and exercise of system Permissions by Android 6.0 developers (Permissions Best Practices)

Use and exercise of system Permissions by Android 6.0 developers (Permissions Best Practices)

During the installation process, you can easily ignore permission requests. If a user is frustrated with the application or is worried about leaking personal information, the user will not need to use the application or uninstall it. How can we avoid this problem?

Consider Using an Intent

In many cases, you may make choices in two implementation methods. You can assume that your app has one permission, you can also use Intent to enable another app to help you implement relevant functions.

For example, an app needs to obtain images through a CAMERA. You can request the CAMERA permission to allow your app to directly control the CAMERA. Your application can use the camera api to control cameras and obtain images. In this way, your application can fully control the photo taking process and allow the camera interface to be integrated into the application.

However, if you do not need full control, you can use the ACTION_IMAGE_CAPTURE of Intent to request images. When you send this Intent, the system will provide several camera app options (provided that the default application is not set). You can select a camera app and then use onActivityResult () method to obtain the return value.

Similarly, if you need to make a call and use the user's contact list, you can create an Intent or directly request permissions from the user. Each method has advantages and disadvantages.

If you apply for a user permission:

When you perform an operation, your app controls the user experience. However, excessive control increases application complexity because you need to design the appropriate UI.

During running (API> = 23) or installation, the user is prompted to grant permission. After that, your application does not need to interact with the user at any time. However, if the user does not grant the permission or revoke the permission, your application will not run properly.

If you use intent:

You do not need to design the UI for running. The application that processes the Intent provides the UI. However, because another application is opened, this means that you cannot control the user interaction experience. In an app that you launch through intent, user interaction is not controlled by you because it is not a self-designed interface.

If you use intent to start this application and you do not have a default application, a window will pop up to allow you to select an app. If you do not set a default startup, a selection window will pop up each time you perform this operation.

Only Ask for Permissions You Need

Each permission request forces the user to make a choice. You should have at least the permission to request the user. If your version is later than or equal to Android6.0, your application will pop up a window requesting permissions whenever you try to use some new features that require permissions. In earlier versions, the permission list is prompted to the user during installation. If the permission list is too long or looks uncomfortable, you may not install the application. To handle these problems, you should have at least the requested permissions.

You can use intent instead. If your new features require a permission, you can ask another app to help you implement this function.

Don't Overwhelm the User

If your system is later than or equal to Android6.0, you must grant permissions when running the program. If you allow a large number of permission requests to the user at one time, you may cause your user to receive a blow and quit your application. On the contrary, when should you use it and when you want to request it.

In an application, one or more permissions are often necessary. In this case, when the app is started, we need to request the user. For example, you have made an application of photography. This application requires the user's Camera permission. When a user starts an application for the first time, they will not be confused about your permission requests. However, if this application has a special red hat, you can send a picture to your address book friends. If you cannot get up, you can request the user's R EAD_CONTACT permission. You should request permissions from users during sharing.

If your application provides a wizard, it is best to request permissions from the user after the Wizard is complete.

Explain Why You Need Permissions

When you call the requestPermission () method, the system will pop up the permission application window, but it does not show why you need this permission. In many cases, users are confused. A good note is to explain to the user why you need this permission before calling requestPermission.

For example, a photography app wants to use the positioning service to mark images. A common user may be confused about why an image needs to be positioned. In this case, a good idea is to explain it to the user before requestPermission.

In another way, you can integrate permission requests in the Wizard. In the wizard, you can show users the special features of the app and why you need this permission. For example. This photography app shows you the special feature of "Share photos with contacts" in the wizard, and then tells you that you need the permission to list contacts. Then apply to the user. This application can request permissions from users by calling the requestPermission () method. Of course, not every user will read your wizard, so you still need to check whether the user is authorized when the user uses this function. If not, you need to apply for this permission from the user in a pop-up window.

Test for Both Permissions Models

In Android6.0, the installation is replaced by the permission request at runtime. For this reason, you must test your application in a wider range of conditions. Before Android, we had enough reason to believe that our program runs, and we had enough permissions because these permissions have been declared in the manifest file. In the new permission model, this is not the case.

If the value is 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 processing SS permission-protectedservices and data.

· Test with various combinations of grantedor revoked permissions. for example, a camera app might listCAMERA, READ_CONTACTS, andACCESS_FINE_LOCATIONin itsmanifest. you shoshould test the app with each of these permissions turned on andoff, to make sure the app can handle all permission executions gracefully.

· Use theadbtoolto 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] 
 
   ...
 

· Analyze your app for services that usepermissions.