Various privileges in Android deep experience and detailed

Various privileges in Android deep experience and detailed

Category: Android2012-07-15 19:27 2822 people Read reviews (0) Favorite reports

Androidpermissionsinstallersystemserviceinteger

I. Permissions (permission)

Permissions are used to describe whether you have the power to do something. The permissions in the Android system are divided into normal level (normal), hazard level (dangerous), signature level (signature), and System/signature level (signature or systems). All predefined permissions in the system belong to different levels depending on the role.
For normal and dangerous levels of permissions, we call it low-level permissions, which are granted as application applications. Other level two permissions, which we call advanced permissions or system permissions, apply with the platform level of authentication. When an app tries to do a restricted operation without permission, the app will be killed by the system to alert.
Any permissions can be used by the system app. This permission can be used unconditionally by the declarator of the permission.
Currently the Android system defines a number of permissions that can be queried by the SDK documentation user to what permissions are required and then applied on demand.
In order to perform your own permissions, you must first use one or more <permission> tag declarations in your androidmanifest.xml. For example, an application that wants to control who can start a activities, which can declare a license to do this, is as follows:

<manifest xmlns:android= "Http://schemas. Android. Com/apk/res/android "package=" Com.me.app.myapp "> <permission android:name=" Com.me.app.myapp.permission.DEADLY_ACTIVITY "android:label=" @string/permlab_deadlyactivity "android:description= "@string/permdesc_deadlyactivity" android:permissiongroup= "Android.permission-group.cost_money" Android: protectionlevel= "Dangerous"/> </manifest>

Two. Permission to use

The permissions required by the application should be applied in the Users-permission attribute, and the requested permission should be defined by the system or an application, otherwise it will be considered an invalid application. At the same time, applications that use permissions need to follow permission grant criteria, and non-platform certified Apps cannot request advanced permissions.

