[Permission] Security and Permission

[Security Architecture]

• In the Android security architecture, by default,
• No application has permission to perform any operations that would adversely impact other applications, the operating system, or the user.
• ex:
• reading or writing the user's private data (such as contacts or e-mails)
• reading or writing another application's files
• performing network access
• keeping the device awake, etc.
• Applications statically declare the permissions they require, and the Android system prompts the user for consent at the time the application is installed.
• Android has no mechanism for granting permissions dynamically (at run-time) because it complicates the user experience to the detriment of security.

[Application Signing]

• The purpose of certificates in Android is to distinguish application authors.
• This allows the system to grant or deny applications access to signature-level permissions and to grant or deny an application's request to be given the same Linux identity as another application.

[User IDs and File Access]

• At install time, Android gives each package a distinct Linux user ID. 
• The identity remains constant for the duration of the package's life on that device. On a different device, the same package may have a different UID
• Because security enforcement happens at the process level, the code of any two packages can not normally run in the same process, since they need to run as different Linux users.
• The two packages are then treated as being the same application, with the same user ID and file permissions.
• Note that in order to retain security, only two applications signed with the same signature (and requesting the same sharedUserId) will be given the same user ID.

[Using Permissions]

• A basic Android application has no permissions associated with it, meaning it can not do anything that would adversely impact the user experience or any data on the device.
• A particular permission may be enforced at a number of places during your program's operation:
• At the time of a call into the system, to prevent an application from executing certain functions.
• When starting an activity, to prevent applications from launching activities of other applications.
• Both sending and receiving broadcasts, to control who can receive your broadcast or who can send a broadcast to you.
• When accessing and operating on a content provider.
• Binding to or starting a service.

[Declaring and Enforcing Permissions]
For example, an application that wants to control who can start one of its activities could declare a permission for this operation as follows:

• <protectionLevel>
• Is required.
• Telling the system how the user is to be informed of applications requiring the permission, or who is allowed to hold that permission.
• <permissionGroup>
• Is optional, and only used to help the system display permissions to the user.
• <android:label>
• Should be supplied.
• Can be displayed to the user when they are viewing a list of permissions.
• <android:description>
• Should be supplied.
• Details on a single permission 
• Our convention for the description is two sentences.
• The first describing the permission.
• The second warning the user of what bad things can happen if an application is granted the permission.
• You can look at the permissions currently defined in the system with the shell command adb shell pm list permissions. 
• In particular, the '-s' option displays the permissions in a form roughly similar to how the user will see them.
• ex: adb shell pm list permissions -s

[Enforcing Permissions in AndroidManifest.xml]

• Activity, Service, BroadcastReceiver, ContentProvider if the caller does not have the required permission then SecurityException is thrown from the call.
• 其中 ContentProvider 還可分以下兩種 permission:
• android:readPermission
• Using ContentResolver.query() requires holding the read permission.
• android:writePermission
• Using ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete() requires the write permission.

[Enforcing Permissions when Sending Broadcasts]

• public abstract void sendBroadcast (Intent intent, String receiverPermission)
• receiverPermission: (optional) String naming a permission that a receiver must hold in order to receive your broadcast. If null, no permission is required.

[URI Permissions]

• The solution to this problem is per-URI permissions: 
• when starting an activity or returning a result to an activity, the caller can set Intent.FLAG_GRANT_READ_URI_PERMISSION and/or Intent.FLAG_GRANT_WRITE_URI_PERMISSION. 
• This grants the receiving activity permission access the specific data URI in the Intent, regardless of whether it has any permission to access data in the content provider corresponding to the Intent.
• .....

[API]

• android:protectionLevel
• The default value is normal.
• android:sharedUserId
• By default, Android assigns each application its own unique user ID.
• If this attribute is set to the same value for two or more applications, they will all share the same ID — provided that they are also signed by the same certificate.
• Application with the same user ID can access each other's data and, if desired, run in the same process.
• Manifest.permission
• SecurityException

* Reference
- Security and Permissions
- android自定义权限
- Android开发指南-框架主题-安全和许可