Skip to content

MASTG-KNOW-0017: Permissões de Aplicativo

O Android atribui uma identidade de sistema distinta (ID de usuário Linux e ID de grupo) a cada aplicativo instalado. Como cada aplicativo Android opera em um sandbox de processo, os aplicativos devem solicitar explicitamente acesso a recursos e dados que estão fora de seu sandbox. Eles solicitam esse acesso declarando as permissões necessárias para usar dados e recursos do sistema. Dependendo do quão sensíveis ou críticos são os dados ou recursos, o sistema Android concederá a permissão automaticamente ou solicitará que o usuário aprove a solicitação.

Para melhorar a privacidade do usuário e mitigar riscos de privacidade, é crucial que os aplicativos Android minimizem as solicitações de permissão e solicitem acesso a informações sensíveis apenas quando estritamente necessário. A documentação para desenvolvedores Android oferece insights valiosos e melhores práticas para ajudar os aplicativos a alcançar o mesmo nível de funcionalidade sem exigir acesso direto a recursos sensíveis:

As permissões do Android podem ser classificadas em categorias distintas dependendo da extensão do acesso a dados restritos e ações permitidas que concedem a um aplicativo. Esta classificação inclui o chamado "Nível de Proteção" conforme mostrado na página de referência da API de permissões e Definições de Código-Fonte do AndroidManifest.xml.

  • Permissões no momento da instalação: concedem acesso limitado a dados restritos ou permitem que o aplicativo execute ações restritas que afetam minimamente o sistema ou outros aplicativos. Elas são concedidas automaticamente no momento da instalação (Android 6.0 (API nível 23) ou superior).
    • Nível de Proteção: normal. Concede aos aplicativos acesso a funcionalidades isoladas em nível de aplicativo com risco mínimo para outros aplicativos, o usuário e o sistema. Exemplo: android.permission.INTERNET
    • Nível de Proteção: signature. Concedida apenas a aplicativos assinados com o mesmo certificado usado para assinar o aplicativo declarante. Exemplo: android.permission.ACCESS_MOCK_LOCATION
    • Nível de Proteção: signatureOrSystem. Reservada para aplicativos incorporados ao sistema ou aqueles assinados com o mesmo certificado usado para assinar o aplicativo declarante. Exemplo: android.permission.ACCESS_DOWNLOAD_MANAGER. Sinônimo antigo para signature|privileged. Preterida no API nível 23.
  • Permissões de tempo de execução: exigem que o usuário seja solicitado explicitamente no tempo de execução para aprovação.
    • Nível de Proteção: dangerous. Concedem acesso adicional a dados restritos ou permitem que o aplicativo execute ações restritas que afetam mais substancialmente o sistema e outros aplicativos.
  • Permissões especiais: exigem que o usuário navegue até Configurações > Aplicativos > Acesso especial do aplicativo e dê consentimento explícito.
    • Nível de Proteção: appop. Concedem acesso a recursos do sistema que são particularmente sensíveis, como exibir e desenhar sobre outros aplicativos ou acessar todos os dados de armazenamento.
  • Permissões personalizadas para compartilhar seus próprios recursos e capacidades com outros aplicativos.
    • Nível de Proteção: normal, signature ou dangerous.

Independentemente do Nível de Proteção atribuído, é importante considerar o risco que uma permissão pode representar considerando as capacidades protegidas adicionais, isso é especialmente importante para aplicativos pré-instalados. A tabela a seguir apresenta um conjunto representativo de permissões Android categorizadas por risco associado, conforme definido neste artigo que utiliza o conjunto de permissões (privilegiadas) e pontos de entrada para um aplicativo para estimar sua superfície de ataque.

