Transmissões enviadas sem a permissão do receptor ficam acessíveis a qualquer receptor. Se essas transmissões contiverem dados confidenciais ou acessarem um receptor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir envia uma transmissão sem especificar a permissão do receptor.

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

As transmissões do sistema podem ser enviadas para componentes privados. Os componentes precisam ser públicos para receber transmissões que não são do sistema de terceiros. Ao se registrar para receber tanto transmissões do sistema quanto transmissões que não são do sistema em um único componente, parte da funcionalidade do componente (a parte do sistema) é desnecessariamente exposta a terceiros.

Ao declarar uma permissão personalizada, existem quatro opções para especificar o nível de proteção da permissão: normal, dangerous, signature e signature or system. Normal as permissões são concedidas a qualquer aplicativo que as solicite. Dangerous as permissões são concedidas somente após a confirmação do usuário. Signature as permissões são concedidas apenas a aplicativos assinados pela mesma chave de desenvolvedor do pacote que define a permissão. Signature or system permissões são semelhantes às permissões signature, mas também são concedidas a pacotes na imagem do sistema Android.

Exemplo 1: Veja a seguir um exemplo de uma permissão personalizada declarada com o nível de proteção normal.

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

Um provedor de conteúdo declarado com a permission combinada de leitura e gravação estará acessível para as entidades que solicitam acesso de leitura ou gravação ao provedor. No entanto, em muitos casos, assim como no caso de arquivos em um sistema de arquivos, as entidades que precisam de acesso de leitura aos dados armazenados pelo provedor não devem ter permissão para modificar os dados. Configurar o atributo permission não permite distinguir entre usuários de dados e interações que afetam a integridade dos dados.

Exemplo 1: Veja a seguir um exemplo de um provedor de conteúdo declarado com o atributo permission de acesso combinado de leitura e gravação.

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

Transmissões persistentes não podem ser protegidas com uma permissão e, portanto, são acessíveis a qualquer receptor. Se essas transmissões contiverem dados confidenciais ou acessarem um receptor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir envia uma transmissão persistente.

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

Definir novas permissões no namespace android.permission pode ter consequências inesperadas quando o sistema operacional é atualizado. Se a versão mais recente do sistema operacional definir exatamente a mesma permissão, o Android Package Management Service (PMS) concederá silenciosamente a permissão ao aplicativo, sem pedir ao usuário que permita ataques de escalonamento de privilégios.

Como este componente espera receber apenas mensagens de transmissão do sistema e não de outros componentes, ele deve ser privado (inacessível para outros componentes)