Permissões de execução

No Android 6.0 e versões mais recentes, o modelo de permissões de aplicativos Android foi projetado para tornar as permissões mais compreensíveis, úteis e seguras para os usuários. O modelo moveu o Android aplicativos que exigem permissões perigosas (consulte permissões afetadas) de um install-time para um modelo de tempo de execução:

• Permissões no momento da instalação

  (Android 5.1 e versões anteriores) Os usuários concedem permissões perigosas a um app ao instalar ou atualizar o app. Dispositivo fabricantes e operadoras podem pré-instalar apps com permissões concedidas previamente sem notificar os usuário.

• Permissões de tempo de execução

  (Android 6.0 a 9) Os usuários concedem permissões perigosas a um app quando ele está em execução. Quando permissões são solicitadas (como quando o aplicativo é iniciado ou quando o usuário acessa um determinado depende do aplicativo, mas o usuário concede/nega acesso a aplicativos grupos de permissões. OEMs/operadoras podem pré-instalar apps, mas não podem conceder permissões, a menos que pelo processo de exceção. Consulte Como criar exceções.

  (Android 10) Os usuários têm mais transparência e controlar quais apps têm permissões de execução de reconhecimento de atividade (RA). Os usuários são solicitados o caixa de diálogo de permissões de execução para sempre permitir, permitir durante o uso ou negar permissões. No upgrade do SO para o Android 10, as permissões concedidas a apps são mantidas, mas os usuários podem acessar as Configurações e alterá-las.

As permissões de execução impedem que os apps tenham acesso a dados particulares sem o consentimento do usuário. e dará a eles mais contexto e visibilidade sobre os tipos de permissões que que os apps estão buscando ou que receberam. O modelo de ambiente de execução incentiva os desenvolvedores ajuda os usuários a entender por que os apps exigem as permissões solicitadas e oferece maior transparência para que os usuários possam tomar decisões melhores sobre a concessão ou a negação delas.

Permissões afetadas

O Android 6.0 e versões mais recentes exigem permissões perigosas para usar um modelo de permissões de execução. Permissões perigosas são permissões de alto risco (como READ_CALENDAR) que concedem solicitar que os apps acessem dados particulares dos usuários ou controle sobre um dispositivo, o que pode prejudicar impactar o usuário. Para ver uma lista de permissões perigosas, execute o comando:

adb shell pm list permissions -g -d

O Android 6.0 e versões mais recentes não alteram o comportamento normal do Google Cloud. Todas são permissões não perigosas, incluindo permissões normais, permissões de sistema e assinatura. Permissões normais são de baixo risco (como SET_WALLPAPER) que concedem aos apps solicitante acesso a aplicativos isolados no nível recursos com risco mínimo para outros apps, o sistema ou o usuário. Assim como no Android 5.1 e versões anteriores, o sistema concede automaticamente as permissões normais a um aplicativo solicitante em e não solicita a aprovação do usuário. Para mais detalhes sobre as permissões, consulte a <permission> element.

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

Além de ser perigosa, uma permissão pode ser restringida de forma rígida ou restrito de maneira flexível. Em ambos os casos, a permissão restrita também precisa estar na lista de permissões. Não está na lista de permissões as restrições rígidas se comportam de maneira diferente das restrições flexíveis não permitidas restrições:

• (Restrições rígidas) Os apps não podem receber permissões que não sejam na lista de permissões.
• (Restrições simples) Os apps sem lista de permissões se comportam de acordo com o a permissão específica solicitada. O comportamento é descrito publicamente documentação da permissão solicitada.

Ao instalar um app, o instalador (como a Google Play Store) pode selecionar para não colocar as permissões restritas do app na lista de permissões. As permissões são restritos pela plataforma e só podem ser concedidos se um app atender a critérios especiais de acordo com a política da plataforma. Exemplos de tipos de permissão com restrição rígida incluem SMS e permissões de registro de chamadas.

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

• já está instalado durante um upgrade do Android 9 para 10.
• Quando uma permissão é concedida ou um app é pré-instalado.
• uma permissão é necessária para um papel já definido para colocar o permissão.
• o instalador (como a Google Play Store) marca a permissão como na lista de permissões.

Os usuários não podem adicionar permissões manualmente.

Requisitos

O modelo de permissão de execução se aplica a todos os apps, inclusive os pré-instalados e os pré-instalados enviadas ao dispositivo como parte do processo de configuração. Os requisitos de software do app incluem:

• O modelo de permissão de execução precisa ser consistente em todos os dispositivos com o Android 6.0. e superiores. Isso é aplicado pelos testes do Conjunto de teste de compatibilidade (CTS) do Android.
• Os apps precisam pedir que os usuários concedam permissões no momento da execução. Para mais detalhes, consulte Atualizar apps. É possível conceder exceções limitadas a apps e gerenciadores padrão que oferecem a funcionalidade básica do dispositivo, que é fundamental para o funcionamento esperado dele. Por exemplo, o app Telefone padrão do dispositivo para lidar com ACTION_CALL pode ter Acesso à permissão do smartphone. Para detalhes, consulte Como criar exceções.
• Apps pré-carregados que têm permissões perigosas precisa ter o nível desejado da API 23 e manter o modelo de permissão de execução. Ou seja, o fluxo da interface durante a instalação do app não deve se desviar da implementação do AOSP PermissionController, os usuários podem revogar permissões perigosas de aplicativos pré-instalados e, assim,
• Os apps headless precisam usar uma atividade para solicitar permissões ou compartilhar uma UID com outro app que tem as permissões necessárias. Para mais detalhes, consulte Apps headless.

Migração de permissões

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

Em uma atualização do Android 9 para a 10, todas as permissões com restrição rígida são na lista de permissões. Para ver detalhes sobre como implementar as permissões de divisão em primeiro e segundo plano, consulte a mudança de privacidade do Android 10, começando com Solicitar plano de fundo. local.

Integração

Ao integrar o modelo de permissões de tempo de execução do aplicativo para o Android 6.0 e superior, você precisa atualizar os apps pré-instalados para trabalhar com o novo modelo. Também é possível definir exceções para apps que são os gerenciadores/provedores padrão para a funcionalidade principal, definem permissões personalizadas e personalizar o tema usado no app PermissionController.

Atualizar apps

Os apps na imagem do sistema e os pré-instalados não são concedidos automaticamente. permissões. Recomendamos que você trabalhe com desenvolvedores de apps pré-instalados (OEM, operadora e para fazer as modificações necessárias no app usando o desenvolvedor diretrizes. Especificamente, verifique se os apps pré-instalados são modificados para evitar falhas e outros problemas quando os usuários revogam permissões.

Apps pré-carregados

No Android 9 e versões anteriores, os apps pré-carregados que usam permissões perigosas precisam ser direcionados ao nível 23 da API ou posterior e manter o modelo de permissão do AOSP para Android 6.0 ou superior. Por exemplo, o fluxo da interface durante uma instalação do aplicativo não deve se desviar da implementação do AOSP PermissionController: Os usuários podem até mesmo revogar as permissões perigosas de apps pré-instalados.

Nas versões 6.0 a 9 do Android, algumas permissões são concedidas durante o fluxo de instalação. No entanto, a partir do em 10, o fluxo de instalação (executado pelo aplicativo Package Installer) é uma função separada da concessão de permissões (na Permission Controller).

Apps headless

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

• No Android 5.1 e versões anteriores, os apps headless podem solicitar permissões quando instalados ou se foram pré-instalados sem o uso de uma atividade.
• Em No Android 6.0 e versões mais recentes, os apps headless precisam usar um dos métodos abaixo para solicitar permissões:
• Adicione uma atividade para solicitar permissões. Esse é o método recomendado.
• Compartilhe um UID com outro app que tenha as permissões necessárias. Usar método apenas quando você precisa que a plataforma lide com vários APKs como um único app.

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

Personalizar a interface do PackageInstaller

Se quiser, você pode personalizar o tema "Permissões" da interface atualizando os temas padrão de dispositivos (Theme.DeviceDefault.Settings e Theme.DeviceDefault.Light.Dialog.NoActionBar) usadas pelos o PackageInstaller. No entanto, como a consistência é fundamental para os desenvolvedores de apps, não é possível personalizar o posicionamento, a posição e as regras de quando as permissões A interface do usuário aparece.

Para incluir strings para outros idiomas, contribua com o strings para o AOSP.

Criar exceções

É possível conceder permissões prévias a apps que são gerenciadores ou provedores para as funcionalidades principais do SO usando o Classe DefaultPermissionGrantPolicy.java no PackageManager. Exemplos:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Definir permissões personalizadas

É possível definir permissões e grupos personalizados como usuários normais ou perigosa e adicionar permissões específicas do OEM/operadora a aplicativos grupos de permissões, da mesma forma que seria possível no Android 5.x e versões anteriores.

No Android 6.0 e posterior, se você adicionar uma nova permissão perigosa, ela deverá ser processada 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 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 nos apps instalados no dispositivo. mas não é possível adicionar novos grupos de permissões ao manifesto da plataforma.

Permissões de teste

O Android inclui testes de conjunto de teste de compatibilidade (CTS) que verificam as permissões individuais são mapeadas para os grupos corretos. Passar nesses testes é um requisito de compatibilidade com o Android 6.0 e versões posteriores do CTS.

Revogar permissões

No Android 13 e versões mais recentes, é possível revogar seus próprios permissões de execução usando Context.revokeSelfPermissionsOnKill(): A revogação acontece de forma assíncrona e é acionada quando é seguro fazer isso sem interrupções. o usuário. Quando a revogação é acionada, todos os processos em execução no UID de chamada são encerrados.

É importante entender que a revogação de uma única permissão pode não se refletir no interface de usuário de configurações, que trata as permissões por grupo. Normalmente, um grupo de permissões é exibido como concedidas, desde que pelo menos uma das permissões do grupo seja concedida. Se garantir que os usuários confirmar a revogação nas configurações for importante para você, revogue todas no grupo de permissões. Para saber quais permissões pertencem a um determinado grupo, você pode usar PackageManager.getGroupOfPlatformPermission e PackageManager.getPlatformPermissionsForGroup.

Quando o sistema revoga as permissões solicitadas, ele também revoga o segundo plano correspondente do usuário se nenhuma das permissões em primeiro plano correspondentes ainda tiver sido concedida.

A revogação não será acionada enquanto o processo permanecer em primeiro plano, mas poderá também serão acionadas imediatamente ao eliminar manualmente todos os processos em execução no UID atual, por instância usando System.exit(). No entanto, recomendamos deixar o sistema decidir quando acioná-lo.

Quando a revogação de uma permissão entrar em vigor, você poderá solicitá-la novamente, e o usuário será solicitado a conceder ou negar a solicitação. Não é possível solicitar uma permissão foram negadas anteriormente pelo usuário. Recomendamos que você revogue as permissões estão atualmente retidos, mas não são mais necessários, você deve ter cuidado para não informar o usuário sobre a da revogação até que entrem em vigor.