Categoria de Risco Permissões Nível de Proteção
ASTRONÔMICO android.permission.INSTALL_PACKAGES signature
CRÍTICO android.permission.COPY_PROTECTED_DATA signature
CRÍTICO android.permission.WRITE_SECURE_SETTINGS signature
CRÍTICO android.permission.READ_FRAME_BUFFER signature
CRÍTICO android.permission.MANAGE_CA_CERTIFICATES signature
CRÍTICO android.permission.MANAGE_APP_OPS_MODES signature
CRÍTICO android.permission.GRANT_RUNTIME_PERMISSIONS signature
CRÍTICO android.permission.DUMP signature
CRÍTICO android.permission.CAMERA dangerous
CRÍTICO android.permission.SYSTEM_CAMERA signatureOrSystem
CRÍTICO android.permission.MANAGE_PROFILE_AND_DEVICE_OWNERS signature
CRÍTICO android.permission.MOUNT_UNMOUNT_FILESYSTEMS signature
CRÍTICO android.permission.PROVIDE_DEFAULT_ENABLED_CREDENTIAL_SERVICE signature
CRÍTICO android.permission.PROVIDE_REMOTE_CREDENTIALS signature
CRÍTICO android.permission.THREAD_NETWORK_PRIVILEGED signature
CRÍTICO android.permission.RECORD_SENSITIVE_CONTENT signature
CRÍTICO android.permission.RECEIVE_SENSITIVE_NOTIFICATIONS signature
ALTO android.permission.INSTALL_GRANT_RUNTIME_PERMISSIONS signature
ALTO android.permission.READ_SMS dangerous
ALTO android.permission.WRITE_SMS normal
ALTO android.permission.RECEIVE_MMS dangerous
ALTO android.permission.SEND_SMS_NO_CONFIRMATION signature
ALTO android.permission.RECEIVE_SMS dangerous
ALTO android.permission.READ_LOGS signature
ALTO android.permission.READ_PRIVILEGED_PHONE_STATE signature
ALTO android.permission.LOCATION_HARDWARE signature
ALTO android.permission.ACCESS_FINE_LOCATION dangerous
ALTO android.permission.ACCESS_BACKGROUND_LOCATION dangerous
ALTO android.permission.BIND_ACCESSIBILITY_SERVICE signature
ALTO android.permission.ACCESS_WIFI_STATE normal
ALTO com.android.voicemail.permission.READ_VOICEMAIL signature
ALTO android.permission.RECORD_AUDIO dangerous
ALTO android.permission.CAPTURE_AUDIO_OUTPUT signature
ALTO android.permission.ACCESS_NOTIFICATIONS signature
ALTO android.permission.INTERACT_ACROSS_USERS_FULL signature
ALTO android.permission.BLUETOOTH_PRIVILEGED signature
ALTO android.permission.GET_PASSWORD signature
ALTO android.permission.INTERNAL_SYSTEM_WINDOW signature
ALTO android.permission.MANAGE_ONGOING_CALLS signature
ALTO android.permission.READ_RESTRICTED_STATS internal
ALTO android.permission.BIND_AUTOFILL_SERVICE signature
ALTO android.permission.WRITE_VERIFICATION_STATE_E2EE_CONTACT_KEYS signature
ALTO android.permission.READ_DROPBOX_DATA signature
ALTO android.permission.WRITE_FLAGS signature
MÉDIO android.permission.ACCESS_COARSE_LOCATION dangerous
MÉDIO android.permission.CHANGE_COMPONENT_ENABLED_STATE signature
MÉDIO android.permission.READ_CONTACTS dangerous
MÉDIO android.permission.WRITE_CONTACTS dangerous
MÉDIO android.permission.CONNECTIVITY_INTERNAL signature
MÉDIO android.permission.ACCESS_MEDIA_LOCATION dangerous
MÉDIO android.permission.READ_EXTERNAL_STORAGE dangerous
MÉDIO android.permission.WRITE_EXTERNAL_STORAGE dangerous
MÉDIO android.permission.SYSTEM_ALERT_WINDOW signature
MÉDIO android.permission.READ_CALL_LOG dangerous
MÉDIO android.permission.WRITE_CALL_LOG dangerous
MÉDIO android.permission.INTERACT_ACROSS_USERS signature
MÉDIO android.permission.MANAGE_USERS signature
MÉDIO android.permission.READ_CALENDAR dangerous
MÉDIO android.permission.BLUETOOTH_ADMIN normal
MÉDIO android.permission.BODY_SENSORS dangerous
MÉDIO android.permission.MANAGE_EXTERNAL_STORAGE signature
MÉDIO android.permission.ACCESS_BLOBS_ACROSS_USERS signature
MÉDIO android.permission.BLUETOOTH_ADVERTISE dangerous
MÉDIO android.permission.READ_MEDIA_AUDIO dangerous
MÉDIO android.permission.READ_MEDIA_IMAGES dangerous
MÉDIO android.permission.READ_MEDIA_VIDEO dangerous
MÉDIO android.permission.REGISTER_NSD_OFFLOAD_ENGINE signature
MÉDIO android.permission.ACCESS_LAST_KNOWN_CELL_ID signature
MÉDIO android.permission.USE_COMPANION_TRANSPORTS signature
BAIXO android.permission.DOWNLOAD_WITHOUT_NOTIFICATION normal
BAIXO android.permission.PACKAGE_USAGE_STATS signature
BAIXO android.permission.MASTER_CLEAR signature
BAIXO android.permission.DELETE_PACKAGES normal
BAIXO android.permission.GET_PACKAGE_SIZE normal
BAIXO android.permission.BLUETOOTH normal
BAIXO android.permission.DEVICE_POWER signature
BAIXO android.permission.READ_PRECISE_PHONE_STATE signature
BAIXO android.permission.LOG_FOREGROUND_RESOURCE_USE signature
BAIXO android.permission.MANAGE_DEFAULT_APPLICATIONS signature
BAIXO android.permission.MANAGE_FACE signature
BAIXO android.permission.REPORT_USAGE_STATS signature
BAIXO android.permission.MANAGE_DISPLAYS signature
BAIXO android.permission.RESTRICT_DISPLAY_MODES signature
BAIXO android.permission.ACCESS_HIDDEN_PROFILES_FULL signature
BAIXO android.permission.GET_BACKGROUND_INSTALLED_PACKAGES signature
NENHUM android.permission.ACCESS_NETWORK_STATE normal
NENHUM android.permission.RECEIVE_BOOT_COMPLETED normal
NENHUM android.permission.WAKE_LOCK normal
NENHUM android.permission.FLASHLIGHT normal
NENHUM android.permission.VIBRATE normal
NENHUM android.permission.WRITE_MEDIA_STORAGE signature
NENHUM android.permission.MODIFY_AUDIO_SETTINGS normal

