2022-11-19 16:49:57

System Permissions

Android is a privilege-separated operating system, in which each application runs with a distinct system identity (Linux user ID and group ID). Parts of the system are also separated into distinct identities. Linux thereby isolates applications from each other and from the system.

Additional finer-grained security features are provided through a 'permission' mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad hoc access to specific pieces of data.

This document describes how application developers can use the security features provided by Android. A more general Android Security Overview is provided in the Android Open Source Project.

Security Architecture

A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the users private data (such as contacts or emails), reading or writing another applications files, performing network access, keeping the device awake, and so on.

Because each Android application operates in a process sandbox, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox. Applications statically declare the permissions they require, and the Android system prompts the user for consent.

The application sandbox does not depend on the technology used to build an application. In particular the Dalvik VM is not a security boundary, and any app can run native code (see the Android NDK). All types of applications — Java, native, and hybrid — are sandboxed in the same way and have the same degree of security from each other.

Application Signing

All APKs (.apk files) must be signed with a certificate whose private key is held by their developer. This certificate identifies the author of the application. The certificate does not need to be signed by a certificate authority; it is perfectly allowable, and typical, for Android applications to use self-signed certificates. 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 applications 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 packages life on that device. On a different device, the same package may have a different UID; what matters is that each package has a distinct UID on a given device.

Because security enforcement happens at the process level, the code of any two packages cannot normally run in the same process, since they need to run as different Linux users. You can use the sharedUserId attribute in the AndroidManifest.xmls manifest tag of each package to have them assigned the same user ID. By doing this, for purposes of security 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.

Any data stored by an application will be assigned that applications user ID, and not normally accessible to other packages. When creating a new file with getSharedPreferences(String, int), openFileOutput(String, int), or openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory), you can use the MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE flags to allow any other package to read/write the file. When setting these flags, the file is still owned by your application, but its global read and/or write permissions have been set appropriately so any other application can see it.

Using Permissions

A basic Android application has no permissions associated with it by default, meaning it cannot do anything that would adversely impact the user experience or any data on the device. To make use of protected features of the device, you must include one or more lt;uses-permissiongt; tags in your app manifest.

For example, an application that needs to monitor incoming SMS messages would specify:

lt;manifest xmlns:android='http://schemas.android.com/apk/res/android'

package='com.android.app.myapp' gt;

lt;uses-permission android:name='android.permission.RECEIVE_SMS' /gt;



If your app lists normal permissions in its manifest (that is, permissions that dont pose much risk to the users privacy or the devices operation), the system automatically grants those permissions. If your app lists dangerous permissions in its manifest (that is, permissions that could potentially affect the users privacy or the devices normal operation), the system asks the user to explicitly grant those permissions. The way Android makes the requests depends on the system version, and the system version targeted by your app:

If the device is running Android 6.0 (API level 23) or higher, and the apps targetSdkVersion is 23 or higher, the app requests permissions from the user at run-time. The user can revoke the permissions at any time, so the app needs to check whether it has the permissions every time it runs. For more information about requesting permissions in your app, see the Working with System Permissions training guide.

If the device is running Android 5.1 (API level 22) or lower, or the apps targetSdkVersion is 22 or lower, the system asks the user to grant the permissions when the user installs the app. If you add a new permission to an updat



本文档介绍了应用程序开发人员如何使用由Android提供的安全功能。 在Android 开放源代码项目AOSP(Android Open Source Project)中提供了更一般的Android安全性概述。

Android是一种特权分隔的操作系统,在Android上运行的每个应用程序都具有各自独立的系统标识(Linux用户ID和组ID)。 系统各部分有不同的身份标识。因此,Linux上运行的各个应用程序相互独立且与系统无关。


Security Architecture



沙盒程序独立于生成普通应用程序的机制。特别地,Dalvik虚拟机不是一个安全的边界,任何的应用程序都能够运行本地代码(参照Android NDK)。所有类型的应用程序——java、native和混合的——均用相同的方式置以相同的安全等级在沙盒中运行。

Application Signing


User IDs and File Access



任何由应用程序存储的数据将被赋予应用程序的用户ID,正常情况不能被其它应用程序访问。当使用getSharedPreferences(String, int), openFileOutput(String, int), 或 openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory)创建一个新的文件时,可以使用MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE标记允许其他应用程序来读/写文件。设置这些全局的读写权限标记后,该文件仍然为创建文件的应用程序所拥有,任何其他应用程序可以看到它。

