A content provider declared with the combined read and write permission will be accessible to the entities that request either read or write access to the provider. However, in many cases, just like in the case of files on a file system, entities that need read access to the data stored by the provider should not be allowed to modify the data. Setting the permission attribute does not allow to distinguish between data users and interactions that affect the data's integrity.

Example 1: The following is an example of a content provider declared with the combined read and write access permission.

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

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 excerpt from the AndroidManifest.xml file specifies a receiver with an intent filter for intents with the android.intent.action.PHONE_STATE action.

        <receiver android:name=".ReceiverTest" android:permission="test.permission" android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.PHONE_STATE" />
            </intent-filter>
        </receiver>

Receiving this intent requires the android.permission.READ_PHONE_STATE permission. If this permission is not requested by the application in the manifest file, the application will fail to receive the intent.

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.

Any application can access public components that are not explicitly assigned an access permission in their manifest definition.

The default value of the exported attribute for the activity, receiver, and service components in an Android application depends on the presence or absence of an intent-filter. Presence of an intent-filter implies, the component is intended for external use, thus setting the exported attribute to true. This component is now accessible to any other applications on the Android platform.

Example 1: The following is an example of an Android activity with an intent-filter and no explicit access permission set.

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

This activity can be exploited by malicious applications.

Receiver registered without the broadcaster permission will receive messages from any broadcaster. If these messages contain malicious data or come from a malicious broadcaster, the application may be compromised.

Example 1: The following code registers a receiver without specifying the broadcaster permission.

...
context.registerReceiver(broadcastReceiver, intentFilter);
...