Observe que esta categorização pode mudar ao longo do tempo. O artigo nos dá um exemplo disso:

Antes do Android 10, a permissão READ_PHONE_STATE seria classificada como ALTA, devido aos identificadores permanentes do dispositivo (ex.: IMEI/MEID, IMSI, SIM e número de série de fabricação) que protege. No entanto, a partir do Android 10, grande parte das informações sensíveis que podem ser usadas para rastreamento foi movida, refatorada ou reescopada para uma nova permissão chamada READ_PRIVILEGED_PHONE_STATE, colocando a nova permissão na categoria ALTA, mas resultando na movimentação da permissão READ_PHONE_STATE para BAIXA.

Mudanças de Permissões por Nível de API

Mudanças no Android 8.0 (API nível 26):

As seguintes mudanças afetam todos os aplicativos executados no Android 8.0 (API nível 26), mesmo aqueles direcionados a níveis de API mais baixos.

  • Mudança nas estatísticas de uso do provedor de contatos: quando um aplicativo solicita a permissão READ_CONTACTS, consultas para dados de uso de contatos retornarão aproximações em vez de valores exatos (a API de preenchimento automático não é afetada por esta mudança).

Aplicativos direcionados ao Android 8.0 (API nível 26) ou superior são afetados pelo seguinte:

  • Melhorias no acesso e descoberta de contas: aplicativos não podem mais obter acesso a contas de usuário apenas por ter a permissão GET_ACCOUNTS concedida, a menos que o autenticador possua as contas ou o usuário conceda esse acesso.
  • Novas permissões de telefonia: as seguintes permissões (classificadas como perigosas) agora fazem parte do grupo de permissões PHONE:
    • A permissão ANSWER_PHONE_CALLS permite atender chamadas telefônicas recebidas programaticamente (via acceptRingingCall).
    • A permissão READ_PHONE_NUMBERS concede acesso de leitura aos números de telefone armazenados no dispositivo.

  • Restrições ao conceder permissões perigosas: permissões perigosas são classificadas em grupos de permissões (ex.: o grupo STORAGE contém READ_EXTERNAL_STORAGE e WRITE_EXTERNAL_STORAGE). Antes do Android 8.0 (API nível 26), era suficiente solicitar uma permissão do grupo para obter todas as permissões desse grupo também concedidas ao mesmo tempo. Isso mudou a partir do Android 8.0 (API nível 26): sempre que um aplicativo solicita uma permissão em tempo de execução, o sistema concederá exclusivamente essa permissão específica. No entanto, observe que todas as solicitações subsequentes de permissões nesse grupo de permissões serão concedidas automaticamente sem mostrar a caixa de diálogo de permissões ao usuário. Veja este exemplo da documentação para desenvolvedores Android:

    Suponha que um aplicativo liste tanto READ_EXTERNAL_STORAGE quanto WRITE_EXTERNAL_STORAGE em seu manifesto. O aplicativo solicita READ_EXTERNAL_STORAGE e o usuário concede. Se o aplicativo for direcionado ao nível de API 25 ou inferior, o sistema também concede WRITE_EXTERNAL_STORAGE ao mesmo tempo, porque pertence ao mesmo grupo de permissões STORAGE e também está registrado no manifesto. Se o aplicativo for direcionado ao Android 8.0 (API nível 26), o sistema concede apenas READ_EXTERNAL_STORAGE naquele momento; no entanto, se o aplicativo posteriormente solicitar WRITE_EXTERNAL_STORAGE, o sistema concede imediatamente esse privilégio sem solicitar o usuário.

    Você pode ver a lista de grupos de permissões na documentação para desenvolvedores Android. Para tornar isso um pouco mais confuso, o Google também alerta que permissões específicas podem ser movidas de um grupo para outro em versões futuras do Android SDK e, portanto, a lógica do aplicativo não deve depender da estrutura desses grupos de permissões. A melhor prática é solicitar explicitamente todas as permissões sempre que necessário.