Using Permissions

一个基本的android程序是没有任何权限的。也就是说,无论是从用户体验上和设备数据上都没有什么危害。 在产品需求下,为了能够使用设备的受保护特性,你必须在AndroidManifest.xml 里声明至少一种所需要的权限。


lt;manifest xmlns:android='http://schemas.android.com/apk/res/android'

package='com.android.app.myapp' gt;

lt;uses-permission android:name='android.permission.RECEIVE_SMS' /gt;












声明和实施许可-Declaring and Enforcing Permissions



lt;manifest xmlns:android='http://schemas.android.com/apk/res/android'

package='com.me.app.myapp' gt;

lt;permission android:name='com.me.app.myapp.permission.DEADLY_ACTIVITY'




android:protectionLevel='dangerous' /gt;





请注意,这两个标签和描述应提供许可。用户在查看的权限列表(android:label)或单个权限( android:description)的细节时,这些内容会被展现。标签应该简洁的介绍权限保护的关键功能。用几个简单的句子描述拥有该权限可以做什么。惯例是用两个句子,第一句描述权限,第二句警告用户当授权该权限后会发生什么。


lt;string name='permlab_callPhone'gt;directly call phone numberslt;/stringgt;

lt;string name='permdesc_callPhone'gt;Allows the application to call

phone numbers without your intervention. Malicious applications may

cause unexpected calls on your phone bill. Note that this does not

allow the application to call emergency numbers.lt;/stringgt;

可以通过shell命令 adb shell pm list permissions来查看现在系统上的权限定义。特别地,-s选项可以用简单的表格形式来给用户呈现权限。

$ adb shell pm list permissions -s

All Permissions:

Network communication: view Wi-Fi state, create Bluetooth connections, full

Internet access, view network state

Your location: access extra location provider commands, fine (GPS) location,

mock location sources for testing, coarse (network-based) location

Services that cost you money: send SMS messages, directly call phone numbers


在AndroidManifest.xml中声明权限设置-Enforcing Permissions in AndroidManifest.xml

进入系统或应用程序的组件的高级别权限可以在AndroidManifest.xml中实现。所有这些都可以通过在相应的组件中包含 android:permission 属性,以使其被用以控制进入的权限。

Activity权限(应用于activity标签)用于限制谁才可以启动相关的Activity。该权限在运行Context.startActivity()和Activity.startActivityForResult()期间被检查;如果调用方不具有相应必需的权限,那么将会从此次调用中抛出SecurityException 异常。

Service权限(应用于service标签)用于限制谁才可以启动或绑定该service。在运行Context.startService() , Context.stopService()和Context.bindService()调用的时候会进行权限检查。如果调用方没有所需的权限,则会抛出一个SecurityException异常。

BroadcastReceiver许可(应用于receiver标签)用于限制谁可以向相关的接收器发送广播。权限检查会在Context.sendBroadcast()返回后当系统去发送已经提交的广播给相应的Receiver时进行。最终,一个permission failure不会再返回给调用方一个异常,只是不会去实现该Intent而已。同样地,Context.registerReceiver()也可以通过自己的permission用于限制谁可以向一个在程序中注册的receiver发送广播。另一种方式是,一个permission也可以提供给Context.sendBroadcast() 用以限制哪一个BroadcastReceiver才可以接收该广播。

ContentProvider许可(应用于provider标签)用于限制谁才可以访问ContentProvider提供的数据。(Content providers有一套额外的安全机制叫做URI permissions,这些在稍后讨论。)不像其他组件,它有两个单独的权限属性,你可以设置: android:readPermission用于限制谁能够读,android:writePermission用于限制谁能够写。需要注意的是如果provider同时需要读写许可,只有写许可的情况下并不能读取provider中的数据。当你第一次检索内容提供者和当完成相关操作时会进行权限检查。(假如没有任何权限则会抛出SecurityException异常。)使用ContentResolver.query()需要持有读权限;使用ContentResolver.insert(),ContentResolver.update(),ContentResolver.delete()需要写权限。在所有这些情况下,没有所需的权限将会导致抛出SecurityException异常。




您需要先支付 30元 才能查看全部内容!立即支付