O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Permissões de tempo de execução

No Android 6.0 e superior, o modelo de permissões do aplicativo Android é projetado para tornar as permissões mais compreensíveis, úteis e seguras para os usuários. O modelo transferido aplicativos Android que requerem permissões perigosas (ver permissões afetados ) de um modelo de instalação em tempo permissão para um modelo de permissão de tempo de execução:

  • Permissões de tempo de instalação

    (Android 5.1 e inferior) Usuários conceder permissões perigosas para um aplicativo ao instalar ou atualizar o aplicativo. Os fabricantes e operadoras de dispositivos podem pré-instalar aplicativos com permissões pré-concedidas sem notificar o usuário.

  • Permissões de tempo de execução

    (Android 6,0-9) Usuários conceder permissões perigosas para um aplicativo quando o aplicativo está sendo executado. Quando as permissões são solicitadas (como quando o aplicativo é iniciado ou quando o usuário acessa um recurso específico) depende do aplicativo, mas o usuário concede / nega o acesso do aplicativo a grupos de permissão específicos. OEMs / operadoras podem pré-instalar aplicativos, mas não podem pré-conceder permissões, a menos que passem pelo processo de exceção. (Veja Criando exceções .)

    (Android 10) Usuários ver o aumento da transparência e ter controle sobre quais aplicativos têm reconhecimento de atividade (AR) permissões de tempo de execução. Os usuários são solicitados pelas permissões de tempo de execução de diálogo , quer sempre permitir, permitir que durante o uso, ou negar permissões. Em uma atualização do sistema operacional para o Android 10, permissões dadas aos aplicativos são retidos, mas os usuários podem entrar em Configurações e alterá-las.

As permissões de tempo de execução evitam que os aplicativos tenham acesso a dados privados sem o consentimento do usuário e fornecem contexto e visibilidade adicionais sobre os tipos de permissões que os aplicativos estão buscando ou foram concedidos. O modelo de tempo de execução incentiva os desenvolvedores a ajudar os usuários a entender por que os aplicativos exigem as permissões solicitadas e fornece maior transparência para que os usuários possam tomar melhores decisões sobre como concedê-las ou negá-las.

Permissões afetadas

O Android 6.0 e superior requer permissões perigosas para usar um modelo de permissões de tempo de execução. Permissões perigosas são permissões de alto risco (como READ_CALENDAR ) que concedem solicitando acesso aplicações aos dados do usuário particulares, ou controle sobre um dispositivo, o que pode impactar negativamente o usuário. Para ver uma lista de permissões perigosas, execute o comando:

adb shell pm list permissions -g -d

Android 6.0 e superior não muda o comportamento de permissões normais . Todas essas são permissões não perigosas, incluindo permissões normais, do sistema e de assinatura. Permissões normais são permissões de menor risco (como SET_WALLPAPER ) que concedem solicitando acesso aplicações a nível de aplicação isolada apresenta com um risco mínimo para outras aplicações, o sistema ou o usuário. Como no Android 5.1 e versões anteriores, o sistema concede automaticamente permissões normais a um aplicativo solicitante na instalação e não solicita a aprovação do usuário. Para mais detalhes sobre permissões, consulte o <permission> elemento documentação.

Restrições rígidas e suaves no Android 10

Além de ser perigosa, uma permissão pode ser restrita por hardware ou por software. Em ambos os casos, a permissão restrita também deve estar na lista de permissões. As restrições rígidas não incluídas na lista de permissões se comportam de maneira diferente das restrições flexíveis não incluídas na lista de permissões:

  • (Restrições de disco rígido) Apps não pode ser concedido permissões que não estão na lista de autorizações.
  • (Restrições suave) Apps sem whitelisting se comportam de acordo com a permissão específico, é solicitada. O comportamento é descrito na documentação pública para a permissão solicitada.

Ao instalar um aplicativo, o instalador (como Google Play Store) pode optar por não colocar na lista de permissões as permissões restritas para o aplicativo. As permissões são restritas pela plataforma e podem ser concedidas apenas se um aplicativo atender a critérios especiais por política de plataforma. Exemplos de tipos de permissão de restrição rígida incluem permissões de SMS e Registro de chamadas.

A lista de permissões acontece durante a instalação e quando

  • um aplicativo já está instalado durante uma atualização do Android 9 para 10.
  • uma permissão é pré-concedida ou um aplicativo está pré-instalado.
  • uma permissão é necessária para uma função que já está definida para colocar a permissão na lista de permissões.
  • o instalador (como Google Play Store) marca a permissão como lista branca.

Os usuários não podem colocar permissões na lista de permissões manualmente.

Requisitos

O modelo de permissão de tempo de execução se aplica a todos os aplicativos, incluindo aplicativos pré-instalados e aplicativos entregues ao dispositivo como parte do processo de configuração. Os requisitos de software de aplicativo incluem:

  • O modelo de permissão de tempo de execução deve ser consistente em todos os dispositivos que executam o Android 6.0 e superior. Isso é aplicado pelos testes do Android Compatibility Test Suite (CTS).
  • Os aplicativos devem solicitar que os usuários concedam permissões de aplicativos no tempo de execução. Para mais detalhes, consulte atualização de aplicativos . Exceções limitadas podem ser concedidas a aplicativos e manipuladores padrão que fornecem funcionalidade básica do dispositivo, fundamental para a operação esperada do dispositivo. (Por exemplo, o padrão Dialer aplicativo do dispositivo para lidar com ACTION_CALL podem ter acesso permissão de telefone.) Para mais informações, consulte Criando exceções .
  • Os aplicativos pré-carregados que têm permissões perigosas devem ter como alvo o nível 23 da API e manter o modelo de permissão de tempo de execução. Ou seja, o fluxo da IU durante a instalação do aplicativo não deve se desviar da implementação AOSP de PermissionController, os usuários podem revogar permissões perigosas de aplicativos pré-instalados e assim por diante.
  • Os aplicativos sem periféricos devem usar uma atividade para solicitar permissões ou compartilhar um UID com outro aplicativo que tenha as permissões necessárias. Para mais detalhes, consulte aplicações sem cabeça .

