Las difusiones enviadas sin el permiso del destinatario están accesibles para todos los usuarios. Si estas difusiones contienen datos confidenciales o son interceptadas por un destinatario malintencionado, podría ponerse en peligro la aplicación.

Ejemplo 1: el siguiente código envía una difusión sin especificar el permiso del destinatario.

...
context.sendBroadcast(intent);
...

Las difusiones del sistema se pueden enviar a componentes privados. Los componentes deben ser públicos para recibir transmisiones de terceros que no pertenecen al sistema. Al registrarse para recibir transmisiones del sistema y fuera del sistema en un solo componente, parte de la funcionalidad del componente (la parte del sistema) queda innecesariamente expuesta a terceros.

Al declarar un permiso personalizado, hay cuatro opciones para especificar el nivel de protección del permiso: normal, dangerous, signature, y signature or system. Los permisos Normal se otorgan a cualquier aplicación que los solicite. Los permisos Dangerous se otorgan solo después de la confirmación del usuario. Los permisos Signature se otorgan solo a las aplicaciones firmadas por la misma clave de desarrollador que el paquete que define el permiso. Los permisos Signature or system son similares a permisos signature, pero también se otorgan a paquetes en la imagen del sistema Android.

Ejemplo 1: A continuación aparece un ejemplo de permiso personalizado declarado con el nivel de protección normal.

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

Un proveedor de contenido declarado con atributo permission de lectura y escritura combinadas estará accesible para las entidades que soliciten acceso de lectura o escritura al proveedor. Sin embargo, en muchos casos, al igual que en el caso de los archivos en un sistema de archivos, las entidades que necesitan acceso de lectura a los datos almacenados por el proveedor no deberían poder modificar los datos. Establecer el atributo permission no permite distinguir entre usuarios de datos e interacciones que afectan la integridad de los datos.

Ejemplo 1: A continuación aparece un ejemplo de proveedor de contenido declarado con el permission (permiso) de acceso combinado de lectura y escritura.

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

Las difusiones persistentes no se pueden proteger con un permiso, por lo que están accesibles para cualquier destinatario. Si estas difusiones contienen datos confidenciales o son interceptadas por un destinatario malintencionado, podría ponerse en peligro la aplicación.

Ejemplo 1: el programa envía una difusión persistente.

...
context.sendStickyBroadcast(intent);
...

La definición de nuevos permisos en el espacio de nombres android.permission puede tener consecuencias inesperadas cuando se actualiza el sistema operativo. Si la versión más reciente del sistema operativo define exactamente el mismo permiso, el Servicio de administración de paquetes de Android (PMS) otorgará silenciosamente el permiso a la aplicación sin pedirle al usuario que permita los ataques de elevación de privilegios.

Como solo espera recibir mensajes de difusión del sistema y no de otros componentes, este componente debe ser privado (inaccesible para otros componentes).