android_frameworks_base/core/res/AndroidManifest.xml

1738 lines
90 KiB
XML
Raw Normal View History

<?xml version="1.0" encoding="utf-8"?>
<!--
/* //device/apps/common/AndroidManifest.xml
**
** Copyright 2006, The Android Open Source Project
**
** Licensed under the Apache License, Version 2.0 (the "License");
** you may not use this file except in compliance with the License.
** You may obtain a copy of the License at
**
** http://www.apache.org/licenses/LICENSE-2.0
**
** Unless required by applicable law or agreed to in writing, software
** distributed under the License is distributed on an "AS IS" BASIS,
** WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
** See the License for the specific language governing permissions and
** limitations under the License.
*/
-->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="android" coreApp="true" android:sharedUserId="android.uid.system"
android:sharedUserLabel="@string/android_system_label">
<!-- ================================================ -->
<!-- Special broadcasts that only the system can send -->
<!-- ================================================ -->
<eat-comment />
<protected-broadcast android:name="android.intent.action.SCREEN_OFF" />
<protected-broadcast android:name="android.intent.action.SCREEN_ON" />
<protected-broadcast android:name="android.intent.action.USER_PRESENT" />
<protected-broadcast android:name="android.intent.action.TIME_TICK" />
<protected-broadcast android:name="android.intent.action.TIMEZONE_CHANGED" />
<protected-broadcast android:name="android.intent.action.BOOT_COMPLETED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_INSTALL" />
<protected-broadcast android:name="android.intent.action.PACKAGE_ADDED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_REPLACED" />
Implement issue #3426299: Introduce application "stopped" state The package manager now keeps track of whether an application is stopped. There are new intent flags to control whether intent filters in a stopped application will match the intent. This is currently used in one place, sending broadcasts, so that stopped apps can not be launched due to background processes. The package manager during first init makes sure no applications are in the stopped state. When new applications are installed, that begin in the stopped state. When the activity manager is launching a component of an application, it ensures the application is taken out of the stopped state. The "force stop" button in manage applications will now put an application back in to the stopped state; it can't go back out of the stopped state until one of its components is launched by the activity manager. There will probably be a few more places where we need to filter stopped applications out of intent matches, but doing this for broadcast is a very big first step. This also introduces a new broadcast that is sent to an application after it is replaced with a new .apk. But only if the app is not in the stopped state. This makes it a lot easier for developers to implement code to get their application back in proper running shape after an upgrade. Finally another new broadcast is added that is sent to a package's installer at the first time it is launched. This allows the installer to tell the package about it being installed only when it is first actually used. Change-Id: I589c53ff0e0ece868fe734ace4439c0d202dca2d
2011-02-24 14:40:20 -08:00
<protected-broadcast android:name="android.intent.action.MY_PACKAGE_REPLACED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_REMOVED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_FULLY_REMOVED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_CHANGED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_RESTARTED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_DATA_CLEARED" />
Implement issue #3426299: Introduce application "stopped" state The package manager now keeps track of whether an application is stopped. There are new intent flags to control whether intent filters in a stopped application will match the intent. This is currently used in one place, sending broadcasts, so that stopped apps can not be launched due to background processes. The package manager during first init makes sure no applications are in the stopped state. When new applications are installed, that begin in the stopped state. When the activity manager is launching a component of an application, it ensures the application is taken out of the stopped state. The "force stop" button in manage applications will now put an application back in to the stopped state; it can't go back out of the stopped state until one of its components is launched by the activity manager. There will probably be a few more places where we need to filter stopped applications out of intent matches, but doing this for broadcast is a very big first step. This also introduces a new broadcast that is sent to an application after it is replaced with a new .apk. But only if the app is not in the stopped state. This makes it a lot easier for developers to implement code to get their application back in proper running shape after an upgrade. Finally another new broadcast is added that is sent to a package's installer at the first time it is launched. This allows the installer to tell the package about it being installed only when it is first actually used. Change-Id: I589c53ff0e0ece868fe734ace4439c0d202dca2d
2011-02-24 14:40:20 -08:00
<protected-broadcast android:name="android.intent.action.PACKAGE_FIRST_LAUNCH" />
<protected-broadcast android:name="android.intent.action.PACKAGE_NEEDS_VERIFICATION" />
<protected-broadcast android:name="android.intent.action.UID_REMOVED" />
<protected-broadcast android:name="android.intent.action.CONFIGURATION_CHANGED" />
<protected-broadcast android:name="android.intent.action.LOCALE_CHANGED" />
<protected-broadcast android:name="android.intent.action.BATTERY_CHANGED" />
<protected-broadcast android:name="android.intent.action.BATTERY_LOW" />
<protected-broadcast android:name="android.intent.action.BATTERY_OKAY" />
<protected-broadcast android:name="android.intent.action.ACTION_POWER_CONNECTED" />
<protected-broadcast android:name="android.intent.action.ACTION_POWER_DISCONNECTED" />
<protected-broadcast android:name="android.intent.action.ACTION_SHUTDOWN" />
<protected-broadcast android:name="android.intent.action.DEVICE_STORAGE_LOW" />
<protected-broadcast android:name="android.intent.action.DEVICE_STORAGE_OK" />
Allow incoming SMS until internal storage is almost full. Fix for bug 2382830: new incoming SMS should not be rejected when running low on internal phone storage. Testing revealed that the /data partition should have at least 256 KiB available in order to prevent random app crashes (including system apps) due to SQLite transaction failures. With 256 KiB free, the device should safely boot without storage full errors. This takes into account the 36-40 KiB that the YAFFS2 filesystem reports as available even after the partition has been completely filled. I've set the default full threshold to 1 MiB to provide a generous safety margin. For this bug, I changed the DeviceStorageMonitorService demon to send two new hidden notifications for device storage "full" and "not full", when the free space falls below the full threshold (default 1 MiB, but configurable as a system setting), in addition to the existing storage low/okay notifications sent when the storage crosses the threshold of 90% full (also configurable). The SMS code was changed to use these new notifications so that it can accept messages until the data partition has been filled to the maximum safe capacity rather than stopping when it hits 90% full. There should be no negative impact on battery life because the additional check in the storage polling service should be offset by an optimization to cache the free threshold values which were previously being computed every time through the loop. While testing this change, I discovered that SMSDispatcher was being instantiated twice, the first time in GSMPhone/CDMAPhone, and the second time in SimSmsInterfaceManager / RuimSmsInterfaceManager. Changed the code to pass the original SMSDispatcher to the Sim/RuimSmsInterfaceManager constructor. Change-Id: Ie0c6d05294778ab6ee42e0fa01313af96d824c77
2010-08-23 18:16:48 -07:00
<protected-broadcast android:name="android.intent.action.DEVICE_STORAGE_FULL" />
<protected-broadcast android:name="android.intent.action.DEVICE_STORAGE_NOT_FULL" />
<protected-broadcast android:name="android.intent.action.NEW_OUTGOING_CALL" />
<protected-broadcast android:name="android.intent.action.REBOOT" />
<protected-broadcast android:name="android.intent.action.DOCK_EVENT" />
<protected-broadcast android:name="android.intent.action.MASTER_CLEAR_NOTIFICATION" />
<protected-broadcast android:name="android.intent.action.USER_ADDED" />
<protected-broadcast android:name="android.intent.action.USER_REMOVED" />
<protected-broadcast android:name="android.intent.action.USER_SWITCHED" />
<protected-broadcast android:name="android.app.action.ENTER_CAR_MODE" />
<protected-broadcast android:name="android.app.action.EXIT_CAR_MODE" />
<protected-broadcast android:name="android.app.action.ENTER_DESK_MODE" />
<protected-broadcast android:name="android.app.action.EXIT_DESK_MODE" />
<protected-broadcast android:name="android.backup.intent.RUN" />
<protected-broadcast android:name="android.backup.intent.CLEAR" />
<protected-broadcast android:name="android.backup.intent.INIT" />
<protected-broadcast android:name="android.bluetooth.adapter.action.STATE_CHANGED" />
<protected-broadcast android:name="android.bluetooth.adapter.action.SCAN_MODE_CHANGED" />
<protected-broadcast android:name="android.bluetooth.adapter.action.DISCOVERY_STARTED" />
<protected-broadcast android:name="android.bluetooth.adapter.action.DISCOVERY_FINISHED" />
<protected-broadcast android:name="android.bluetooth.adapter.action.LOCAL_NAME_CHANGED" />
<protected-broadcast android:name="android.bluetooth.adapter.action.CONNECTION_STATE_CHANGED" />
<protected-broadcast android:name="android.bluetooth.device.action.FOUND" />
<protected-broadcast android:name="android.bluetooth.device.action.DISAPPEARED" />
<protected-broadcast android:name="android.bluetooth.device.action.CLASS_CHANGED" />
<protected-broadcast android:name="android.bluetooth.device.action.ACL_CONNECTED" />
<protected-broadcast android:name="android.bluetooth.device.action.ACL_DISCONNECT_REQUESTED" />
<protected-broadcast android:name="android.bluetooth.device.action.ACL_DISCONNECTED" />
<protected-broadcast android:name="android.bluetooth.device.action.NAME_CHANGED" />
<protected-broadcast android:name="android.bluetooth.device.action.BOND_STATE_CHANGED" />
<protected-broadcast android:name="android.bluetooth.device.action.NAME_FAILED" />
<protected-broadcast android:name="android.bluetooth.device.action.PAIRING_REQUEST" />
<protected-broadcast android:name="android.bluetooth.device.action.PAIRING_CANCEL" />
<protected-broadcast android:name="android.bluetooth.device.action.CONNECTION_ACCESS_REPLY" />
<protected-broadcast
android:name="android.bluetooth.headset.profile.action.CONNECTION_STATE_CHANGED" />
<protected-broadcast
android:name="android.bluetooth.headset.profile.action.AUDIO_STATE_CHANGED" />
<protected-broadcast
android:name="android.bluetooth.headset.action.VENDOR_SPECIFIC_HEADSET_EVENT" />
<protected-broadcast
android:name="android.bluetooth.a2dp.profile.action.CONNECTION_STATE_CHANGED" />
<protected-broadcast
android:name="android.bluetooth.a2dp.profile.action.PLAYING_STATE_CHANGED" />
<protected-broadcast
android:name="android.bluetooth.input.profile.action.CONNECTION_STATE_CHANGED" />
<protected-broadcast
android:name="android.bluetooth.pan.profile.action.CONNECTION_STATE_CHANGED" />
<protected-broadcast android:name="android.hardware.usb.action.USB_STATE" />
<protected-broadcast android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED" />
<protected-broadcast android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED" />
<protected-broadcast android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" />
<protected-broadcast android:name="android.hardware.usb.action.USB_DEVICE_DETACHED" />
<protected-broadcast android:name="android.net.conn.CONNECTIVITY_CHANGE" />
<protected-broadcast android:name="android.net.conn.CONNECTIVITY_CHANGE_IMMEDIATE" />
<protected-broadcast android:name="android.nfc.action.LLCP_LINK_STATE_CHANGED" />
<protected-broadcast android:name="com.android.nfc_extras.action.RF_FIELD_ON_DETECTED" />
<protected-broadcast android:name="com.android.nfc_extras.action.RF_FIELD_OFF_DETECTED" />
<protected-broadcast android:name="com.android.nfc_extras.action.AID_SELECTED" />
<protected-broadcast android:name="android.nfc.action.TRANSACTION_DETECTED" />
<protected-broadcast android:name="android.intent.action.CLEAR_DNS_CACHE" />
<protected-broadcast android:name="android.intent.action.PROXY_CHANGE" />
<protected-broadcast android:name="android.os.UpdateLock.UPDATE_LOCK_CHANGED" />
<!-- ====================================== -->
<!-- Permissions for things that cost money -->
<!-- ====================================== -->
<eat-comment />
<!-- Used for permissions that can be used to make the user spend money
without their direct involvement. For example, this is the group
for permissions that allow you to directly place phone calls,
directly send SMS messages, etc. -->
<permission-group android:name="android.permission-group.COST_MONEY"
android:label="@string/permgrouplab_costMoney"
android:description="@string/permgroupdesc_costMoney" />
<!-- Allows an application to send SMS messages. -->
<permission android:name="android.permission.SEND_SMS"
android:permissionGroup="android.permission-group.COST_MONEY"
android:protectionLevel="dangerous"
android:label="@string/permlab_sendSms"
android:description="@string/permdesc_sendSms" />
<!-- Allows an application to send SMS messages via the Messaging app with no user
input or confirmation.
@hide -->
<permission android:name="android.permission.SEND_SMS_NO_CONFIRMATION"
android:permissionGroup="android.permission-group.COST_MONEY"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_sendSmsNoConfirmation"
android:description="@string/permdesc_sendSmsNoConfirmation" />
<!-- Allows an application to initiate a phone call without going through
the Dialer user interface for the user to confirm the call
being placed. -->
<permission android:name="android.permission.CALL_PHONE"
android:permissionGroup="android.permission-group.COST_MONEY"
android:protectionLevel="dangerous"
android:label="@string/permlab_callPhone"
android:description="@string/permdesc_callPhone" />
<!-- ================================== -->
<!-- Permissions for accessing messages -->
<!-- ================================== -->
<eat-comment />
<!-- Used for permissions that allow an application to send messages
on behalf of the user or intercept messages being received by the
user. This is primarily intended for SMS/MMS messaging, such as
receiving or reading an MMS. -->
<permission-group android:name="android.permission-group.MESSAGES"
android:label="@string/permgrouplab_messages"
android:description="@string/permgroupdesc_messages" />
<!-- Allows an application to monitor incoming SMS messages, to record
or perform processing on them. -->
<permission android:name="android.permission.RECEIVE_SMS"
android:permissionGroup="android.permission-group.MESSAGES"
android:protectionLevel="dangerous"
android:label="@string/permlab_receiveSms"
android:description="@string/permdesc_receiveSms" />
<!-- Allows an application to monitor incoming MMS messages, to record
or perform processing on them. -->
<permission android:name="android.permission.RECEIVE_MMS"
android:permissionGroup="android.permission-group.MESSAGES"
android:protectionLevel="dangerous"
android:label="@string/permlab_receiveMms"
android:description="@string/permdesc_receiveMms" />
<!-- Allows an application to receive emergency cell broadcast messages,
to record or display them to the user. Reserved for system apps.
@hide Pending API council approval -->
<permission android:name="android.permission.RECEIVE_EMERGENCY_BROADCAST"
android:permissionGroup="android.permission-group.MESSAGES"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_receiveEmergencyBroadcast"
android:description="@string/permdesc_receiveEmergencyBroadcast" />
<!-- Allows an application to read previously received cell broadcast
messages and to register a content observer to get notifications when
a cell broadcast has been received and added to the database. For
emergency alerts, the database is updated immediately after the
alert dialog and notification sound/vibration/speech are presented.
The "read" column is then updated after the user dismisses the alert.
This enables supplementary emergency assistance apps to start loading
additional emergency information (if Internet access is available)
when the alert is first received, and to delay presenting the info
to the user until after the initial alert dialog is dismissed.
@hide Pending API council approval -->
<permission android:name="android.permission.READ_CELL_BROADCASTS"
android:permissionGroup="android.permission-group.MESSAGES"
android:protectionLevel="dangerous"
android:label="@string/permlab_readCellBroadcasts"
android:description="@string/permdesc_readCellBroadcasts" />
<!-- Allows an application to read SMS messages. -->
<permission android:name="android.permission.READ_SMS"
android:permissionGroup="android.permission-group.MESSAGES"
android:protectionLevel="dangerous"
android:label="@string/permlab_readSms"
android:description="@string/permdesc_readSms" />
<!-- Allows an application to write SMS messages. -->
<permission android:name="android.permission.WRITE_SMS"
android:permissionGroup="android.permission-group.MESSAGES"
android:protectionLevel="dangerous"
android:label="@string/permlab_writeSms"
android:description="@string/permdesc_writeSms" />
<!-- Allows an application to monitor incoming WAP push messages. -->
<permission android:name="android.permission.RECEIVE_WAP_PUSH"
android:permissionGroup="android.permission-group.MESSAGES"
android:protectionLevel="dangerous"
android:label="@string/permlab_receiveWapPush"
android:description="@string/permdesc_receiveWapPush" />
<!-- =============================================================== -->
<!-- Permissions for accessing personal info (contacts and calendar) -->
<!-- =============================================================== -->
<eat-comment />
<!-- Used for permissions that provide access to the user's private data,
such as contacts, calendar events, e-mail messages, etc. This includes
both reading and writing of this data (which should generally be
expressed as two distinct permissions). -->
<permission-group android:name="android.permission-group.PERSONAL_INFO"
android:label="@string/permgrouplab_personalInfo"
android:description="@string/permgroupdesc_personalInfo" />
<!-- Allows an application to read the user's contacts data. -->
<permission android:name="android.permission.READ_CONTACTS"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_readContacts"
android:description="@string/permdesc_readContacts" />
<!-- Allows an application to write (but not read) the user's
contacts data. -->
<permission android:name="android.permission.WRITE_CONTACTS"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_writeContacts"
android:description="@string/permdesc_writeContacts" />
<!-- Allows an application to read the user's call log. -->
<permission android:name="android.permission.READ_CALL_LOG"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_readCallLog"
android:description="@string/permdesc_readCallLog" />
<!-- Allows an application to write (but not read) the user's
contacts data. -->
<permission android:name="android.permission.WRITE_CALL_LOG"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_writeCallLog"
android:description="@string/permdesc_writeCallLog" />
<!-- Allows an application to read the user's personal profile data. -->
<permission android:name="android.permission.READ_PROFILE"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_readProfile"
android:description="@string/permdesc_readProfile" />
<!-- Allows an application to write (but not read) the user's
personal profile data. -->
<permission android:name="android.permission.WRITE_PROFILE"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_writeProfile"
android:description="@string/permdesc_writeProfile" />
<!-- Allows an application to read from the user's social stream. -->
<permission android:name="android.permission.READ_SOCIAL_STREAM"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_readSocialStream"
android:description="@string/permdesc_readSocialStream" />
<!-- Allows an application to write (but not read) the user's
social stream data. -->
<permission android:name="android.permission.WRITE_SOCIAL_STREAM"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_writeSocialStream"
android:description="@string/permdesc_writeSocialStream" />
<!-- Allows an application to read the user's calendar data. -->
<permission android:name="android.permission.READ_CALENDAR"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_readCalendar"
android:description="@string/permdesc_readCalendar" />
<!-- Allows an application to write (but not read) the user's
calendar data. -->
<permission android:name="android.permission.WRITE_CALENDAR"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_writeCalendar"
android:description="@string/permdesc_writeCalendar" />
<!-- Allows an application to read the user dictionary. This should
really only be required by an IME, or a dictionary editor like
the Settings app.
@hide Pending API council approval -->
<permission android:name="android.permission.READ_USER_DICTIONARY"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_readDictionary"
android:description="@string/permdesc_readDictionary" />
<!-- Allows an application to write to the user dictionary.
@hide Pending API council approval -->
<permission android:name="android.permission.WRITE_USER_DICTIONARY"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="normal"
android:label="@string/permlab_writeDictionary"
android:description="@string/permdesc_writeDictionary" />
<!-- Allows an application to read (but not write) the user's
browsing history and bookmarks. -->
<permission android:name="com.android.browser.permission.READ_HISTORY_BOOKMARKS"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:label="@string/permlab_readHistoryBookmarks"
android:description="@string/permdesc_readHistoryBookmarks"
android:protectionLevel="dangerous" />
<!-- Allows an application to write (but not read) the user's
browsing history and bookmarks. -->
<permission android:name="com.android.browser.permission.WRITE_HISTORY_BOOKMARKS"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:label="@string/permlab_writeHistoryBookmarks"
android:description="@string/permdesc_writeHistoryBookmarks"
android:protectionLevel="dangerous" />
<!-- Allows an application to broadcast an Intent to set an alarm for the
user. -->
<permission android:name="com.android.alarm.permission.SET_ALARM"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:label="@string/permlab_setAlarm"
android:description="@string/permdesc_setAlarm"
android:protectionLevel="normal" />
<!-- Allows an application to add voicemails into the system. -->
<permission android:name="com.android.voicemail.permission.ADD_VOICEMAIL"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:protectionLevel="dangerous"
android:label="@string/permlab_addVoicemail"
android:description="@string/permdesc_addVoicemail" />
<!-- ======================================= -->
<!-- Permissions for accessing location info -->
<!-- ======================================= -->
<eat-comment />
<!-- Used for permissions that allow access to the user's current
location. -->
<permission-group android:name="android.permission-group.LOCATION"
android:label="@string/permgrouplab_location"
android:description="@string/permgroupdesc_location" />
<!-- Allows an application to access fine (e.g., GPS) location -->
<permission android:name="android.permission.ACCESS_FINE_LOCATION"
android:permissionGroup="android.permission-group.LOCATION"
android:protectionLevel="dangerous"
android:label="@string/permlab_accessFineLocation"
android:description="@string/permdesc_accessFineLocation" />
<!-- Allows an application to access coarse (e.g., Cell-ID, WiFi) location -->
<permission android:name="android.permission.ACCESS_COARSE_LOCATION"
android:permissionGroup="android.permission-group.LOCATION"
android:protectionLevel="dangerous"
android:label="@string/permlab_accessCoarseLocation"
android:description="@string/permdesc_accessCoarseLocation" />
<!-- Allows an application to create mock location providers for testing -->
<permission android:name="android.permission.ACCESS_MOCK_LOCATION"
android:permissionGroup="android.permission-group.LOCATION"
android:protectionLevel="dangerous"
android:label="@string/permlab_accessMockLocation"
android:description="@string/permdesc_accessMockLocation" />
<!-- Allows an application to access extra location provider commands -->
<permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS"
android:permissionGroup="android.permission-group.LOCATION"
android:protectionLevel="normal"
android:label="@string/permlab_accessLocationExtraCommands"
android:description="@string/permdesc_accessLocationExtraCommands" />
<!-- Allows an application to install a location provider into the Location Manager -->
<permission android:name="android.permission.INSTALL_LOCATION_PROVIDER"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_installLocationProvider"
android:description="@string/permdesc_installLocationProvider" />
<!-- ======================================= -->
<!-- Permissions for accessing networks -->
<!-- ======================================= -->
<eat-comment />
<!-- Used for permissions that provide access to networking services. The
main permission here is internet access, but this is also an
appropriate group for accessing or modifying any network configuration
or other related network operations. -->
<permission-group android:name="android.permission-group.NETWORK"
android:label="@string/permgrouplab_network"
android:description="@string/permgroupdesc_network" />
<!-- Allows applications to open network sockets. -->
<permission android:name="android.permission.INTERNET"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="dangerous"
android:description="@string/permdesc_createNetworkSockets"
android:label="@string/permlab_createNetworkSockets" />
<!-- Allows applications to access information about networks -->
<permission android:name="android.permission.ACCESS_NETWORK_STATE"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="normal"
android:description="@string/permdesc_accessNetworkState"
android:label="@string/permlab_accessNetworkState" />
<!-- Allows applications to access information about Wi-Fi networks -->
<permission android:name="android.permission.ACCESS_WIFI_STATE"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="normal"
android:description="@string/permdesc_accessWifiState"
android:label="@string/permlab_accessWifiState" />
<!-- @hide -->
<permission android:name="android.permission.ACCESS_WIMAX_STATE"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="normal"
android:description="@string/permdesc_accessWimaxState"
android:label="@string/permlab_accessWimaxState" />
<!-- Allows applications to connect to paired bluetooth devices -->
<permission android:name="android.permission.BLUETOOTH"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="dangerous"
android:description="@string/permdesc_bluetooth"
android:label="@string/permlab_bluetooth" />
<!-- Allows applications to perform I/O operations over NFC -->
<permission android:name="android.permission.NFC"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="dangerous"
android:description="@string/permdesc_nfc"
android:label="@string/permlab_nfc" />
<!-- Allows an application to use SIP service -->
<permission android:name="android.permission.USE_SIP"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="dangerous"
android:description="@string/permdesc_use_sip"
android:label="@string/permlab_use_sip" />
<!-- Allows applications to call into AccountAuthenticators. Only
the system can get this permission. -->
2009-10-02 17:19:31 -07:00
<permission android:name="android.permission.ACCOUNT_MANAGER"
android:permissionGroup="android.permission-group.ACCOUNTS"
android:protectionLevel="signature"
android:description="@string/permdesc_accountManagerService"
android:label="@string/permlab_accountManagerService" />
<!-- Allows an internal user to use privaledged ConnectivityManager
APIs.
@hide -->
<permission android:name="android.permission.CONNECTIVITY_INTERNAL"
android:permissionGroup="android.permission-group.NETWORK"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- ================================== -->
<!-- Permissions for accessing accounts -->
<!-- ================================== -->
<eat-comment />
<!-- Permissions for direct access to the accounts managed
by the Account Manager. -->
<permission-group android:name="android.permission-group.ACCOUNTS"
android:label="@string/permgrouplab_accounts"
android:description="@string/permgroupdesc_accounts" />
<!-- Allows access to the list of accounts in the Accounts Service -->
<permission android:name="android.permission.GET_ACCOUNTS"
android:permissionGroup="android.permission-group.ACCOUNTS"
android:protectionLevel="normal"
android:description="@string/permdesc_getAccounts"
android:label="@string/permlab_getAccounts" />
<!-- Allows an application to act as an AccountAuthenticator for
the AccountManager -->
<permission android:name="android.permission.AUTHENTICATE_ACCOUNTS"
android:permissionGroup="android.permission-group.ACCOUNTS"
android:protectionLevel="dangerous"
android:label="@string/permlab_authenticateAccounts"
android:description="@string/permdesc_authenticateAccounts" />
<!-- Allows an application to request authtokens from the AccountManager -->
<permission android:name="android.permission.USE_CREDENTIALS"
android:permissionGroup="android.permission-group.ACCOUNTS"
android:protectionLevel="dangerous"
android:label="@string/permlab_useCredentials"
android:description="@string/permdesc_useCredentials" />
<!-- Allows an application to manage the list of accounts in the AccountManager -->
<permission android:name="android.permission.MANAGE_ACCOUNTS"
android:permissionGroup="android.permission-group.ACCOUNTS"
android:protectionLevel="dangerous"
android:label="@string/permlab_manageAccounts"
android:description="@string/permdesc_manageAccounts" />
<!-- ================================== -->
<!-- Permissions for accessing hardware -->
<!-- ================================== -->
<eat-comment />
<!-- Used for permissions that provide direct access to the hardware on
the device. This includes audio, the camera, vibrator, etc. -->
<permission-group android:name="android.permission-group.HARDWARE_CONTROLS"
android:label="@string/permgrouplab_hardwareControls"
android:description="@string/permgroupdesc_hardwareControls" />
<!-- Allows an application to modify global audio settings -->
<permission android:name="android.permission.MODIFY_AUDIO_SETTINGS"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_modifyAudioSettings"
android:description="@string/permdesc_modifyAudioSettings" />
<!-- Allows an application to record audio -->
<permission android:name="android.permission.RECORD_AUDIO"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_recordAudio"
android:description="@string/permdesc_recordAudio" />
<!-- Required to be able to access the camera device.
<p>This will automatically enforce the <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code
&lt;uses-feature&gt;}</a> manifest element for <em>all</em> camera features.
If you do not require all camera features or can properly operate if a camera
is not available, then you must modify your manifest as appropriate in order to
install on devices that don't support all camera features.</p> -->
<permission android:name="android.permission.CAMERA"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_camera"
android:description="@string/permdesc_camera" />
<!-- Allows access to the vibrator -->
<permission android:name="android.permission.VIBRATE"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
android:protectionLevel="normal"
android:label="@string/permlab_vibrate"
android:description="@string/permdesc_vibrate" />
<!-- Allows access to the flashlight -->
<permission android:name="android.permission.FLASHLIGHT"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
android:protectionLevel="normal"
android:label="@string/permlab_flashlight"
android:description="@string/permdesc_flashlight" />
UsbManager: Enhancements for managing USB devices and accessories When a USB device or accessory is connected, the UsbService now asks the user which application to associate with the device or accessory. Applications interested in devices or accessories must specify the devices they work with via meta-data attached to their manifest. Permission to communicate with the device is assigned when the user chooses the activity to use for the device. The user has the option of clicking the "always use this application" checkbox to make the assignment automatic in the future. The user may later clear this preference and revoke permission for an application to have permission to communicate with the device by clicking the "Clear defaults" button for the activity in the Manage Applications panel in Settings. Added class UsbResolveActivity (a subclass or ResolveActivity for choosing an activity for a USB device or accessory) Added UsbDeviceManager, which manages the mapping between USB devices/accessories and applications, including default applications for devices and accessories, and manages application permissions. Add interface to allow Settings to clear device and accessory preferences and permissions for an application. Remove obsolete ACCESS_USB permission. Add new signatureOrSystem MANAGE_USB permission to allow administrating preferences and permissions. Moved UsbService.java to a "usb" subdirectory, along with new classes UsbResolveActivity and UsbDeviceManager. Change-Id: I92554381e9779e68ce380daaee4e1401fb875703 Signed-off-by: Mike Lockwood <lockwood@android.com>
2011-02-27 09:10:37 -08:00
<!-- Allows an application to manage preferences and permissions for USB devices
@hide -->
<permission android:name="android.permission.MANAGE_USB"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
UsbManager: Enhancements for managing USB devices and accessories When a USB device or accessory is connected, the UsbService now asks the user which application to associate with the device or accessory. Applications interested in devices or accessories must specify the devices they work with via meta-data attached to their manifest. Permission to communicate with the device is assigned when the user chooses the activity to use for the device. The user has the option of clicking the "always use this application" checkbox to make the assignment automatic in the future. The user may later clear this preference and revoke permission for an application to have permission to communicate with the device by clicking the "Clear defaults" button for the activity in the Manage Applications panel in Settings. Added class UsbResolveActivity (a subclass or ResolveActivity for choosing an activity for a USB device or accessory) Added UsbDeviceManager, which manages the mapping between USB devices/accessories and applications, including default applications for devices and accessories, and manages application permissions. Add interface to allow Settings to clear device and accessory preferences and permissions for an application. Remove obsolete ACCESS_USB permission. Add new signatureOrSystem MANAGE_USB permission to allow administrating preferences and permissions. Moved UsbService.java to a "usb" subdirectory, along with new classes UsbResolveActivity and UsbDeviceManager. Change-Id: I92554381e9779e68ce380daaee4e1401fb875703 Signed-off-by: Mike Lockwood <lockwood@android.com>
2011-02-27 09:10:37 -08:00
android:label="@string/permlab_manageUsb"
android:description="@string/permdesc_manageUsb" />
<!-- Allows an application to access the MTP USB kernel driver.
For use only by the device side MTP implementation.
@hide -->
<permission android:name="android.permission.ACCESS_MTP"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_accessMtp"
android:description="@string/permdesc_accessMtp" />
<!-- Allows access to hardware peripherals. Intended only for hardware testing -->
<permission android:name="android.permission.HARDWARE_TEST"
android:permissionGroup="android.permission-group.HARDWARE_CONTROLS"
android:protectionLevel="signature"
android:label="@string/permlab_hardware_test"
android:description="@string/permdesc_hardware_test" />
<!-- Allows access to configure network interfaces, configure/use IPSec, etc.
@hide -->
<permission android:name="android.permission.NET_ADMIN"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature" />
<!-- =========================================== -->
<!-- Permissions associated with telephony state -->
<!-- =========================================== -->
<eat-comment />
<!-- Used for permissions that are associated with accessing and modifyign
telephony state: intercepting outgoing calls, reading
and modifying the phone state. Note that
placing phone calls is not in this group, since that is in the
more important "takin' yer moneys" group. -->
<permission-group android:name="android.permission-group.PHONE_CALLS"
android:label="@string/permgrouplab_phoneCalls"
android:description="@string/permgroupdesc_phoneCalls" />
<!-- Allows an application to monitor, modify, or abort outgoing
calls. -->
<permission android:name="android.permission.PROCESS_OUTGOING_CALLS"
android:permissionGroup="android.permission-group.PHONE_CALLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_processOutgoingCalls"
android:description="@string/permdesc_processOutgoingCalls" />
<!-- Allows modification of the telephony state - power on, mmi, etc.
Does not include placing calls. -->
<permission android:name="android.permission.MODIFY_PHONE_STATE"
android:permissionGroup="android.permission-group.PHONE_CALLS"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_modifyPhoneState"
android:description="@string/permdesc_modifyPhoneState" />
<!-- Allows read only access to phone state. -->
<permission android:name="android.permission.READ_PHONE_STATE"
android:permissionGroup="android.permission-group.PHONE_CALLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_readPhoneState"
android:description="@string/permdesc_readPhoneState" />
<!-- Allows read access to privileged phone state.
@hide Used internally. -->
<permission android:name="android.permission.READ_PRIVILEGED_PHONE_STATE"
android:permissionGroup="android.permission-group.PHONE_CALLS"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- ================================== -->
<!-- Permissions for sdcard interaction -->
<!-- ================================== -->
<eat-comment />
<!-- Group of permissions that are related to SD card access. -->
<permission-group android:name="android.permission-group.STORAGE"
android:label="@string/permgrouplab_storage"
android:description="@string/permgroupdesc_storage" />
<!-- Allows an application to read from external storage -->
<permission android:name="android.permission.READ_EXTERNAL_STORAGE"
android:permissionGroup="android.permission-group.STORAGE"
android:label="@string/permlab_sdcardRead"
android:description="@string/permdesc_sdcardRead"
android:protectionLevel="dangerous" />
<!-- Allows an application to write to external storage -->
<permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
android:permissionGroup="android.permission-group.STORAGE"
android:label="@string/permlab_sdcardWrite"
android:description="@string/permdesc_sdcardWrite"
android:protectionLevel="dangerous" />
<!-- Allows an application to write to internal media storage
@hide -->
<permission android:name="android.permission.WRITE_MEDIA_STORAGE"
android:permissionGroup="android.permission-group.STORAGE"
android:label="@string/permlab_mediaStorageWrite"
android:description="@string/permdesc_mediaStorageWrite"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- ============================================ -->
<!-- Permissions for low-level system interaction -->
<!-- ============================================ -->
<eat-comment />
<!-- Group of permissions that are related to system APIs. Many
of these are not permissions the user will be expected to understand,
and such permissions should generally be marked as "normal" protection
level so they don't get displayed. This can also, however, be used
for miscellaneous features that provide access to the operating system,
such as writing the global system settings. -->
<permission-group android:name="android.permission-group.SYSTEM_TOOLS"
android:label="@string/permgrouplab_systemTools"
android:description="@string/permgroupdesc_systemTools" />
<!-- Allows an application to read or write the system settings. -->
<permission android:name="android.permission.WRITE_SETTINGS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_writeSettings"
android:description="@string/permdesc_writeSettings" />
<!-- Allows an application to modify the Google service map. -->
<permission android:name="android.permission.WRITE_GSERVICES"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_writeGservices"
android:description="@string/permdesc_writeGservices" />
<!-- Allows an application to expand or collapse the status bar. -->
<permission android:name="android.permission.EXPAND_STATUS_BAR"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_expandStatusBar"
android:description="@string/permdesc_expandStatusBar" />
<!-- Allows an application to get information about the currently
or recently running tasks: a thumbnail representation of the tasks,
what activities are running in it, etc. -->
<permission android:name="android.permission.GET_TASKS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_getTasks"
android:description="@string/permdesc_getTasks" />
<!-- Allows an application to change the Z-order of tasks -->
<permission android:name="android.permission.REORDER_TASKS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_reorderTasks"
android:description="@string/permdesc_reorderTasks" />
<!-- @hide Allows an application to change to remove/kill tasks -->
<permission android:name="android.permission.REMOVE_TASKS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_removeTasks"
android:description="@string/permdesc_removeTasks" />
<!-- Allows an application to start any activity, regardless of permission
protection or exported state. @hide -->
<permission android:name="android.permission.START_ANY_ACTIVITY"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_startAnyActivity"
android:description="@string/permdesc_startAnyActivity" />
<!-- @hide Change the screen compatibility mode of applications -->
<permission android:name="android.permission.SET_SCREEN_COMPATIBILITY"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_setScreenCompatibility"
android:description="@string/permdesc_setScreenCompatibility" />
<!-- Allows an application to modify the current configuration, such
as locale. -->
<permission android:name="android.permission.CHANGE_CONFIGURATION"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_changeConfiguration"
android:description="@string/permdesc_changeConfiguration" />
<!-- @deprecated The {@link android.app.ActivityManager#restartPackage}
API is no longer supported. -->
<permission android:name="android.permission.RESTART_PACKAGES"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_killBackgroundProcesses"
android:description="@string/permdesc_killBackgroundProcesses" />
<!-- Allows an application to call
{@link android.app.ActivityManager#killBackgroundProcesses}. -->
<permission android:name="android.permission.KILL_BACKGROUND_PROCESSES"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_killBackgroundProcesses"
android:description="@string/permdesc_killBackgroundProcesses" />
<!-- Allows an application to call
{@link android.app.ActivityManager#forceStopPackage}.
@hide -->
<permission android:name="android.permission.FORCE_STOP_PACKAGES"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_forceStopPackages"
android:description="@string/permdesc_forceStopPackages" />
<!-- @hide Allows an application to retrieve the content of the active window
An active window is the window that has fired an accessibility event. -->
<permission android:name="android.permission.RETRIEVE_WINDOW_CONTENT"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_retrieve_window_content"
android:description="@string/permdesc_retrieve_window_content" />
<!-- Allows an application to open windows using the type
{@link android.view.WindowManager.LayoutParams#TYPE_SYSTEM_ALERT},
shown on top of all other applications. Very few applications
should use this permission; these windows are intended for
system-level interaction with the user. -->
<permission android:name="android.permission.SYSTEM_ALERT_WINDOW"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_systemAlertWindow"
android:description="@string/permdesc_systemAlertWindow" />
<!-- Modify the global animation scaling factor. -->
<permission android:name="android.permission.SET_ANIMATION_SCALE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_setAnimationScale"
android:description="@string/permdesc_setAnimationScale" />
<!-- @deprecated This functionality will be removed in the future; please do
not use.
Allow an application to make its activities persistent. -->
<permission android:name="android.permission.PERSISTENT_ACTIVITY"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_persistentActivity"
android:description="@string/permdesc_persistentActivity" />
<!-- Allows an application to find out the space used by any package. -->
<permission android:name="android.permission.GET_PACKAGE_SIZE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_getPackageSize"
android:description="@string/permdesc_getPackageSize" />
<!-- @deprecated No longer useful, see
{@link android.content.pm.PackageManager#addPackageToPreferred}
for details. -->
<permission android:name="android.permission.SET_PREFERRED_APPLICATIONS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_setPreferredApplications"
android:description="@string/permdesc_setPreferredApplications" />
<!-- Allows an application to receive the
{@link android.content.Intent#ACTION_BOOT_COMPLETED} that is
broadcast after the system finishes booting. If you don't
request this permission, you will not receive the broadcast at
that time. Though holding this permission does not have any
security implications, it can have a negative impact on the
user experience by increasing the amount of time it takes the
system to start and allowing applications to have themselves
running without the user being aware of them. As such, you must
explicitly declare your use of this facility to make that visible
to the user. -->
<permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_receiveBootCompleted"
android:description="@string/permdesc_receiveBootCompleted" />
<!-- Allows an application to broadcast sticky intents. These are
broadcasts whose data is held by the system after being finished,
so that clients can quickly retrieve that data without having
to wait for the next broadcast. -->
<permission android:name="android.permission.BROADCAST_STICKY"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_broadcastSticky"
android:description="@string/permdesc_broadcastSticky" />
<!-- Allows using PowerManager WakeLocks to keep processor from sleeping or screen
from dimming -->
<permission android:name="android.permission.WAKE_LOCK"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_wakeLock"
android:description="@string/permdesc_wakeLock" />
<!-- Allows applications to set the wallpaper -->
<permission android:name="android.permission.SET_WALLPAPER"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_setWallpaper"
android:description="@string/permdesc_setWallpaper" />
<!-- Allows applications to set the wallpaper hints -->
<permission android:name="android.permission.SET_WALLPAPER_HINTS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:label="@string/permlab_setWallpaperHints"
android:description="@string/permdesc_setWallpaperHints" />
<!-- Allows applications to set the system time -->
<permission android:name="android.permission.SET_TIME"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_setTime"
android:description="@string/permdesc_setTime" />
<!-- Allows applications to set the system time zone -->
<permission android:name="android.permission.SET_TIME_ZONE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_setTimeZone"
android:description="@string/permdesc_setTimeZone" />
<!-- Allows mounting and unmounting file systems for removable storage. -->
<permission android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_mount_unmount_filesystems"
android:description="@string/permdesc_mount_unmount_filesystems" />
<!-- Allows formatting file systems for removable storage. -->
<permission android:name="android.permission.MOUNT_FORMAT_FILESYSTEMS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_mount_format_filesystems"
android:description="@string/permdesc_mount_format_filesystems" />
<!-- Allows access to ASEC non-destructive API calls
@hide -->
<permission android:name="android.permission.ASEC_ACCESS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_asec_access"
android:description="@string/permdesc_asec_access" />
<!-- Allows creation of ASEC volumes
@hide -->
<permission android:name="android.permission.ASEC_CREATE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_asec_create"
android:description="@string/permdesc_asec_create" />
<!-- Allows destruction of ASEC volumes
@hide -->
<permission android:name="android.permission.ASEC_DESTROY"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_asec_destroy"
android:description="@string/permdesc_asec_destroy" />
<!-- Allows mount / unmount of ASEC volumes
@hide -->
<permission android:name="android.permission.ASEC_MOUNT_UNMOUNT"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_asec_mount_unmount"
android:description="@string/permdesc_asec_mount_unmount" />
<!-- Allows rename of ASEC volumes
@hide -->
<permission android:name="android.permission.ASEC_RENAME"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:label="@string/permlab_asec_rename"
android:description="@string/permdesc_asec_rename" />
<!-- Allows applications to disable the keyguard -->
<permission android:name="android.permission.DISABLE_KEYGUARD"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:description="@string/permdesc_disableKeyguard"
android:label="@string/permlab_disableKeyguard" />
<!-- Allows applications to read the sync settings -->
<permission android:name="android.permission.READ_SYNC_SETTINGS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:description="@string/permdesc_readSyncSettings"
android:label="@string/permlab_readSyncSettings" />
<!-- Allows applications to write the sync settings -->
<permission android:name="android.permission.WRITE_SYNC_SETTINGS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:description="@string/permdesc_writeSyncSettings"
android:label="@string/permlab_writeSyncSettings" />
<!-- Allows applications to read the sync stats -->
<permission android:name="android.permission.READ_SYNC_STATS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="normal"
android:description="@string/permdesc_readSyncStats"
android:label="@string/permlab_readSyncStats" />
<!-- Allows applications to write the apn settings -->
<permission android:name="android.permission.WRITE_APN_SETTINGS"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:description="@string/permdesc_writeApnSettings"
android:label="@string/permlab_writeApnSettings" />
<!-- Allows an application to allow access the subscribed feeds
ContentProvider. -->
<permission android:name="android.permission.SUBSCRIBED_FEEDS_READ"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:label="@string/permlab_subscribedFeedsRead"
android:description="@string/permdesc_subscribedFeedsRead"
android:protectionLevel="normal" />
<permission android:name="android.permission.SUBSCRIBED_FEEDS_WRITE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:label="@string/permlab_subscribedFeedsWrite"
android:description="@string/permdesc_subscribedFeedsWrite"
android:protectionLevel="dangerous" />
<!-- Allows applications to change network connectivity state -->
<permission android:name="android.permission.CHANGE_NETWORK_STATE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:description="@string/permdesc_changeNetworkState"
android:label="@string/permlab_changeNetworkState" />
<!-- Allows applications to change Wi-Fi connectivity state -->
<permission android:name="android.permission.CHANGE_WIFI_STATE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:description="@string/permdesc_changeWifiState"
android:label="@string/permlab_changeWifiState" />
<!-- @hide -->
<permission android:name="android.permission.CHANGE_WIMAX_STATE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:description="@string/permdesc_changeWimaxState"
android:label="@string/permlab_changeWimaxState" />
<!-- Allows applications to enter Wi-Fi Multicast mode -->
<permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:description="@string/permdesc_changeWifiMulticastState"
android:label="@string/permlab_changeWifiMulticastState" />
<!-- Allows applications to discover and pair bluetooth devices -->
<permission android:name="android.permission.BLUETOOTH_ADMIN"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:description="@string/permdesc_bluetoothAdmin"
android:label="@string/permlab_bluetoothAdmin" />
<!-- Allows an application to clear the caches of all installed
applications on the device. -->
<permission android:name="android.permission.CLEAR_APP_CACHE"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="dangerous"
android:label="@string/permlab_clearAppCache"
android:description="@string/permdesc_clearAppCache" />
<!-- Allows an application to use any media decoder when decoding for playback
@hide -->
<permission android:name="android.permission.ALLOW_ANY_CODEC_FOR_PLAYBACK"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system"
android:label="@string/permlab_anyCodecForPlayback"
android:description="@string/permdesc_anyCodecForPlayback" />
<!-- ========================================= -->
<!-- Permissions for special development tools -->
<!-- ========================================= -->
<eat-comment />
<!-- Group of permissions that are related to development features. These
are not permissions that should appear in normal applications; they
protect APIs that are intended only to be used for development
purposes. -->
<permission-group android:name="android.permission-group.DEVELOPMENT_TOOLS"
android:label="@string/permgrouplab_developmentTools"
android:description="@string/permgroupdesc_developmentTools" />
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
<!-- Allows an application to read or write the secure system settings. -->
<permission android:name="android.permission.WRITE_SECURE_SETTINGS"
android:permissionGroup="android.permission-group.DEVELOPMENT_TOOLS"
android:protectionLevel="signature|system|development"
android:label="@string/permlab_writeSecureSettings"
android:description="@string/permdesc_writeSecureSettings" />
<!-- Allows an application to retrieve state dump information from system
services. -->
<permission android:name="android.permission.DUMP"
android:permissionGroup="android.permission-group.DEVELOPMENT_TOOLS"
android:protectionLevel="signature|system|development"
android:label="@string/permlab_dump"
android:description="@string/permdesc_dump" />
<!-- Allows an application to read the low-level system log files.
Log entries can contain the user's private information,
which is why this permission is not available to normal apps. -->
<permission android:name="android.permission.READ_LOGS"
android:permissionGroup="android.permission-group.DEVELOPMENT_TOOLS"
android:protectionLevel="signature|system|development"
android:label="@string/permlab_readLogs"
android:description="@string/permdesc_readLogs" />
<!-- Configure an application for debugging. -->
<permission android:name="android.permission.SET_DEBUG_APP"
android:permissionGroup="android.permission-group.DEVELOPMENT_TOOLS"
android:protectionLevel="signature|system|development"
android:label="@string/permlab_setDebugApp"
android:description="@string/permdesc_setDebugApp" />
<!-- Allows an application to set the maximum number of (not needed)
application processes that can be running. -->
<permission android:name="android.permission.SET_PROCESS_LIMIT"
android:permissionGroup="android.permission-group.DEVELOPMENT_TOOLS"
android:protectionLevel="signature|system|development"
android:label="@string/permlab_setProcessLimit"
android:description="@string/permdesc_setProcessLimit" />
<!-- Allows an application to control whether activities are immediately
finished when put in the background. -->
<permission android:name="android.permission.SET_ALWAYS_FINISH"
android:permissionGroup="android.permission-group.DEVELOPMENT_TOOLS"
android:protectionLevel="signature|system|development"
android:label="@string/permlab_setAlwaysFinish"
android:description="@string/permdesc_setAlwaysFinish" />
<!-- Allow an application to request that a signal be sent to all persistent processes -->
<permission android:name="android.permission.SIGNAL_PERSISTENT_PROCESSES"
android:permissionGroup="android.permission-group.DEVELOPMENT_TOOLS"
android:protectionLevel="signature|system|development"
android:label="@string/permlab_signalPersistentProcesses"
android:description="@string/permdesc_signalPersistentProcesses" />
<!-- ==================================== -->
<!-- Private (signature-only) permissions -->
<!-- ==================================== -->
<eat-comment />
<!-- Allows applications to RW to diagnostic resources. -->
<permission android:name="android.permission.DIAGNOSTIC"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:description="@string/permdesc_diagnostic"
android:label="@string/permlab_diagnostic" />
<!-- Allows an application to open, close, or disable the status bar
and its icons. -->
<permission android:name="android.permission.STATUS_BAR"
android:label="@string/permlab_statusBar"
android:description="@string/permdesc_statusBar"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to be the status bar. Currently used only by SystemUI.apk
@hide -->
<permission android:name="android.permission.STATUS_BAR_SERVICE"
android:label="@string/permlab_statusBarService"
android:description="@string/permdesc_statusBarService"
android:protectionLevel="signature" />
<!-- Allows an application to force a BACK operation on whatever is the
top activity. -->
<permission android:name="android.permission.FORCE_BACK"
android:label="@string/permlab_forceBack"
android:description="@string/permdesc_forceBack"
android:protectionLevel="signature" />
<!-- Allows an application to update device statistics. Not for
use by third party apps. -->
<permission android:name="android.permission.UPDATE_DEVICE_STATS"
android:label="@string/permlab_batteryStats"
android:description="@string/permdesc_batteryStats"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to open windows that are for use by parts
of the system user interface. Not for use by third party apps. -->
<permission android:name="android.permission.INTERNAL_SYSTEM_WINDOW"
android:label="@string/permlab_internalSystemWindow"
android:description="@string/permdesc_internalSystemWindow"
android:protectionLevel="signature" />
<!-- Allows an application to manage (create, destroy,
Z-order) application tokens in the window manager. This is only
for use by the system. -->
<permission android:name="android.permission.MANAGE_APP_TOKENS"
android:label="@string/permlab_manageAppTokens"
android:description="@string/permdesc_manageAppTokens"
android:protectionLevel="signature" />
<!-- Allows an application to inject user events (keys, touch, trackball)
into the event stream and deliver them to ANY window. Without this
permission, you can only deliver events to windows in your own process.
Very few applications should need to use this permission. -->
<permission android:name="android.permission.INJECT_EVENTS"
android:label="@string/permlab_injectEvents"
android:description="@string/permdesc_injectEvents"
android:protectionLevel="signature" />
<!-- Allows an application to watch and control how activities are
started globally in the system. Only for is in debugging
(usually the monkey command). -->
<permission android:name="android.permission.SET_ACTIVITY_WATCHER"
android:label="@string/permlab_runSetActivityWatcher"
android:description="@string/permdesc_runSetActivityWatcher"
android:protectionLevel="signature" />
<!-- Allows an application to call the activity manager shutdown() API
to put the higher-level system there into a shutdown state.
@hide -->
<permission android:name="android.permission.SHUTDOWN"
android:label="@string/permlab_shutdown"
android:description="@string/permdesc_shutdown"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to tell the activity manager to temporarily
stop application switches, putting it into a special mode that
prevents applications from immediately switching away from some
critical UI such as the home screen.
@hide -->
<permission android:name="android.permission.STOP_APP_SWITCHES"
android:label="@string/permlab_stopAppSwitches"
android:description="@string/permdesc_stopAppSwitches"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to retrieve the current state of keys and
switches. This is only for use by the system.
@deprecated The API that used this permission has been removed. -->
<permission android:name="android.permission.READ_INPUT_STATE"
android:label="@string/permlab_readInputState"
android:description="@string/permdesc_readInputState"
android:protectionLevel="signature" />
<!-- Must be required by an {@link android.inputmethodservice.InputMethodService},
to ensure that only the system can bind to it. -->
<permission android:name="android.permission.BIND_INPUT_METHOD"
android:label="@string/permlab_bindInputMethod"
android:description="@string/permdesc_bindInputMethod"
android:protectionLevel="signature" />
<!-- Must be required by a TextService (e.g. SpellCheckerService)
to ensure that only the system can bind to it. -->
<permission android:name="android.permission.BIND_TEXT_SERVICE"
android:label="@string/permlab_bindTextService"
android:description="@string/permdesc_bindTextService"
android:protectionLevel="signature" />
<!-- Must be required by an {@link android.net.VpnService},
to ensure that only the system can bind to it. -->
<permission android:name="android.permission.BIND_VPN_SERVICE"
android:label="@string/permlab_bindVpnService"
android:description="@string/permdesc_bindVpnService"
android:protectionLevel="signature" />
<!-- Must be required by a {@link android.service.wallpaper.WallpaperService},
to ensure that only the system can bind to it. -->
<permission android:name="android.permission.BIND_WALLPAPER"
android:label="@string/permlab_bindWallpaper"
android:description="@string/permdesc_bindWallpaper"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Must be required by device administration receiver, to ensure that only the
system can interact with it. -->
<permission android:name="android.permission.BIND_DEVICE_ADMIN"
android:label="@string/permlab_bindDeviceAdmin"
android:description="@string/permdesc_bindDeviceAdmin"
android:protectionLevel="signature" />
<!-- Allows low-level access to setting the orientation (actually
rotation) of the screen. Not for use by normal applications. -->
<permission android:name="android.permission.SET_ORIENTATION"
android:label="@string/permlab_setOrientation"
android:description="@string/permdesc_setOrientation"
android:protectionLevel="signature" />
<!-- Allows low-level access to setting the pointer speed.
Not for use by normal applications. -->
<permission android:name="android.permission.SET_POINTER_SPEED"
android:label="@string/permlab_setPointerSpeed"
android:description="@string/permdesc_setPointerSpeed"
android:protectionLevel="signature" />
<!-- Allows low-level access to setting the keyboard layout.
Not for use by normal applications. -->
<permission android:name="android.permission.SET_KEYBOARD_LAYOUT"
android:label="@string/permlab_setKeyboardLayout"
android:description="@string/permdesc_setKeyboardLayout"
android:protectionLevel="signature" />
<!-- Allows an application to install packages. -->
<permission android:name="android.permission.INSTALL_PACKAGES"
android:label="@string/permlab_installPackages"
android:description="@string/permdesc_installPackages"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to clear user data -->
<permission android:name="android.permission.CLEAR_APP_USER_DATA"
android:label="@string/permlab_clearAppUserData"
android:description="@string/permdesc_clearAppUserData"
android:protectionLevel="signature" />
<!-- Allows an application to delete cache files. -->
<permission android:name="android.permission.DELETE_CACHE_FILES"
android:label="@string/permlab_deleteCacheFiles"
android:description="@string/permdesc_deleteCacheFiles"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to delete packages. -->
<permission android:name="android.permission.DELETE_PACKAGES"
android:label="@string/permlab_deletePackages"
android:description="@string/permdesc_deletePackages"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to move location of installed package.
@hide -->
<permission android:name="android.permission.MOVE_PACKAGE"
android:label="@string/permlab_movePackage"
android:description="@string/permdesc_movePackage"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to change whether an application component (other than its own) is
enabled or not. -->
<permission android:name="android.permission.CHANGE_COMPONENT_ENABLED_STATE"
android:label="@string/permlab_changeComponentState"
android:description="@string/permdesc_changeComponentState"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- @hide Allows an application to grant or revoke specific permissions. -->
<permission android:name="android.permission.GRANT_REVOKE_PERMISSIONS"
android:label="@string/permlab_grantRevokePermissions"
android:description="@string/permdesc_grantRevokePermissions"
android:protectionLevel="signature" />
<!-- Allows an application to use SurfaceFlinger's low level features -->
<permission android:name="android.permission.ACCESS_SURFACE_FLINGER"
android:label="@string/permlab_accessSurfaceFlinger"
android:description="@string/permdesc_accessSurfaceFlinger"
android:protectionLevel="signature" />
<!-- Allows an application to take screen shots and more generally
get access to the frame buffer data -->
<permission android:name="android.permission.READ_FRAME_BUFFER"
android:label="@string/permlab_readFrameBuffer"
android:description="@string/permdesc_readFrameBuffer"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Required to be able to disable the device (very dangerous!). -->
<permission android:name="android.permission.BRICK"
android:label="@string/permlab_brick"
android:description="@string/permdesc_brick"
android:protectionLevel="signature" />
<!-- Required to be able to reboot the device. -->
<permission android:name="android.permission.REBOOT"
android:label="@string/permlab_reboot"
android:description="@string/permdesc_reboot"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows low-level access to power management -->
<permission android:name="android.permission.DEVICE_POWER"
android:label="@string/permlab_devicePower"
android:description="@string/permdesc_devicePower"
android:protectionLevel="signature" />
<!-- Run as a manufacturer test application, running as the root user.
Only available when the device is running in manufacturer test mode. -->
<permission android:name="android.permission.FACTORY_TEST"
android:label="@string/permlab_factoryTest"
android:description="@string/permdesc_factoryTest"
android:protectionLevel="signature" />
<!-- Allows an application to broadcast a notification that an application
package has been removed. -->
<permission android:name="android.permission.BROADCAST_PACKAGE_REMOVED"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:label="@string/permlab_broadcastPackageRemoved"
android:description="@string/permdesc_broadcastPackageRemoved"
android:protectionLevel="signature" />
<!-- Allows an application to broadcast an SMS receipt notification -->
<permission android:name="android.permission.BROADCAST_SMS"
android:permissionGroup="android.permission-group.MESSAGES"
android:label="@string/permlab_broadcastSmsReceived"
android:description="@string/permdesc_broadcastSmsReceived"
android:protectionLevel="signature" />
<!-- Allows an application to broadcast a WAP PUSH receipt notification -->
<permission android:name="android.permission.BROADCAST_WAP_PUSH"
android:permissionGroup="android.permission-group.MESSAGES"
android:label="@string/permlab_broadcastWapPush"
android:description="@string/permdesc_broadcastWapPush"
android:protectionLevel="signature" />
<permission android:name="android.permission.MASTER_CLEAR"
android:label="@string/permlab_masterClear"
android:description="@string/permdesc_masterClear"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to call any phone number, including emergency
numbers, without going through the Dialer user interface for the user
to confirm the call being placed. -->
<permission android:name="android.permission.CALL_PRIVILEGED"
android:label="@string/permlab_callPrivileged"
android:description="@string/permdesc_callPrivileged"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to perform CDMA OTA provisioning @hide -->
<permission android:name="android.permission.PERFORM_CDMA_PROVISIONING"
android:label="@string/permlab_performCdmaProvisioning"
android:description="@string/permdesc_performCdmaProvisioning"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows enabling/disabling location update notifications from
the radio. Not for use by normal applications. -->
<permission android:name="android.permission.CONTROL_LOCATION_UPDATES"
android:label="@string/permlab_locationUpdates"
android:description="@string/permdesc_locationUpdates"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows read/write access to the "properties" table in the checkin
database, to change values that get uploaded. -->
<permission android:name="android.permission.ACCESS_CHECKIN_PROPERTIES"
android:label="@string/permlab_checkinProperties"
android:description="@string/permdesc_checkinProperties"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to collect component usage
statistics @hide -->
<permission android:name="android.permission.PACKAGE_USAGE_STATS"
android:label="@string/permlab_pkgUsageStats"
android:description="@string/permdesc_pkgUsageStats"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to collect battery statistics -->
<permission android:name="android.permission.BATTERY_STATS"
android:label="@string/permlab_batteryStats"
android:description="@string/permdesc_batteryStats"
android:protectionLevel="normal" />
<!-- Allows an application to control the backup and restore process
@hide pending API council -->
<permission android:name="android.permission.BACKUP"
android:label="@string/permlab_backup"
android:description="@string/permdesc_backup"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
Full local backup infrastructure This is the basic infrastructure for pulling a full(*) backup of the device's data over an adb(**) connection to the local device. The basic process consists of these interacting pieces: 1. The framework's BackupManagerService, which coordinates the collection of app data and routing to the destination. 2. A new framework-provided BackupAgent implementation called FullBackupAgent, which is instantiated in the target applications' processes in turn, and knows how to emit a datastream that contains all of the app's saved data files. 3. A new shell-level program called "bu" that is used to bridge from adb to the framework's Backup Manager. 4. adb itself, which now knows how to use 'bu' to kick off a backup operation and pull the resulting data stream to the desktop host. 5. A system-provided application that verifies with the user that an attempted backup/restore operation is in fact expected and to be allowed. The full agent implementation is not used during normal operation of the delta-based app-customized remote backup process. Instead it's used during user-confirmed *full* backup of applications and all their data to a local destination, e.g. via the adb connection. The output format is 'tar'. This makes it very easy for the end user to examine the resulting dataset, e.g. for purpose of extracting files for debug purposes; as well as making it easy to contemplate adding things like a direct gzip stage to the data pipeline during backup/restore. It also makes it convenient to construct and maintain synthetic backup datasets for testing purposes. Within the tar format, certain artificial conventions are used. All files are stored within top-level directories according to their semantic origin: apps/pkgname/a/ : Application .apk file itself apps/pkgname/obb/: The application's associated .obb containers apps/pkgname/f/ : The subtree rooted at the getFilesDir() location apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent apps/pkgname/r/ : Files stored relative to the root of the app's file tree apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored. For each package, the first entry in the tar stream is a file called "_manifest", nominally rooted at apps/pkgname. This file contains some metadata about the package whose data is stored in the archive. The contents of shared storage can optionally be included in the tar stream. It is placed in the synthetic location: shared/... uid/gid are ignored; app uids are assigned at install time, and the app's data is handled from within its own execution environment, so will automatically have the app's correct uid. Forward-locked .apk files are never backed up. System-partition .apk files are not backed up unless they have been overridden by a post-factory upgrade, in which case the current .apk *is* backed up -- i.e. the .apk that matches the on-disk data. The manifest preceding each application's portion of the tar stream provides version numbers and signature blocks for version checking, as well as an indication of whether the restore logic should expect to install the .apk before extracting the data. System packages can designate their own full backup agents. This is to manage things like the settings provider which (a) cannot be shut down on the fly in order to do a clean snapshot of their file trees, and (b) manage data that is not only irrelevant but actively hostile to non-identical devices -- CDMA telephony settings would seriously mess up a GSM device if emplaced there blind, for example. When a full backup or restore is initiated from adb, the system will present a confirmation UI that the user must explicitly respond to within a short [~ 30 seconds] timeout. This is to avoid the possibility of malicious desktop-side software secretly grabbing a copy of all the user's data for nefarious purposes. (*) The backup is not strictly a full mirror. In particular, the settings database is not cloned; it is handled the same way that it is in cloud backup/restore. This is because some settings are actively destructive if cloned onto a different (or especially a different-model) device: telephony settings and AndroidID are good examples of this. (**) On the framework side it doesn't care that it's adb; it just sends the tar stream to a file descriptor. This can easily be retargeted around whatever transport we might decide to use in the future. KNOWN ISSUES: * the security UI is desperately ugly; no proper designs have yet been done for it * restore is not yet implemented * shared storage backup is not yet implemented * symlinks aren't yet handled, though some infrastructure for dealing with them has been put in place. Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 14:43:32 -07:00
<!-- Allows a package to launch the secure full-backup confirmation UI.
ONLY the system process may hold this permission.
@hide -->
<permission android:name="android.permission.CONFIRM_FULL_BACKUP"
android:label="@string/permlab_confirm_full_backup"
android:description="@string/permdesc_confirm_full_backup"
android:protectionLevel="signature" />
<!-- Must be required by a {@link android.widget.RemoteViewsService},
to ensure that only the system can bind to it. -->
<permission android:name="android.permission.BIND_REMOTEVIEWS"
android:label="@string/permlab_bindRemoteViews"
android:description="@string/permdesc_bindRemoteViews"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to tell the AppWidget service which application
can access AppWidget's data. The normal user flow is that a user
picks an AppWidget to go into a particular host, thereby giving that
host application access to the private data from the AppWidget app.
An application that has this permission should honor that contract.
Very few applications should need to use this permission. -->
<permission android:name="android.permission.BIND_APPWIDGET"
android:permissionGroup="android.permission-group.PERSONAL_INFO"
android:label="@string/permlab_bindGadget"
android:description="@string/permdesc_bindGadget"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows applications to change the background data setting
@hide pending API council -->
<permission android:name="android.permission.CHANGE_BACKGROUND_DATA_SETTING"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
android:description="@string/permdesc_changeBackgroundDataSetting"
android:label="@string/permlab_changeBackgroundDataSetting" />
<!-- This permission can be used on content providers to allow the global
search system to access their data. Typically it used when the
provider has some permissions protecting it (which global search
would not be expected to hold), and added as a read-only permission
to the path in the provider where global search queries are
performed. This permission can not be held by regular applications;
it is used by applications to protect themselves from everyone else
besides global search. -->
<permission android:name="android.permission.GLOBAL_SEARCH"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Internal permission protecting access to the global search
system: ensures that only the system can access the provider
to perform queries (since this otherwise provides unrestricted
access to a variety of content providers), and to write the
search statistics (to keep applications from gaming the source
ranking).
@hide -->
<permission android:name="android.permission.GLOBAL_SEARCH_CONTROL"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature" />
<!-- Allows applications to set a live wallpaper.
@hide XXX Change to signature once the picker is moved to its
own apk as Ghod Intended. -->
<permission android:name="android.permission.SET_WALLPAPER_COMPONENT"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allow an application to read and write the cache partition.
@hide -->
<permission android:name="android.permission.ACCESS_CACHE_FILESYSTEM"
android:label="@string/permlab_cache_filesystem"
android:description="@string/permdesc_cache_filesystem"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Must be required by default container service so that only
the system can bind to it and use it to copy
protected data to secure containers or files
accessible to the system.
@hide -->
<permission android:name="android.permission.COPY_PROTECTED_DATA"
android:label="@string/permlab_copyProtectedData"
android:description="@string/permlab_copyProtectedData"
android:protectionLevel="signature" />
<!-- Internal permission protecting access to the encryption methods
@hide
-->
<permission android:name="android.permission.CRYPT_KEEPER"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to read historical network usage for
specific networks and applications. @hide -->
<permission android:name="android.permission.READ_NETWORK_USAGE_HISTORY"
android:label="@string/permlab_readNetworkUsageHistory"
android:description="@string/permdesc_readNetworkUsageHistory"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Allows an application to manage network policies (such as warning and disable
limits) and to define application-specific rules. @hide -->
<permission android:name="android.permission.MANAGE_NETWORK_POLICY"
android:label="@string/permlab_manageNetworkPolicy"
android:description="@string/permdesc_manageNetworkPolicy"
android:protectionLevel="signature" />
<!-- Allows an application to account its network traffic against other UIDs. Used
by system services like download manager and media server. Not for use by
third party apps. @hide -->
<permission android:name="android.permission.MODIFY_NETWORK_ACCOUNTING"
android:label="@string/permlab_modifyNetworkAccounting"
android:description="@string/permdesc_modifyNetworkAccounting"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- C2DM permission.
@hide Used internally.
-->
<permission android:name="android.intent.category.MASTER_CLEAR.permission.C2D_MESSAGE"
android:protectionLevel="signature" />
<uses-permission android:name="android.intent.category.MASTER_CLEAR.permission.C2D_MESSAGE"/>
<!-- Package verifier needs to have this permission before the PackageManager will
trust it to verify packages.
@hide
-->
<permission android:name="android.permission.PACKAGE_VERIFICATION_AGENT"
android:label="@string/permlab_packageVerificationAgent"
android:description="@string/permdesc_packageVerificationAgent"
New development permissions. These are permissions that an application can request, but won't normally be granted. To have the permission granted, the user must explicitly do so through a new "adb shell pm grant" command. I put these permissions in the "development tools" permission group. Looking at the stuff there, I think all of the permissions we already had in that group should be turned to development permissions; I don't think any of them are protecting public APIs, and they are really not things normal applications should use. The support this, the protectionLevel of a permission has been modified to consist of a base protection type with additional flags. The signatureOrSystem permission has thus been converted to a signature base type with a new "system" flag; you can use "system" and/or "dangerous" flags with signature permissions as desired. The permissions UI has been updated to understand these new types of permissions and know when to display them. Along with doing that, it also now shows you which permissions are new when updating an existing application. This also starts laying the ground-work for "optional" permissions (which development permissions are a certain specialized form of). Completing that work requires some more features in the package manager to understand generic optional permissions (having a facility to not apply them when installing), along with the appropriate UI for the app and user to manage those permissions. Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
2012-02-21 15:11:13 -08:00
android:protectionLevel="signature|system" />
<!-- Must be required by package verifier receiver, to ensure that only the
system can interact with it.
@hide
-->
<permission android:name="android.permission.BIND_PACKAGE_VERIFIER"
android:label="@string/permlab_bindPackageVerifier"
android:description="@string/permdesc_bindPackageVerifier"
android:protectionLevel="signature" />
<!-- Allows applications to access serial ports via the SerialManager.
@hide -->
<permission android:name="android.permission.SERIAL_PORT"
android:label="@string/permlab_serialPort"
android:description="@string/permdesc_serialPort"
android:protectionLevel="normal" />
<!-- Allows the holder to access content providers from outside an ApplicationThread.
This permission is enforced by the ActivityManagerService on the corresponding APIs,
in particular ActivityManagerService#getContentProviderExternal(String) and
ActivityManagerService#removeContentProviderExternal(String).
@hide
-->
<permission android:name="android.permission.ACCESS_CONTENT_PROVIDERS_EXTERNALLY"
android:label="@string/permlab_accessContentProvidersExternally"
android:description="@string/permdesc_accessContentProvidersExternally"
android:protectionLevel="signature" />
<!-- Allows an application to hold an UpdateLock, recommending that a headless
OTA reboot *not* occur while the lock is held.
@hide -->
<permission android:name="android.permission.UPDATE_LOCK"
android:label="@string/permlab_updateLock"
android:description="@string/permdesc_updateLock"
android:protectionLevel="signatureOrSystem" />
Full local backup infrastructure This is the basic infrastructure for pulling a full(*) backup of the device's data over an adb(**) connection to the local device. The basic process consists of these interacting pieces: 1. The framework's BackupManagerService, which coordinates the collection of app data and routing to the destination. 2. A new framework-provided BackupAgent implementation called FullBackupAgent, which is instantiated in the target applications' processes in turn, and knows how to emit a datastream that contains all of the app's saved data files. 3. A new shell-level program called "bu" that is used to bridge from adb to the framework's Backup Manager. 4. adb itself, which now knows how to use 'bu' to kick off a backup operation and pull the resulting data stream to the desktop host. 5. A system-provided application that verifies with the user that an attempted backup/restore operation is in fact expected and to be allowed. The full agent implementation is not used during normal operation of the delta-based app-customized remote backup process. Instead it's used during user-confirmed *full* backup of applications and all their data to a local destination, e.g. via the adb connection. The output format is 'tar'. This makes it very easy for the end user to examine the resulting dataset, e.g. for purpose of extracting files for debug purposes; as well as making it easy to contemplate adding things like a direct gzip stage to the data pipeline during backup/restore. It also makes it convenient to construct and maintain synthetic backup datasets for testing purposes. Within the tar format, certain artificial conventions are used. All files are stored within top-level directories according to their semantic origin: apps/pkgname/a/ : Application .apk file itself apps/pkgname/obb/: The application's associated .obb containers apps/pkgname/f/ : The subtree rooted at the getFilesDir() location apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent apps/pkgname/r/ : Files stored relative to the root of the app's file tree apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored. For each package, the first entry in the tar stream is a file called "_manifest", nominally rooted at apps/pkgname. This file contains some metadata about the package whose data is stored in the archive. The contents of shared storage can optionally be included in the tar stream. It is placed in the synthetic location: shared/... uid/gid are ignored; app uids are assigned at install time, and the app's data is handled from within its own execution environment, so will automatically have the app's correct uid. Forward-locked .apk files are never backed up. System-partition .apk files are not backed up unless they have been overridden by a post-factory upgrade, in which case the current .apk *is* backed up -- i.e. the .apk that matches the on-disk data. The manifest preceding each application's portion of the tar stream provides version numbers and signature blocks for version checking, as well as an indication of whether the restore logic should expect to install the .apk before extracting the data. System packages can designate their own full backup agents. This is to manage things like the settings provider which (a) cannot be shut down on the fly in order to do a clean snapshot of their file trees, and (b) manage data that is not only irrelevant but actively hostile to non-identical devices -- CDMA telephony settings would seriously mess up a GSM device if emplaced there blind, for example. When a full backup or restore is initiated from adb, the system will present a confirmation UI that the user must explicitly respond to within a short [~ 30 seconds] timeout. This is to avoid the possibility of malicious desktop-side software secretly grabbing a copy of all the user's data for nefarious purposes. (*) The backup is not strictly a full mirror. In particular, the settings database is not cloned; it is handled the same way that it is in cloud backup/restore. This is because some settings are actively destructive if cloned onto a different (or especially a different-model) device: telephony settings and AndroidID are good examples of this. (**) On the framework side it doesn't care that it's adb; it just sends the tar stream to a file descriptor. This can easily be retargeted around whatever transport we might decide to use in the future. KNOWN ISSUES: * the security UI is desperately ugly; no proper designs have yet been done for it * restore is not yet implemented * shared storage backup is not yet implemented * symlinks aren't yet handled, though some infrastructure for dealing with them has been put in place. Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 14:43:32 -07:00
<!-- The system process is explicitly the only one allowed to launch the
confirmation UI for full backup/restore -->
<uses-permission android:name="android.permission.CONFIRM_FULL_BACKUP"/>
<application android:process="system"
android:persistent="true"
android:hasCode="false"
android:label="@string/android_system_label"
android:allowClearUserData="false"
android:backupAgent="com.android.server.SystemBackupAgent"
android:killAfterRestore="false"
android:icon="@drawable/ic_launcher_android">
<activity android:name="com.android.internal.app.ChooserActivity"
android:theme="@style/Theme.Holo.Dialog.Alert"
android:finishOnCloseSystemDialogs="true"
android:excludeFromRecents="true"
android:multiprocess="true">
<intent-filter>
<action android:name="android.intent.action.CHOOSER" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
<activity android:name="com.android.internal.app.HeavyWeightSwitcherActivity"
android:theme="@style/Theme.Holo.Dialog"
android:label="@string/heavy_weight_switcher_title"
android:finishOnCloseSystemDialogs="true"
android:excludeFromRecents="true"
android:process=":ui">
</activity>
<activity android:name="com.android.internal.app.PlatLogoActivity"
android:theme="@style/Theme.Wallpaper.NoTitleBar.Fullscreen"
android:process=":ui">
</activity>
<activity android:name="com.android.internal.app.DisableCarModeActivity"
android:theme="@style/Theme.NoDisplay"
android:excludeFromRecents="true"
android:process=":ui">
</activity>
<activity android:name="com.android.internal.app.RingtonePickerActivity"
android:theme="@style/Theme.Holo.Dialog.Alert"
android:excludeFromRecents="true"
android:multiprocess="true"
android:process=":ui">
<intent-filter>
<action android:name="android.intent.action.RINGTONE_PICKER" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
2009-04-20 16:05:10 -07:00
<activity android:name="android.accounts.ChooseAccountActivity"
android:excludeFromRecents="true"
android:exported="true"
android:theme="@android:style/Theme.Holo.Dialog"
android:label="@string/choose_account_label"
android:process=":ui">
2009-04-20 16:05:10 -07:00
</activity>
<activity android:name="android.accounts.ChooseTypeAndAccountActivity"
android:excludeFromRecents="true"
android:exported="true"
android:theme="@android:style/Theme.Holo.DialogWhenLarge.NoActionBar"
android:label="@string/choose_account_label"
android:process=":ui">
</activity>
<activity android:name="android.accounts.ChooseAccountTypeActivity"
android:excludeFromRecents="true"
android:theme="@android:style/Theme.Holo.DialogWhenLarge.NoActionBar"
android:label="@string/choose_account_label"
android:process=":ui">
</activity>
<activity android:name="android.accounts.GrantCredentialsPermissionActivity"
android:excludeFromRecents="true"
android:exported="true"
android:theme="@android:style/Theme.Holo.DialogWhenLarge"
android:process=":ui">
</activity>
<activity android:name="android.content.SyncActivityTooManyDeletes"
android:theme="@android:style/Theme.Holo.Dialog"
android:label="@string/sync_too_many_deletes"
android:process=":ui">
</activity>
<activity android:name="com.android.server.ShutdownActivity"
android:permission="android.permission.SHUTDOWN"
android:excludeFromRecents="true">
<intent-filter>
<action android:name="android.intent.action.ACTION_REQUEST_SHUTDOWN" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.REBOOT" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
UsbManager: Enhancements for managing USB devices and accessories When a USB device or accessory is connected, the UsbService now asks the user which application to associate with the device or accessory. Applications interested in devices or accessories must specify the devices they work with via meta-data attached to their manifest. Permission to communicate with the device is assigned when the user chooses the activity to use for the device. The user has the option of clicking the "always use this application" checkbox to make the assignment automatic in the future. The user may later clear this preference and revoke permission for an application to have permission to communicate with the device by clicking the "Clear defaults" button for the activity in the Manage Applications panel in Settings. Added class UsbResolveActivity (a subclass or ResolveActivity for choosing an activity for a USB device or accessory) Added UsbDeviceManager, which manages the mapping between USB devices/accessories and applications, including default applications for devices and accessories, and manages application permissions. Add interface to allow Settings to clear device and accessory preferences and permissions for an application. Remove obsolete ACCESS_USB permission. Add new signatureOrSystem MANAGE_USB permission to allow administrating preferences and permissions. Moved UsbService.java to a "usb" subdirectory, along with new classes UsbResolveActivity and UsbDeviceManager. Change-Id: I92554381e9779e68ce380daaee4e1401fb875703 Signed-off-by: Mike Lockwood <lockwood@android.com>
2011-02-27 09:10:37 -08:00
<activity android:name="com.android.internal.app.NetInitiatedActivity"
android:theme="@style/Theme.Holo.Dialog.Alert"
android:excludeFromRecents="true"
android:process=":ui">
</activity>
<receiver android:name="com.android.server.BootReceiver" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
<receiver android:name="com.android.server.MasterClearReceiver"
android:permission="android.permission.MASTER_CLEAR"
android:priority="100" >
<intent-filter>
<!-- For Checkin, Settings, etc.: action=MASTER_CLEAR -->
<action android:name="android.intent.action.MASTER_CLEAR" />
<!-- MCS always uses REMOTE_INTENT: category=MASTER_CLEAR -->
<action android:name="com.google.android.c2dm.intent.RECEIVE" />
<category android:name="android.intent.category.MASTER_CLEAR" />
</intent-filter>
</receiver>
<service android:name="com.android.internal.os.storage.ExternalStorageFormatter"
android:permission="android.permission.MASTER_CLEAR"
android:exported="true" />
</application>
</manifest>