Detailed Android6.0 runtime Rights Management _android

Since the release of Android6.0, great changes have been made in terms of authority, is no longer the previous as long as in the manifest settings can be arbitrary access to permissions, but more attention to the user's privacy and experience, no longer forced the user to deny the rights caused by the inability to install things, and will not ask for user authorization, Access to user privacy is arbitrary and 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's one big embodiment.

First, cognitive

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

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

One is normal Permissions, that is, normal permissions, such permissions do not hide the user's privacy and security issues, such as access to the network, access to WiFi permissions, etc.;

The other is dangerous Permissions, that is, dangerous permissions, such permissions will directly threaten the user's security and privacy issues, such as access to text messages, photo albums and other permissions.

But in the end which is the general permissions and dangerous permissions, here are given the classification, we use for reference.

1, Normal Permissions (normal permissions)

• access_location_extra_commands
• access_network_state
• access_notification_policy
• access_wifi_state
• BLUETOOTH
• bluetooth_admin
• broadcast_sticky
• change_network_s TATE
• change_wifi_multicast_state
• change_wifi_state
• disable_keyguard
• Expand_sta Tus_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
• WR Ite_sync_settings

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

2, Dangerous Permissions (dangerous authority)

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 (calendars)

• Read_calendar
• Write_calendar

CAMERA (camera)

• CAMERA

LOCATION (location)

• Access_fine_location
• Access_coarse_location

Sensors (sensor)

• Body_sensors

Microphone (microphone)

• Record_audio

Dangerous 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 authority, not only accept the interface on the display of this permission, Instead, all of the other access rights in this group will be automatically accessed , for example, once the write_contacts is authorized, the app also has read_contacts and get_accounts privileges.
It is noteworthy that such permissions are also required to be registered in manifest.

OK, light say not practice is not our style, I write things are based on their own problems, and then carefully study before recording down. On the one hand to consolidate their knowledge, on the other hand, also hope to help others to provide a point solution.

Second, the actual combat

The actual part is divided into several situations, because according to our target SDK version and the Android version of the different scenarios, for common permissions are familiar with, do not introduce, the following describes the use of dangerous permissions scenarios:

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

Here we take the short message as an example to explain the use of the entire permission:

1, without access to the case:

First we'll design the following layout, as follows:

Look at the code, very simple, directly read the short interest:

Then, click on the interface "read the message in the Inbox", I believe that everyone will know what happened, and sure enough, no accident of the program directly collapsed, lay the log:

The log is very clear to tell us that this exception is due to the lack of permissions, then we directly to the text and read the 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 in our interface, but the fact is that they are very much broken:

Again, there is no permission exception, this is why?

Let's not solve this problem first, imagine a real situation, if your existing app has a lot of dangerous access, sometimes you know exactly where to use it, But your target version, like my version, points to 6.0, and it is possible that the user's mobile phone is more than 6.0 version, then this time your app is likely to appear this way, then you have not found out where to use dangerous authority is, how to solve it?

Then you can solve this:

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

And then the phone version is 6.0 or more, to see the results:

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

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

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

When Targetsdkversion < 23, and the true machine version >= 23 o'clock, we did not do any related processing, we got the desired access rights, which indicates that the application of the dangerous permissions in manifest to work.

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

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

Target targetsdkversion for 21来 look at the results:

is also OK, 0 message is because my simulator has no text message, this number and we have no relationship. If Targetsdkversion is 23, take a look at the results:

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

And so we've got a little conclusion:

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

From the above several conclusions, we should be very clear to know the access rights in the real machine usage, but our mobile phones are upgraded, the version will become more and more, so our current application can not always support the use of the lower version and do not consider the high version. So now app privilege escalation is an inevitable trend.

So now come back to solve the problems left above, the real machine and the target version is greater than 6.0 when the permissions are abnormal how do we solve it?

Mainly divided into three steps:

1: Check to see if you have permission

2: If you do not have permission, then apply for permission

3: Processing Permission callback

Now let's take a look at these steps separately.

1: Check to see if you have permission

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

The Checkselfpermission method has two parameters, namely, the context, and the requested permission.

If you have permission, please let it read the message directly. If you do not have permission to apply.

2: Apply for permission

The request permission is to use:

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

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

3: Processing Permission callback

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

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

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

OK, the following is the specific interface to display:

We can see that when we first click to read the text message, it will first check whether the application has permission, if not, to apply, here in the interface corresponds to the display of an authorized dialog box, the first time we chose to deny authorization, And then in the callback, it's going to 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 apply for authorization, when we allow authorization, and then we see that the number of messages displayed in the TextView shows the number of messages. (Here are 0 because of the simulator with no text messages, this is not the point.) ）

It's worth reminding that when we first chose to deny authorization, when we clicked to read the text again, there would be a "no more reminders" Prompt in the authorization dialog, what would happen if we refused the authorization and chose not to remind you? Please see demo:

When you reject it multiple times and choose not to mention it, the next time you read it, you are not going to apply for authorization, but you are simply stating in the callback that the user has denied authorization.

So what if the user had to give the application authorization for some kind of need? In fact, it is very simple, in the callback, to remind users to "set" inside 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 denied" basically the same, just a little optimization can be, This is not a demo.

Actually it's almost finished here, but there's a way we can stay, that's Shouldshowrequestpermissionrationale, this method returns false by default, but when the user has already rejected this permission request the previous time, When you need to request this permission again, will return to ture, it is the moral that you have refused once, the result of a pop-up authorization box, you need to give me an explanation, why to authorize, that is, the authority of multiple authorization to explain, so that users know why must authorize to complete his operation.

Here, let's look at its use:

I have a simple pop-up dialog here, explaining why to use this permission, and then again to invoke the permission of the application method, we can with the callback method of encapsulation, can be better application.

Look at the next interface operation:

When it comes to the basics, here's a single request, a number of together is also possible, we can try, the basic is the same operation, in addition to the point, may be one of our applications, need to use more than dangerous permissions, so that we need to rewrite the same code many times, it is not convenient, So there is a lot of online on the framework of the open source code, we can use their own.

OK, here is the end, I hope we can learn a little knowledge, but also many of their own reality, I wish you a happy life.

The above is the entire content of this article, I hope the content of this article for everyone's study or work can bring some help, but also hope that a lot of support cloud Habitat community!