Android6.0 Run-time Rights management

Since the release of Android6.0, in the right to make a great change, no longer as long as the manifest settings can be arbitrary access to the rights, but more attention to the user's privacy and experience, will not force users to refuse to have permissions caused by the inability to install things, and will not ask for user authorization, The user's privacy can be accessed arbitrarily, and permissions can be changed in a timely manner even after authorization. This is the 6.0 version of the more support and focus on the user of a large embodiment.

First, cognition

Today we are going to learn the rights management of Android6.0.

The Android6.0 system divides the permissions into two levels:

One is normal Permissions, that is, ordinary permissions, such permissions will not lurk in the privacy and security of users, such as access to network permissions, access to WiFi, etc.;

Another kind is the dangerous Permissions, namely the dangerous permission, this kind of permission can directly threaten the user's security and the privacy question, for example accesses the text message, the album and so on permission.

But in the end what is normal permissions and dangerous permissions, here is the classification, everyone in use for reference.

1. Normal Permissions (normal permission)

• access_location_extra_commands
• access_network_state
• access_notification_policy
• access_wifi_state
• BLUETOOTH
• Bluetooth_admin
• Broadcast_sticky
• change_network_state
• change_wifi_multicast_state
• change_wifi_state
• Disable_keyguard
• Expand_status_bar
• get_package_size
• Install_shortcut
• INTERNET
• kill_background_processes
• modify_audio_settings
• NFC
• read_sync_settings
• Read_sync_stats
• receive_boot_completed
• Reorder_tasks
• request_ignore_battery_optimizations
• request_install_packages
• Set_alarm
• Set_time_zone
• Set_wallpaper
• set_wallpaper_hints
• Transmit_ir
• Uninstall_shortcut
• Use_fingerprint
• Vibrate
• Wake_lock
• write_sync_settings

Using the above permissions is not a threat to user security, so this kind of permission can be directly in the manifest directly in the use of, and after the installation will be directly effective.

2, Dangerous Permissions (dangerous permission)

• SMS (SMS)
  • send_sms
  • receive_sms
  • read_sms
  • receive_wap_push
  • Receive_mms
• STORAGE (memory card)
  • read_external_storage
  • write_external_storage
• CONTACTS (Contact person)
  • read_contacts
  • write_contacts
  • get_accounts
• Phone (MOBILE)
  • read_phone_state
  • call_phone
  • read_call_log
  • write_call_log
  • add_voicemail
  • use_sip
  • process_outgoing_calls
• Calendar (Calendar)
  • Read_calendar
  • Write_calendar
• camera
  • camera
• location
  • access_fine_location
  • access_coarse_location
• Sensors (sensor)
  • body_sensors
• Microphone (microphone)
  • record_audio

Dangerous permissions and ordinary permissions are also different, ordinary permissions are a single permission, and dangerous permissions are displayed in groups, that is, when you accept a dangerous permission, not only but accept the interface to show this permission, but it is in this group of all other access rights will also be automatically acquired permissions , for example, once write_contacts is authorized, the app also has read_contacts and get_accounts permissions.
It is important to note that such permissions are also required to be registered in the manifest.

OK, Light said not practice is not our style, we write things are based on their own problems encountered, and then seriously study after the record. On the one hand to consolidate their knowledge, on the other hand also hope to help others to provide a little solution.

Second, actual combat

The actual combat part is divided into several situations, because according to our target SDK version and the Android version of the real machine will have different scenarios, for ordinary permissions we are familiar with, do not introduce, the following describes the use of dangerous rights scenarios:

Before introducing the usage scenario, look at the Android version of my development and the real machine.

Let's take a short text message for an example to explain the use of the entire permission:

1, without access to the case:

First, let's design the layout, as follows:

Look at the code, it's simple, just read the short note:

Then, click on the interface "read text messages in the Inbox", I believe everyone will know what happened, sure enough unexpected program crashes directly, lay the log:

The log is very clear to tell us that this exception is caused by no permissions, then we directly add to it and read the text message permission to see it.

2. Added Permissions in manifest:

In manifest, you should be happy to wait for a total number of text messages to appear on our interface, but the fact is that it's a real crash:

Again there is an exception with no permissions, which is why?

Here we do not solve this problem, first of all to imagine a practical situation, if your existing app has a lot of use of dangerous permissions, and sometimes you know exactly where to use, But your target version is the same as my version point to 6.0, and the possibility that the user's mobile phone is more than 6.0 version, then this time your app may appear this, then you have not yet found out where the use of dangerous permissions is, how to solve it?

So you can solve this:

Modify the Targetsdkversion target version number in your build.gradle:

Then the phone version is still more than 6.0, to see the results:

Yes, haha, you are very happy, indeed it is possible.

So smart you might realize something, yes, with version 23, which is the android6.0 bit dividing line, we can draw a small conclusion:

