This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to the camera can pose a danger to user privacy and personal safety. Applications that require camera access must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the CAMERA permission, which enables an application to access the device's camera.

 <uses-permission android:name="android.permission.CAMERA"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to contacts information can pose a danger to user privacy and personal safety. Applications must treat contacts data as sensitive and manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CONTACTS permission, which enables an application to read the user's contacts data.

 <uses-permission android:name="android.permission.READ_CONTACTS"/> 

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CONTACTS permission, which enables an application to write to the user's contacts data.

 <uses-permission android:name="android.permission.WRITE_CONTACTS"/> 

Example 3: The <uses-permission .../> element of AndroidManifest.xml declares usage of the GET_ACCOUNTS permission, which enables an application to access the user's email and online accounts stored in the Account Manager. Sensitive data such as account IDs, email addresses, and phone numbers can be accessed with this permission.

 <uses-permission android:name="android.permission.GET_ACCOUNTS"/> 

Files written to external storage are readable and writeable by arbitrary programs and users. Programs must never write sensitive information, for instance personally identifiable information, to external storage. When you connect the Android device via USB to a PC or other device it enables USB mass storage mode. Any file written to external storage can be read and modified in this mode. In addition, files in external storage will remain there even after the application that wrote them is uninstalled, further increasing the risk that any sensitive information stored in them will be compromised.

Example 1:The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_EXTERNAL_STORAGE permission, which enables an application to write to external storage.

 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 

Example 2:The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_EXTERNAL_STORAGE permission, which enables and application to read from external storage.

 <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> 

There is no good reason to request or grant a permission that disables the device.

Example 1: A program must not call this permission. Ever.

 <uses-permission android:name="android.permission.BRICK"/> 

Access to GPS location information can compromise a user's privacy and personal safety. Programs that access GPS location information must be careful to manage it with the utmost caution.

Example 1: The following code requests to receive updates to the changes of the location of the phone.

lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000, 0, locationListener);

SMS operations must not be performed without cause or consideration. Malicious software exploits these APIs to steal money and data from unwary users.

Example 1: In this case, the program sends a text based SMS.

sms.sendTextMessage(recipient, null, message, PendingIntent.getBroadcast(SmsMessaging.this, 0, new Intent(ACTION_SMS_SENT), 0), null);

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to the device microphone can pose a danger to user privacy and personal safety. Applications that require access to the microphone must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the RECORD_AUDIO permission, which enables an application to record audio using the device's microphone.

 <uses-permission android:name="android.permission.RECORD_AUDIO"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, Bluetooth access to nearby devices poses a danger to user privacy and personal safety as malicious actors can use Bluetooth functionality to monitor the device location or exploit vulnerabilities to eavesdrop and collect data. Applications that require Bluetooth access to nearby devices must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the BLUETOOTH_ADVERTISE permission, which enables an application to advertise to nearby Bluetooth devices.

 <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to notifications can pose a danger to user privacy and personal safety if sensitive information is included in sent notifications. Applications that require access to send notifications must manage it with the utmost caution and take precautions to prevent sensitive data leakage in notification messages.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the POST_NOTIFICATIONS permission, which enables an application to send notifications to the device user.

 <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to audio files can pose a danger to user privacy and personal safety. Applications that require access to audio files must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_MEDIA_AUDIO permission, which enables an application to read music and audio files on the device.

 <uses-permission android:name="android.permission.READ_MEDIA_AUDIO"/> 

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to photo and video files can pose a danger to user privacy and personal safety. Applications that require access to photos and videos must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_MEDIA_VIDEO permission, which enables an application to read video files on the device.

 <uses-permission android:name="android.permission.READ_MEDIA_VIDEO"/> 

Audio recording operations must not be performed without cause or consideration. Malicious software exploits these APIs to steal money and data from unwary users.

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to body sensors can pose a danger to user privacy and personal safety. Applications that require access to body sensors must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the BODY_SENSORS permission, which enables an application to access data from body or environmental sensors on the device or connected wearables.

 <uses-permission android:name="android.permission.BODY_SENSORS"/> 

Operations related to making and receiving telephone calls must not be performed without cause or consideration. Malicious software exploits these APIs to call premium-pay numbers, thereby stealing money from unwary users.

Example 1: The following code requests the complete voicemail number.

number = tm.getCompleteVoiceMailNumber(); 

Some permissions on Intents are there to be able to grant permissions to external programs that do not usually have that permission, such as FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION. If a malicious program is able to intercept this intent, it will then gain permission to read from or write to the specified URI. These can often be more susceptible to being intercepted if the intent is implicit rather than explicit.

Example 1: The following code sets the permission flag to enable writing to a URI within the Intent.

  myIntent.setFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code sends a text based SMS.

sms.sendTextMessage(recipient, null, message, PendingIntent.getBroadcast(SmsMessaging.this, 0, new Intent(ACTION_SMS_SENT), 0), null);

This API requires the android.permission.SEND_SMS permission. If this permission is not requested by the application in the manifest file, the application will fail to send an SMS.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code reads contacts information stored on the device.

Cursor cursor = getContentResolver().query(ContactsContract.Contacts.CONTENT_URI, null, null, null, null);

Reading data from this content provider requires the android.permission.READ_CONTACTS permission. If this permission is not requested by the application in the manifest file, the application will fail to read contacts information.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code sends an intent with the android.provider.Telephony.SMS_RECEIVED action.

    Intent i = new Intent("android.provider.Telephony.SMS_RECEIVED");
    context.sendBroadcast(i);

Sending this intent requires the android.permission.BROADCAST_SMS permission. If this permission is not requested by the application in the manifest file, the application will fail to send the intent.

Secure coding principles advocate making access specifiers as restrictive as possible. A method with a public access specifier means that any external code is allowed to call it. Public methods that perform privileged actions can be dangerous when code is shared in libraries or in environments where code can dynamically enter the system (e.g. Code Injection, Dangerous File Inclusion, File Upload, etc).

Example 1: In the following code, doPrivilegedOpenFile() is declared public and performs a privileged operation.

public static void doPrivilegedOpenFile(final String filePath) {
  final BadFileNamePrivilegedAction pa = new BadFileNamePrivilegedAction(filePath);

  FileInputStream fis = null;
  ...
  fis = (FileInputStream)AccessController.doPrivileged(pa);
  ...
}

Some functions may enable a programmer to specify an explicit value for whether permission was allowed. This can then be abused to violate what the user wants and still assume the permission was given.

Example 1: The following code asks permission to use the user's location on Android while using WebView, yet uses the user's location whether or not permission to do so is granted. This is achieved by manually invoking the callback with true to specify that permission was given:

public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions$Callback callback){
  super.onGeolocationPermissionsShowPrompt(origin, callback);
  callback.invoke(origin, true, false);
}