Migração de permissões

As permissões concedidas a aplicativos no Android 5.x permanecem concedidas após a atualização para o Android 6.0 ou superior, mas os usuários podem revogar essas permissões a qualquer momento.

Em uma atualização do Android 9 para 10, todas as permissões restritas são colocadas na lista de permissões. Para mais detalhes sobre a implementação das permissões divididas em primeiro plano / fundo, consulte Android 10 mudanças de privacidade , começando com localização Pedido de fundo .

Integração

Ao integrar o modelo de permissões de tempo de execução do aplicativo para Android 6.0 e superior, você deve atualizar os aplicativos pré-instalados para funcionar com o novo modelo. Você também pode definir exceções para aplicativos que são os manipuladores padrão / prestadores para a funcionalidade do núcleo, definir permissões personalizadas, e personalizar o tema usado no PermissionController aplicativo.

Atualizando aplicativos

Os aplicativos na imagem do sistema e os aplicativos pré-instalados não têm permissões pré-concedidas automaticamente. Nós encorajamos você a trabalhar com desenvolvedores de aplicativos pré-instalados (OEM, portador e terceiros) para fazer as modificações de aplicativos necessários usando diretrizes para desenvolvedores . Especificamente, você deve garantir que os aplicativos pré-instalados sejam modificados para evitar travamentos e outros problemas quando os usuários revogam permissões.

Aplicativos pré-carregados

No Android 9 e inferior, os aplicativos pré-carregados que usam permissões perigosas devem ter como alvo a API de nível 23 ou superior e manter o modelo de permissão AOSP do Android 6.0 e superior. Por exemplo, o fluxo de UI durante uma instalação aplicativo não deve desviar-se da implementação AOSP de PermissionController . Os usuários podem até revogar as permissões perigosas de aplicativos pré-instalados.

No Android 6.0 a 9, algumas permissões são concedidas durante o fluxo de instalação. No entanto, a partir de 10, o fluxo de instalar (realizado pelo Package Installer APP) é uma função separada de permissões concessão (na Permission Controller app).

Aplicativos sem cabeça

Apenas atividades podem solicitar permissões. Os serviços não podem solicitar permissões diretamente.

  • No Android 5.1 e anterior, os aplicativos headless podem solicitar permissões quando instalados ou se foram pré-instalados sem o uso de uma atividade.
  • No Android 6.0 e superior, os aplicativos sem cabeça devem usar um dos seguintes métodos para solicitar permissões:
    • Adicione uma atividade para solicitar permissões. (Este é o método preferido.)
    • Compartilhe um UID com outro aplicativo que tenha as permissões necessárias. Use este método apenas quando precisar que a plataforma lide com vários APKs como um único aplicativo.

O objetivo é evitar confundir os usuários com solicitações de permissão que aparecem fora do contexto.

Personalização da IU PackageInstaller

Se desejar, você pode personalizar o tema Permissão UI, atualizando os temas padrão do dispositivo ( Theme.DeviceDefault.Settings e Theme.DeviceDefault.Light.Dialog.NoActionBar ) utilizados pelos PackageInstaller. No entanto, como a consistência é crítica para desenvolvedores de aplicativos, você não pode personalizar o posicionamento, a posição e as regras de quando a IU de permissões aparece.

Para incluir cadeias para idiomas adicionais, contribuem as cordas para AOSP.

Criação de exceções

Você pode pré-concessão de permissões para aplicativos que são manipuladores padrão ou prestadores de funcionalidade OS núcleo usando o DefaultPermissionGrantPolicy.java classe em PackageManager. Exemplos:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Definição de permissões personalizadas

Você pode definir permissões personalizadas e grupos como normal ou perigoso e adicionar permissões específicas Carrier-OEM / para grupos de permissões existentes, assim como você poderia, em 5.x Android e versões anteriores.

No Android 6.0 e posterior, se você adicionar uma nova permissão perigosa, ela deve ser tratada da mesma forma que outras permissões perigosas (solicitadas durante o tempo de execução do aplicativo e revogáveis ​​pelos usuários). Especificamente:

  • Você pode adicionar novas permissões a um grupo atual, mas não pode modificar o mapeamento AOSP de permissões perigosas e grupos de permissões perigosas. (Em outras palavras, você não pode remover uma permissão de um grupo e atribuir a outro grupo).
  • Você pode adicionar novos grupos de permissões em aplicativos instalados no dispositivo, mas não pode adicionar novos grupos de permissões no manifesto da plataforma.

Permissões de teste

O Android inclui testes de Compatibility Test Suite (CTS) que verificam se as permissões individuais são mapeadas para os grupos corretos. Passar nesses testes é um requisito para compatibilidade com o Android 6.0 e CTS posterior.