When Targetsdkversion >= 23, and the real machine version >= 23 o'clock, even if the corresponding dangerous permissions are added to the manifest, when there is no corresponding processing (as for how to deal with later), there will be a limit of the exception, At this point the dangerous permissions in the manifest do not work, but must also be declared.

When Targetsdkversion < 23, and the real machine version >= 23 o'clock, we did not do any related processing, we get the desired access, which indicates that the dangerous permissions applied in the manifest have worked.

We are looking at another situation, that is, if my phone is older, has not updated 6.0 of the system, in this case, what is the situation?

This time we're using a 4.4.4 version of the simulator

Target targetsdkversion for 21来 look at the results:

is also possible, 0 information is because my simulator does not have the text message, this number is not related to us much. If Targetsdkversion is 23, take a look at the results:

It is clear that we have got the right result again.

From this we also get a small conclusion:

When our real machine system version < 23 o'clock, regardless of whether our targetsdkversion value is greater than 23, will not affect the permissions we apply in manifest, that is, the system version of the real machine is playing a leading role.

From the above conclusions, we should be very clear about the use of access rights in the real machine, but our phones are upgraded, the version will be more and more high, so our current application can not always only support the low version of the use and do not consider the high version. So now the app privilege upgrade is the inevitable trend.

So now come back to solve the problem left above, the real machine and the target version is greater than 6.0 when the permission is abnormal how can we solve it?

It consists of three steps:

1: Check if you have permission

2: If there is no permission, then request permission

3: Handling Permission Callbacks

Let's take a look at these steps separately.

1: Check if you have permission

Check if you have permission to use Contextcompat.checkselfpermission (context context, String permission);

There are two parameters in the Checkselfpermission method, namely the context, and the permission requested.

If you have permission, please let it read the SMS message directly. Apply if you do not have permission.

2: Request permission

The application permission is to use:

public static void Requestpermissions (Final Activity activity,final string[] permissions, final int requestcode) {}

The Requestpermissions method requires three parameters, the current activity, the requested permission, can be multiple, the last is the request code, since there is a request code indicating that it will have a callback, that is, we want to talk about the processing callback.

3: Handling Permission Callbacks

To handle a permission callback, you need to override the Onrequestpermissionsresult method in the activity:

Then within the method to determine whether the user authorized the permission group or deny authorization, if authorized to get the text message, otherwise, here I just show a toast prompt box.

Here again, in the permission group as long as there is one authorized, other permissions have permissions, which is why the direct use of grantresults[0] = = packagemanager.permission_granted reason.

OK, below the specific interface display:

We can see that when we first click to read the text message, it will first check whether the app has permissions, if not, to apply, here in the interface is to display an authorized dialog box, the first time we chose to refuse authorization, And then in the callback it will print one of our toast disappears to remind us to reject the authorization, but when we need to read the text again, it will also go to apply for authorization, then we allow authorization, then we see, in the display text message number of TextView shows the number of text messages. (here 0 is because of the use of the simulator without SMS, this is not the point.) ）

It is worth reminding that when we first choose to refuse authorization, when we click to read the text message again, then in the Authorization dialog box there will be a "no longer remind" prompt, when we refused the authorization, and choose no longer remind, then what will happen? Take a look at the demo:

When repeatedly rejecting and choosing not to mention a reminder, the next time you go to read it will not be to apply for authorization, but directly in the callback stating that the user has refused authorization.

So at this time if the user for a certain need to give the application authorization to do, in fact, it is very simple, in the callback, remind the user to "settings" in the manual to the application authorization, or send a broadcast to open the settings interface and so on, here and I show the reminder "permission has been rejected" basic, just a little optimization, This is not a demo.

In fact, it is almost finished here, but there is a way we can stay, that is Shouldshowrequestpermissionrationale, this method returns false by default, but when the user has denied this permission request last time, Once again you need to apply for this permission, it will return to ture, the moral is that you have rejected once, and the result of a popup authorization box, you need to give me an explanation, why authorization, that is, multiple authorization this permission to explain, so that users know why must be authorized to complete his operation.

Below, take a look at its use:

I here simply pop up a dialog box, explain why to use this permission, and then go again to invoke the permission of this application method, you can with the callback method together under encapsulation, can be better applied.

Look at the interface operation:

The basic difference here is not enough to say, here is just a single application permission, a number of the same can be, we can try it, the basic is the same operation, in addition, in the explanation point, maybe we have an application, need more out of the use of dangerous permissions, so that we need to rewrite the same code, very convenient, So there is a lot of open source code on the Authority framework, we can use it by ourselves.

OK, to this end, I hope you can learn some knowledge, but also many of their own reality, I wish you a happy life.

For more information please pay attention to the platform, blog updates will be timely notification. Love to learn love technology.

Android6.0 Run-time Rights management