Shulou(Shulou.com)06/01 Report--

In this article, the editor introduces in detail the "Android permission mechanism and adaptation method". The content is detailed, the steps are clear, and the details are handled properly. I hope this article "Android authority mechanism and adaptation method" can help you solve your doubts.

I. Summary

Android M has been released for some time, and many applications on the market have adapted to Android M. Permission mechanism, as a major feature of Android M, has attracted the attention of many developers.

II. Android authority mechanism

For those who have already understood the basic knowledge, it is recommended to skip to the third point (QQ Music's experience in authority adaptation).

Before Android6.0, the permission mechanism of Android is relatively simple. Developers declare the required permissions in the AndroidManifest file. When APP is installed, the system prompts the user that APP will obtain the permissions, and the user agrees with the authorization to continue the installation. From then on, APP has been permanently authorized. However, in the same period, iOS will be more flexible in dealing with permissions. Permissions are not granted during installation, but when APP is running, users can decide whether to grant certain permissions to APP according to their own needs. At the same time, users can also easily recall the granted permissions. Obviously, the mechanism of dynamic rights management is more suitable for the privacy protection of users, and the too simple permission mechanism of Android has also been complained by many people. Finally, Android6.0 also released a mechanism for dynamic permissions.

Start adapting and how to be compatible

It is very easy for APP to adapt to Android6.0. You only need to upgrade targetSdkVersion and compileSdkVersion to 23 or above, and add code logic such as permission check application. Many people here will wonder what will happen if they run on Android6.0 models for older versions of APP or on models below Android6.0 for Android6.0-adapted APP. How is it compatible?

1. First of all, the old version of APP (targetSdkVersion is lower than 23), because there is no application logic for adaptation permission, the installation authorization scheme is still adopted when the model above Android6.0 is running.

2. APP adapted to Android6.0 still uses the scheme authorized during installation when running on lower versions of Android systems, but developers should note that the code logic of permission application should only be executed on Android6.0 and above models.

Dangerous permissions and general permissions

At first, programmers who hear that they want to add permission judgment and application code logic may break down: a normal APP of a certain size can easily declare a lot of permissions. Wouldn't it be very troublesome to apply for each permission?

At the very least, Google is wise, not all permissions need to be applied for at run time. Google assesses the privacy hazard of each permission. Permissions are divided into two categories: normal permissions and dangerous permissions. For example, the right to control the vibration of mobile phones does no harm to users. As long as the developer declares this permission, it can always be authorized and cannot be reclaimed after installation. However, permissions such as reading SD card data are obviously dangerous rights, and APP must apply to users for this permission.

Google is still very considerate to our developers. In order to further reduce the workload of development and harass users by applying for permissions, dangerous permissions are grouped according to their respective attributes. For example, read SD card and write SD card, these two permissions are usually declared and used in pairs, so they are divided into a group, and as long as we get any one of the permissions in this permission group, you can get the permissions of the entire permission group. Google's definition and grouping of dangerous permissions is shown in the following figure.

Permission related API description

First of all, in the process of dynamic permission application, developers mainly focus on the process and API as follows:

1. Check whether the permission is granted.

Activity.java

Public int checkSelfPermission (permission)

2. Apply for permission.

Activity.java

Public final void requestPermissions (new String [permission1,permission2,...], requestCode)

At this point, the system authorization pop-up window will pop up (the authorization pop-up window does not support customization, of course).

3. Permission callback.

After the user selects in the system pop-up window, the result will be called back to APP through the onRequestPermissionsResult method of Activity.

Public void onRequestPermissionsResult (int requestCode, String [] permissions, int [] grantResults) {

/ / continue to execute logic or prompt for permission acquisition failure

}

4. Permission description.

If the user chooses to refuse, the next time the APP developer needs to declare this permission, Google recommends that the APP developer give more instructions to the user, so the following API is provided. The returned value of this method will be a little tangled in the process of use (for more information, please see the code block below).

Public boolean shouldShowRequestPermissionRationale (permission)

{

1. If APP does not apply for this permission, return false

2. When the user refuses, if it is checked and no longer prompted, return false.

3. If the user refuses, but if it is not checked and no longer prompted, return true.

Therefore, if you want to prompt the user for the first time, you need to record whether the permission has been applied, and if not, force the pop-up window prompt, rather than according to the return value of this method.

}

Third, QQ Music's experience in authority adaptation.

1. The timing of application varies with different permissions.

QQ Music, as a more complex streaming media application, also needs a lot of permissions, but when to apply for these permissions has become the first to bear the brunt of adaptation 6.0. In view of this problem, we also think about the authority needed, and generally think that the application for authority needs to be divided into two opportunities.

User trigger: this is easy to understand. There are some permissions related to features, such as the right to listen to songs and recognize songs, the permission to take photos on the cover of self-built playlists, and so on, which are not needed when APP is running, so we choose to use the authorization blocking logic when the user triggers or enters the feature.

When the application is started: when combing, we found that some permissions (reading device information, reading and writing SD cards, etc.) are not triggered by users or features, but by network flow-free, login security, log system and other underlying logic triggered all the time. For these permissions, it is more entangled. In retrospect, however, these permissions are usually rights that developers or APP cannot compromise, because if the user does not authorize it, it will affect the function and data of the entire APP. Therefore, we choose a more violent approach, which is blocked when the application is launched. This is also one of the ways suggested by Google.

But it should be noted that to apply for authorization at the beginning, do not coldly pull up the system pop-up window to authorize. It is recommended to use APP's own pop-up window to politely explain to the user why these permissions are needed, for example, unable to read device information, unable to connect and free flow, unable to ensure login security, unable to read SD card, unable to play songs, etc., to avoid being too stiff to cause user resentment. In particular, because of local translation, Google's pop-up window description of permissions is not local. For example, when we apply for permission to read device information, the pop-up window of the system is "phone permission", which can easily lead to misunderstanding by users. Therefore, reasonable guidance and explanation is essential.

2. Application startup authorization requires a shell

As I just said, many invisible permissions have nothing to do with features. So, if we start APP directly and the user is not authorized, a lot of initialization logic is easy because there is no permission crash, even if there is no crash, there may be more or less other problems. Therefore, we need to prohibit the execution of this logic until these permissions are fully granted.

Students who have done startup-related know that it is very complicated to intercept a normal startup of an APP and then recover. Often, we need a shell to isolate the inner shell of the business logic. As far as QQ Music is concerned, we can easily think of the shell loaded by dex, the requirements are also very similar, and dex loading also needs to be done before the business. Along this line of thinking, naturally, we chose to do the blocking logic of permissions in the shell of dex, and quickly and well achieved the desired results. It is believed that most of the APP are divided into dex, so it is suggested to do it in this way, which can save a lot of work.

IV. "chaos" of Android authority mechanism

The chaos we are talking about here actually has something to do with the serious fragmentation of Android. As the domestic ROM becomes more and more individual, many ROM are trying to establish their own permission mechanism, and some even open the native one or develop their own permission mechanism based on Android5.x. In the face of these situations, what we can do is often very limited, to give a few examples.

1. Permission to read motion data

In the process of developing QQ Music running radio station, it was found that the system pop-up window of "apply the permission to read motion data" will be prompted on some models of a domestic ROM. However, repeatedly looking up the relevant API, we found that the step-by-step related Sensor we use does not need to apply for any permission. But if the user chooses to reject, even if APP registers with Sensor, there will be no callback from the system. Later, after contacting the relevant personnel of the manufacturer, the reply was that the third-party APP could not check and apply for this permission, which itself belongs to the manufacturer's own authority mechanism of ROM.

There is a similar case, that is, Mobile Manager of a certain manufacturer will always prompt QQ Music to try to read the application list. In fact, we don't read the list of applications, we just call some API related to PackageManager to trigger this alarm.

For such problems, we suspect that the third-party ROM blocks permissions after it detects that APP calls the relevant API at run time. What developers should note here is that blocked API may not necessarily lead to crash, but it may cause us not to get the correct return value or receive some message callbacks from the system.

2. Unable to add shortcut

After the original announcement, we can create shortcuts on the desktop, and this permission is not a dangerous permission. However, for some domestic ROM, the restrictions on adding shortcuts to APP are relatively strict, and users must manually allow shortcuts to be added in the settings before APP can be added successfully. In this case, APP does not know whether it can add shortcuts or not, so it can only fail silently. Fortunately, it is not the main shortcut that is affected here, and there are shortcut entrances to some functions.

3. Vanishing desktop lyrics, floating window permissions

QQ Music desktop lyrics are realized by adding View to WindowManager. But many domestic ROM have the permission of floating window a long time ago. At first, we changed type to LayoutParams.TYPE_TOAST and declared this normal permission, avoiding most system problems. However, at the end of 2016, with the upgrade of a certain ROM system, this tactic was useless, and a large number of user feedback broke out.

We continued to try to check the floating window permissions and found that the result returned by checkPermission ("android.permission.SYSTEM_ALERT_WINDOW") was always true, so this path could not be taken.

Finally, after various queries, it is found that the floating window permission is not in the permission mechanism of the Android6.0 standard, but a switch bit that has been hidden in the AppOpsManager, corresponding to the 24th switch. It is important to note that the class AppOpsManager has been around for a long time, but many ROM hides the method of checkOp, but it turns out that this method can still be called through reflection to detect whether permissions are turned on.

AppOpsManager manager = (AppOpsManager) context.getSystemService ("appops")

Try {

Object object = invokeMethod (manager, "checkOp", op, Binder.getCallingUid (), getPackageName (context))

Return AppOpsManager.MODE_ALLOWED = (Integer) object

} catch (Exception e) {

MLog.e (TAG, "CheckPermission" + e.toString ())

}

However, to open the floating window permission, the paths of different ROM are different, some are in the settings, some are in the system's own butler, and finally we can only give users different guidance according to different ROM, and finally reduce the amount of feedback.

After reading this, the article "Android permission Mechanism and adaptation method" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself. If you want to know more about related articles, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.