Therefore, there are roughly two types of access permissions between programs:
The first low-level point (Permission's Protectlevel property is normal or dangerous), and its caller apk simply declares <uses-permission> can have its permission.
The second advanced point (Permission's Protectlevel property is signature or Signatureorsystem), and its caller apk needs to have the same signature as the apk being called.

When an application is installed, the permissions requested by the application is approved for acquisition by the package installer. Package Installer determines whether to grant the program request permission by checking the application's signature. The user does not check the permissions during use, that is, either approve the permission at the time of installation, make it available by design, or do not approve it so that the user is not able to use the feature at all, and there is no hint that the user will fail.
For example, advanced permissions require an API with system-level permissions, so that their apk has system permissions. For example, there is a systemclock.setcurrenttimemillis () function in the Android API to modify the system time. There are two ways of doing this:

The first method is simple, but it needs to be compiled with make in the case of the Android system source code:
1. android:shareduserid= the "Android.uid.system" attribute in the manifest node of the application's androidmanifest.xml.
2. Modify the Android.mk file, intervene local_certificate: = Platform this line
3. Using the MM command to compile, the generated apk will have to modify the system time of the terms of reference

The 2nd method troublesome point, but does not eliminate the virtual machine to run to the source code situation with make to compile:
1. As above, meddle with the android:shareduserid= "Android.uid.system" attribute.
2. Use eclipse to compile the apk file, but this apk file is not available.
3. Use the PIN system's platform password key to sign the APK file from scratch. signapk Platform.x509.pem platform.pk8 input.apk output.apk

Three. Custom permission

The permissions defined by the Android system can be found in the manifest.permission. Any program can define and enforce its own unique permissions, so the permissions defined in Manifest.permission is not a complete list (that is, it can have a custom permissions).
A particular permission may be enforced in many parts of the program's operations:
When the system has a call, to prevent the program to perform other functions.
When an activity is started, the application is prevented from launching the acitivity of other applications.
When sending and receiving broadcasts, go to control who can receive your broadcast or who can send you the broadcast.
When entering and manipulating a content provider.
When binding or starting a service.

Four. Component Permissions

The

can set advanced permissions through the Androidmanifest.xml file to restrict access to all components of the system or to use the application. All of these requests are contained in the Android:permission property of the component you need, and naming this permission can control access to this component.
1. Activity Permissions (use <activity> tags) restrict the ability to initiate components or applications associated with activity permissions. Checked during context.startactivity () and Activity.startactivityforresult ();
2 . Service permissions (Apps <service> tags) restrict the components or applications that start, bind, or start and bind the associated service. This permission is checked during Context.startservice (), Context.stopservice (), and Context.bindservice ();
3 . Broadcastreceiver Permissions (Apps <receiver> tags) restrict the components or applications that can send broadcasts to the associated recipients. This permission is checked after Context.sendbroadcast () is returned, and the system tries to deliver the broadcast to the relevant recipient. Therefore, a permission failure will cause an exception to be thrown back to the caller, and it will not be delivered to the destination. In the same way, you can enable Context.registerreceiver () to support a permission that controls the ability to deliver components or applications that are broadcast to the recipient of a registered program. Other, when calling Context.sendbroadcast () to limit the broadcast recipient object that can be allowed to receive broadcasts (see below).
4 . ContentProvider permissions (using <provider> tags) are used to restrict the components or applications that can access data in ContentProvider.
If the caller does not request permission, a security exception (SecurityException) is thrown for the call. In all these cases, a SecurityException exception is thrown from a caller without storing the requested permission result.

Five. Support permissions when sending broadcasts

When sending a broadcast you can always specify a request permission, this permission in addition to the permission execution, other can send intent to a registered Broadcastreceiver permission can be. by calling Context.sendbroadcast () and some permission strings, in order to receive your broadcast, you request that a receiver application must hold that permission. Note that both the receiver and the broadcaster can request a permission. When such a thing happens, for intent, both permission checks must pass, in order to deliver to a common destination.

Six. Other rights support

Any fine-grained permissions (more granular permissions) can be set in the process of invoking the service. This is done through the Context.checkcallingpermission () method. A call is made using a desired permission string, which can then be returned to the caller as an integer when the permission is granted (an integer is returned if not approved). It is important to note that this situation can only occur in calls from another process, typically a service-published IDL interface, or other processes that are provided to others.
Android offers a number of other ways to check permissions. If you have the PID of another process, you can use the context method Context.checkpermission (String, int, int) to check the permission for that PID. If you have a package name for another application, you can use the Packagemanager method Packagemanager.checkpermission (String, string) directly To determine if the package already has the appropriate permissions.

Seven. Uri permissions

The standard permission system we have discussed so far is not enough for content provider. A content provider may want to protect its read and write permissions, while the immediate client corresponding to it also needs to pass a specific URI to other applications so that the URI can be manipulated by other applications. A typical example is a mail program that handles messages with attachments. Access to messages requires the use of permission to protect them, as these are sensitive user data. However, if there is a URI to the picture attachment that needs to be passed to the picture browser, the image browser will not have access to the attachment because he cannot have access to all the messages.
The solution to this problem is Per-uri permission: when initiating an activity or returning a result to an activity, the caller can set the intent.flag_grant_read_uri_permission and /or Intent.flag_grant_write_uri_permission. This causes the activity that receives the intent to gain access to the URI specified by the intent, regardless of whether it has permission to enter the intent corresponding content provider.

This mechanism allows a common Capability-style model, which is driven by user interaction (such as opening an attachment, selecting a contact from a list), and specifically acquiring fine-grained permissions (finer grained permissions). This is an important way to reduce unnecessary permissions, and this is primarily about permissions that are directly related to the behavior of the program.
The acquisition of these URI permission requires a mate of the content provider (which contains those URIs). It is highly recommended to provide this capability in content provider and to declare support through android:granturipermissions or <grant-uri-permissions> tags.

Eight. Summary

1. Can I have access to data or features with normal or dangerous permissions without declaring <uses-permission> signature permissions?

As long as the signature is the same, access sets the data or features set by normal or dangerous permissions even if you do not explicitly declare <ues-permission>.

2. How do I use the system-level permissions to use the Systems API (that is, using the signature at system level), and how do other apk functions with other signature permission settings (that is, using signature level signatures)?
Users with system-level permissions can declare functionality that has been set by access to other common signature rights.
Therefore, it is set to have system level permissions.

Various privileges in Android deep experience and detailed