Mudanças no Android 9 (API Nível 28):

As seguintes mudanças afetam todos os aplicativos executados no Android 9, mesmo aqueles direcionados a níveis de API inferiores a 28.

  • Acesso restrito aos registros de chamadas: as permissões READ_CALL_LOG, WRITE_CALL_LOG e PROCESS_OUTGOING_CALLS (perigosas) foram movidas de PHONE para o novo grupo de permissões CALL_LOG. Isso significa que ser capaz de fazer chamadas telefônicas (ex.: por ter as permissões do grupo PHONE concedidas) não é suficiente para obter acesso aos registros de chamadas.
  • Acesso restrito a números de telefone: aplicativos que desejam ler o número de telefone exigem a permissão READ_CALL_LOG quando executados no Android 9 (API nível 28).
  • Acesso restrito a informações de localização e conexão Wi-Fi: valores SSID e BSSID não podem ser recuperados (ex.: via WifiManager.getConnectionInfo a menos que todas as seguintes condições sejam verdadeiras:
    • A permissão ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION.
    • A permissão ACCESS_WIFI_STATE.
    • Os serviços de localização estejam habilitados (em Configurações -> Localização).

Aplicativos direcionados ao Android 9 (API nível 28) ou superior são afetados pelo seguinte:

  • Preterição do número de série de fabricação: o número de série de hardware do dispositivo não pode ser lido (ex.: via Build.getSerial) a menos que a permissão READ_PHONE_STATE (perigosa) seja concedida.

Mudanças no Android 10 (API nível 29):

O Android 10 (API nível 29) introduz várias melhorias de privacidade do usuário. As mudanças relacionadas a permissões afetam todos os aplicativos executados no Android 10 (API nível 29), incluindo aqueles direcionados a níveis de API mais baixos.

  • Acesso restrito à localização: nova opção de permissão para acesso à localização "apenas enquanto usa o aplicativo".
  • Armazenamento com escopo por padrão: aplicativos direcionados ao Android 10 (API nível 29) não precisam declarar nenhuma permissão de armazenamento para acessar seus arquivos no diretório específico do aplicativo no armazenamento externo, bem como para arquivos criados a partir da galeria de mídia.
  • Acesso restrito ao conteúdo da tela: as permissões READ_FRAME_BUFFER, CAPTURE_VIDEO_OUTPUT e CAPTURE_SECURE_VIDEO_OUTPUT agora são apenas de acesso por assinatura, o que impede o acesso silencioso ao conteúdo da tela do dispositivo.
  • Verificação de permissão voltada ao usuário em aplicativos legados: ao executar um aplicativo direcionado ao Android 5.1 (API nível 22) ou inferior pela primeira vez, os usuários serão solicitados com uma tela de permissões onde podem revogar o acesso a permissões legadas específicas (que anteriormente seriam concedidas automaticamente no momento da instalação).

Aplicação de Permissões

Aplicação de Permissões em Atividades:

As permissões são aplicadas via atributo android:permission dentro da tag <activity> no manifesto. Essas permissões restringem quais aplicativos podem iniciar essa Atividade. A permissão é verificada durante Context.startActivity e Activity.startActivityForResult. Não possuir a permissão necessária resulta em uma SecurityException sendo lançada da chamada.

Aplicação de Permissões em Serviços:

Permissões aplicadas via atributo android:permission dentro da tag <service> no manifesto restringem quem pode iniciar ou vincular ao Serviço associado. A permissão é verificada durante Context.startService, Context.stopService e Context.bindService. Não possuir a permissão necessária resulta em uma SecurityException sendo lançada da chamada.

Aplicação de Permissões em Transmissões:

Permissões aplicadas via atributo android:permission dentro da tag <receiver> restringem o acesso para enviar transmissões para o BroadcastReceiver associado. As permissões mantidas são verificadas após Context.sendBroadcast retornar, enquanto tenta entregar a transmissão enviada ao receptor fornecido. Não possuir as permissões necessárias não lança uma exceção, o resultado é uma transmissão não enviada.

Uma permissão pode ser fornecida para Context.registerReceiver para controlar quem pode transmitir para um receptor registrado programaticamente. Indo no sentido contrário, uma permissão pode ser fornecida ao chamar Context.sendBroadcast para restringir quais receptores de transmissão têm permissão para receber a transmissão.

Observe que tanto um receptor quanto um transmissor podem exigir uma permissão. Quando isso acontece, ambas as verificações de permissão devem passar para que a intent seja entregue ao alvo associado. Para mais informações, consulte a seção "Restringindo transmissões com permissões" na Documentação para Desenvolvedores Android.

Aplicação de Permissões em Provedores de Conteúdo:

Permissões aplicadas via atributo android:permission dentro da tag <provider> restringem o acesso a dados em um ContentProvider. Provedores de conteúdo têm um recurso de segurança adicional importante chamado permissões URI, que é descrito a seguir. Ao contrário dos outros componentes, ContentProviders têm dois atributos de permissão separados que podem ser definidos, android:readPermission restringe quem pode ler do provedor, e android:writePermission restringe quem pode escrever nele. Se um ContentProvider estiver protegido com permissões de leitura e escrita, ter apenas a permissão de escrita não concede também permissões de leitura.

As permissões são verificadas quando você recupera um provedor pela primeira vez e conforme as operações são realizadas usando o ContentProvider. Usar ContentResolver.query requer ter a permissão de leitura; usar ContentResolver.insert, ContentResolver.update, ContentResolver.delete requer a permissão de escrita. Uma SecurityException será lançada da chamada se as permissões adequadas não forem mantidas em todos esses casos.

Permissões URI de Provedores de Conteúdo:

O sistema de permissão padrão não é suficiente quando usado com provedores de conteúdo. Por exemplo, um provedor de conteúdo pode querer limitar permissões a permissões de LEITURA para se proteger, enquanto usa URIs personalizados para recuperar informações. Um aplicativo deve ter apenas a permissão para esse URI específico.

A solução são permissões por URI. Ao iniciar ou retornar um resultado de uma atividade, o método pode definir Intent.FLAG_GRANT_READ_URI_PERMISSION e/ou Intent.FLAG_GRANT_WRITE_URI_PERMISSION. Isso concede permissão à atividade para o URI específico, independentemente de ter permissões para acessar dados do provedor de conteúdo.

Isso permite um modelo comum de capacidade onde a interação do usuário direciona a concessão ad-hoc de permissão granular. Isso pode ser uma instalação chave para reduzir as permissões necessárias pelos aplicativos apenas àquelas diretamente relacionadas ao seu comportamento. Sem este modelo em vigor, usuários maliciosos podem acessar anexos de e-mail de outros membros ou coletar listas de contatos para uso futuro via URIs desprotegidos. No manifesto, o atributo android:grantUriPermissions ou o nó ajudam a restringir os URIs.

Aqui você pode encontrar mais informações sobre APIs relacionadas a Permissões URI:

Permissões Personalizadas

O Android permite que aplicativos exponham seus serviços/componentes para outros aplicativos. Permissões personalizadas são necessárias para acesso do aplicativo aos componentes expostos. Você pode definir permissões personalizadas em AndroidManifest.xml criando uma tag de permissão com dois atributos obrigatórios: android:name e android:protectionLevel.

É crucial criar permissões personalizadas que adiram ao Princípio do Privilégio Mínimo: a permissão deve ser definida explicitamente para sua finalidade, com um rótulo e descrição significativos e precisos.

Abaixo está um exemplo de uma permissão personalizada chamada START_MAIN_ACTIVITY, que é necessária ao lançar a Atividade TEST_ACTIVITY.

O primeiro bloco de código define a nova permissão, que é autoexplicativa. A tag label é um resumo da permissão, e a description é uma versão mais detalhada do resumo. Você pode definir o nível de proteção de acordo com os tipos de permissões que serão concedidas. Depois de definir