Solicitar permissões de execução

Cada app Android é executado em um sandbox com acesso limitado. Se o app precisa usar recursos ou informações fora do próprio sandbox, declare uma permissão de execução e configure uma solicitação de permissão para fornecer esse acesso. Essas etapas fazem parte do fluxo de trabalho para usar permissões.

Se você declarar alguma permissão perigosa, e se o app for instalado em um dispositivo com o Android 6.0 (API de nível 23) ou mais recente, será necessário solicitar as permissões perigosas no momento da execução seguindo as etapas deste guia.

Se você não declarar nenhuma permissão perigosa ou se o app estiver instalado em um dispositivo que executa o Android 5.1 (API de nível 22) ou versão mais antiga, as permissões serão concedidas automaticamente, e não será necessário concluir as etapas restantes desta página.

Princípios básicos

Os princípios básicos para solicitar permissões no momento da execução são os seguintes:

  • Solicite uma permissão no contexto, quando o usuário começar a interagir com o recurso que requer a permissão.
  • Não bloqueie o usuário. Sempre ofereça a opção de cancelar um fluxo de interface educacional, como um fluxo que explique a lógica para solicitar permissões.
  • Se o usuário negar ou revogar uma permissão necessária para um recurso, faça uma degradação suave para que ele possa continuar usando o app, possivelmente desativando o recurso que requer a permissão.
  • Não presuma nenhum comportamento do sistema. Por exemplo, não presuma que as permissões aparecem no mesmo grupo de permissões. Um grupo de permissões apenas ajuda o sistema a minimizar o número de caixas de diálogo que são apresentadas ao usuário quando um app solicita permissões relacionadas.

Fluxo de trabalho para solicitar permissões

Antes de declarar e solicitar permissões de execução no seu app, avalie se ele precisa fazer isso. É possível atender a muitos casos de uso no app, como tirar fotos, pausar a reprodução de mídia e exibir anúncios relevantes, sem precisar declarar nenhuma permissão.

Se você concluir que seu app precisa declarar e solicitar permissões de execução, siga estas etapas:

  1. No arquivo de manifesto do app, declare as permissões que o app pode precisar solicitar.
  2. Projete a UX do seu app para que ações específicas sejam associadas a permissões de execução específicas. Informe aos usuários quais ações podem exigir que eles concedam permissão para que o app acesse dados particulares do usuário.
  3. Espere o usuário invocar a tarefa ou ação no app que exige acesso a dados particulares específicos do usuário. Nesse momento, o app pode solicitar a permissão de execução necessária para acessar esses dados.

  4. Confira se o usuário já concedeu a permissão de execução que o app exige. Se tiver concedido, seu app poderá acessar os dados particulares do usuário. Caso contrário, continue para a próxima etapa.

    Você precisa conferir se tem essa permissão sempre que realizar uma operação que precise dela.

  5. Confira se o app precisa mostrar uma justificativa para o usuário, explicando por que é necessário conceder uma permissão de execução específica. Se o sistema determinar que seu app não mostrará uma justificativa, prossiga para a próxima etapa diretamente, sem exibir um elemento da interface.

    No entanto, se o sistema determinar que o app precisa exibir uma justificativa, apresente-a ao usuário em um elemento da interface. Nessa justificativa, explique claramente quais dados o app está tentando acessar e quais os benefícios ele pode oferecer ao usuário se conceder a permissão de execução. Depois que o usuário confirmar essa justificativa, siga para a próxima etapa.

  6. Solicite a permissão de execução que seu app exige para acessar os dados particulares do usuário. O sistema exibe um pedido de permissão de execução, como o mostrado na página de visão geral das permissões.

  7. Confira a resposta do usuário, seja para conceder ou negar a permissão de execução.

  8. Se a permissão foi concedida ao seu app, você pode acessar os dados particulares do usuário. Se a permissão tiver sido negada, faça uma degradação suave da experiência no app para que ele ofereça funcionalidade ao usuário, sem as informações protegidas pela permissão.

A Figura 1 ilustra o fluxo de trabalho e o conjunto de decisões associadas a esse processo:

Figura 1. Diagrama que mostra o fluxo de trabalho para declarar e solicitar permissões de execução no Android.

Determinar se o app já recebeu a permissão

Para verificar se o usuário já concedeu uma permissão específica ao app, transmita essa permissão ao método ContextCompat.checkSelfPermission(). Esse método retorna PERMISSION_GRANTED ou PERMISSION_DENIED, dependendo se o app tem ou não a permissão.

Explicar porque seu app precisa da permissão

A caixa de diálogo de permissões mostrada pelo sistema ao chamar requestPermissions() informa quais permissões o app solicita, mas não explica o motivo. Em alguns casos, o usuário pode achar isso confuso. É recomendável explicar ao usuário por que as permissões são necessárias para o app antes de chamar requestPermissions().

Pesquisas demonstram que os usuários se sentem mais à vontade com solicitações de permissões quando sabem por que o app precisa delas. Por exemplo, se a permissão é necessária para oferecer suporte a um recurso principal do app ou para publicidade. Consequentemente, se você só estiver usando uma fração das chamadas de API que se encaixam em um grupo de permissões, será relevante listar de maneira explícita quais permissões estão sendo usadas e o porquê. Por exemplo, se você só estiver usando a localização aproximada, informe isso ao usuário na descrição do app ou em artigos de ajuda sobre ele.

Em certas condições, também é útil informar os usuários sobre o acesso a dados sensíveis em tempo real. Por exemplo, caso você esteja acessando a câmera ou o microfone, é recomendável informar o usuário com um ícone de notificação em algum lugar do app ou na bandeja de notificações (se o aplicativo estiver sendo executado em segundo plano) para que não pareça que os dados estão sendo coletados clandestinamente.

Por fim, se você precisar solicitar uma permissão para que um recurso do seu app funcione, mas o motivo não estiver claro para o usuário, encontre uma maneira de informar por que você precisa das permissões mais sensíveis.

Se o método ContextCompat.checkSelfPermission() retornar PERMISSION_DENIED, chame shouldShowRequestPermissionRationale(). Se esse método retornar true, mostre uma interface educacional para o usuário. Nessa interface, descreva o motivo pelo qual o recurso que o usuário quer ativar precisa de uma permissão específica.

Além disso, se o app solicitar uma permissão relacionada à localização, ao microfone ou à câmera, considere explicar por que seu app precisa de acesso a essas informações.

Solicitar permissões

Depois que o usuário visualizar uma interface educacional ou o valor de retorno de shouldShowRequestPermissionRationale() indicar que você não precisa mostrar uma interface educacional, solicite a permissão. Os usuários veem uma caixa de diálogo de permissão do sistema, na qual podem escolher se querem conceder uma permissão específica ao app.

Para fazer isso, use o contrato RequestPermission, incluído em uma biblioteca AndroidX, em que você permite que o sistema gerencie o código de solicitação de permissão para você. Como o uso do contrato RequestPermission simplifica sua lógica, essa é a solução recomendada quando possível. No entanto, se necessário, você também pode gerenciar um código de solicitação por conta própria como parte da solicitação de permissão e incluir esse código na sua lógica de callback de permissão.

Permitir que o sistema gerencie o código de solicitação de permissão

Para que o sistema gerencie o código de solicitação associado a uma solicitação de permissões, adicione dependências nas seguintes bibliotecas no arquivo build.gradle do módulo:

Em seguida, você pode usar uma das seguintes classes:

As etapas a seguir mostram como usar o contrato RequestPermission. O processo é quase o mesmo para o contrato RequestMultiplePermissions.

  1. Na lógica de inicialização da atividade ou do fragmento, transmita uma implementação de ActivityResultCallback para uma chamada para registerForActivityResult(). O ActivityResultCallback define como o app processa a resposta do usuário à solicitação de permissão.

    Mantenha uma referência ao valor de retorno de registerForActivityResult(), que é do tipo ActivityResultLauncher.

  2. Para exibir a caixa de diálogo de permissões do sistema quando necessário, chame o método launch() na instância de ActivityResultLauncher que você salvou na etapa anterior.

    Depois que launch() for chamado, a caixa de diálogo de permissões do sistema será exibida. Quando o usuário faz uma escolha, o sistema invoca de maneira assíncrona a implementação de ActivityResultCallback, que você definiu na etapa anterior.

    Observação: seu app não pode personalizar a caixa de diálogo mostrada quando você chama launch(). Para oferecer mais informações ou contexto ao usuário, mude a IU do seu app para que fique claro por que um recurso do app precisa de uma permissão específica. Por exemplo, você pode mudar o texto no botão que ativa o recurso.

    Além disso, o texto na caixa de diálogo de permissão do sistema referencia o grupo de permissões associado à permissão solicitada. Esse grupo de permissões foi projetado para facilitar o uso do sistema, e seu app não pode depender de permissões estarem dentro ou fora de um grupo específico.

O snippet de código a seguir mostra como lidar com a resposta de permissões:

Kotlin

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
    registerForActivityResult(RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    }

Java

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
    registerForActivityResult(new RequestPermission(), isGranted -> {
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    });

E este snippet de código demonstra o processo recomendado para verificar se há uma permissão e solicitar uma permissão do usuário quando necessário:

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

Gerenciar o código de solicitação de permissão

Em vez de permitir que o sistema gerencie o código de solicitação de permissão, você pode gerenciar esse código por conta própria. Para isso, inclua o código da solicitação em uma chamada para requestPermissions().

O snippet de código a seguir demonstra como solicitar uma permissão usando um código de solicitação:

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

Depois que o usuário responder à caixa de diálogo de permissões do sistema, o sistema invocará a implementação do app de onRequestPermissionsResult(). O sistema passa a resposta do usuário para a caixa de diálogo de permissão, bem como o código de solicitação definido, conforme mostrado no snippet de código seguir:

Kotlin

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

Java

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

Solicitar permissões de localização

Ao solicitar permissões de localização, siga as mesmas práticas recomendadas de qualquer outra permissão de execução. Uma diferença importante quando se trata de permissões de localização é que o sistema inclui várias permissões relacionadas à localização. As permissões solicitadas e a forma como você as solicita dependem dos requisitos de localização do caso de uso do seu app.

Localização em primeiro plano

Se o app tiver um recurso que compartilhe ou receba informações de localização apenas uma vez ou por um período definido, esse recurso exigirá acesso à localização em primeiro plano. Veja alguns exemplos:

  • Em um app de navegação, um recurso permite que os usuários recebam navegação guiada.
  • Em um app de mensagens, um recurso permite que os usuários compartilhem a localização atual com outro usuário.

O sistema considera que seu app está usando a localização em primeiro plano se um recurso do app acessar a localização atual do dispositivo em uma das seguintes situações:

  • Uma atividade pertencente ao seu app está visível.

  • Seu app está executando um serviço em primeiro plano. Quando um serviço em primeiro plano está em execução, o sistema aumenta o reconhecimento do usuário mostrando uma notificação contínua. Seu app mantém o acesso quando está em segundo plano, como quando o usuário pressiona o botão home no dispositivo ou bloqueia a tela.

    No Android 10 (API de nível 29) e versões mais recentes, é necessário declarar um tipo de serviço em primeiro plano de location, conforme mostrado no snippet de código a seguir. Em versões anteriores do Android, é recomendável declarar esse tipo de serviço em primeiro plano.

    <!-- Recommended for Android 9 (API level 28) and lower. -->
<!-- Required for Android 10 (API level 29) and higher. -->
<service
    android:name="MyNavigationService"
    android:foregroundServiceType="location" ... >
    <!-- Any inner elements go here. -->
</service>

Declare a necessidade de localização em primeiro plano quando seu app solicitar a permissão ACCESS_COARSE_LOCATION ou ACCESS_FINE_LOCATION, conforme mostrado no snippet a seguir:

<manifest ... >
  <!-- Include this permission any time your app needs location information. -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

Localização em segundo plano

Um app exige acesso à localização em segundo plano se um recurso do app compartilha constantemente a localização com outros usuários ou usa a API Geofence. Entre os exemplos estão os seguintes:

  • Em um app para compartilhamento de local com a família, um recurso permite que os usuários compartilhem a localização com os parentes de forma contínua.
  • Em um app de IoT, um recurso permite que os usuários configurem os dispositivos da casa para que sejam desligados quando eles saem e ligados novamente quando voltam.

O sistema considera que seu app está usando a localização em segundo plano se ele acessa a localização atual do dispositivo em qualquer situação diferente das descritas na seção Localização em primeiro plano. A precisão da localização em segundo plano é igual à precisão da localização em primeiro plano, que depende das permissões declaradas pelo app.

No Android 10 (API de nível 29) e versões mais recentes, é necessário declarar a permissão ACCESS_BACKGROUND_LOCATION no manifesto do app para solicitar acesso à localização em segundo plano no tempo de execução. Nas versões anteriores do Android, quando o app recebe acesso à localização em primeiro plano, também recebe acesso à localização em segundo plano automaticamente.

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

Processar negação de permissão

Se o usuário negar uma solicitação de permissão, seu app precisará ajudar a entender as implicações de negar essa permissão. Mais especificamente, seu app precisa informar os usuários sobre os recursos que não funcionam devido à ausência da permissão. Ao fazer isso, lembre-se das seguintes práticas recomendadas:

  • Direcione a atenção do usuário. Destaque uma parte específica da IU do app em que a funcionalidade será limitada porque o app não tem a permissão necessária. Veja alguns exemplos do que você pode fazer:

    • Mostrar uma mensagem em que os resultados ou dados do recurso seriam exibidos.
    • Exibir um botão diferente que contenha um ícone e uma cor de erro.

  • Faça uma descrição específica. Não mostre uma mensagem genérica. Em vez disso, deixe claro quais recursos não estão disponíveis porque o app não tem a permissão necessária.

  • Não bloqueie a interface do usuário. Em outras palavras, não exiba uma mensagem de aviso em tela cheia que impeça o usuário de continuar usando o app.

Ao mesmo tempo, o app precisa respeitar a decisão do usuário de negar uma permissão. A partir do Android 11 (API de nível 30), se o usuário tocar mais de uma vez em Negar para uma permissão específica durante a vida útil da instalação do app em um dispositivo, a caixa de diálogo de permissões do sistema não será exibida se o app solicitar a permissão novamente. A ação do usuário implica "não perguntar novamente". Em versões anteriores, uma caixa de diálogo de permissões do sistema era mostrada toda vez que o app solicitava uma permissão, a menos que uma caixa de seleção "não perguntar novamente" tivesse sido selecionada.

Se um usuário negar uma permissão mais de uma vez, isso é considerado uma negação permanente. É muito importante solicitar permissões apenas quando os usuários precisarem de acesso a um recurso específico. Caso contrário, é possível que você perca acidentalmente a capacidade de solicitar permissões mais uma vez.

Em determinadas situações, a permissão pode ser negada automaticamente, sem interferência do usuário. Da mesma forma, uma permissão também pode ser concedida de forma automática. É importante não presumir nada sobre o comportamento automático. Sempre que seu app precisar acessar uma funcionalidade que exija uma permissão, confira se ele ainda tem essa permissão.

Para oferecer ao usuário a melhor experiência possível ao pedir permissões, consulte também as Práticas recomendadas de permissões do app.

Inspecionar status de negação durante testes e depuração

Para identificar se um app teve permissões permanentemente negadas (para fins de depuração e teste), use este comando:

adb shell dumpsys package PACKAGE_NAME

Em que PACKAGE_NAME é o nome do pacote a ser inspecionado.

A saída do comando contém seções parecidas com esta:

...
runtime permissions:
  android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...

As permissões que foram negadas uma vez pelo usuário são sinalizadas com USER_SET. As que foram negadas permanentemente selecionando a opção Negar duas vezes são sinalizadas com USER_FIXED.

Para garantir que os testadores recebam a caixa de diálogo de solicitação durante o teste, redefina essas flags quando terminar a depuração do app. Para isso, use o comando:

adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed

PERMISSION_NAME é o nome da permissão que você quer redefinir.

Para conferir uma lista completa de permissões do app Android, acesse a página de referência da API de permissões.

Permissões únicas

A opção chamada &quot;Apenas esta vez&quot; é o segundo dos três botões na caixa de diálogo.
Figura 2. Caixa de diálogo do sistema que aparece quando um app solicita uma permissão única.

A partir do Android 11 (API de nível 30), sempre que seu app solicita uma permissão relacionada a localização, microfone ou câmera, a caixa de diálogo de permissões voltada ao usuário contém uma opção chamada Apenas esta vez, conforme mostrado na figura 2. Se o usuário selecionar essa opção na caixa de diálogo, seu app receberá uma permissão única temporária.

O app poderá acessar os dados relacionados por um período que depende do comportamento do app e das ações do usuário:

  • Enquanto a atividade do seu app estiver visível, ele poderá acessar os dados.
  • Se o usuário colocar o app em segundo plano, o app poderá continuar acessando os dados por um curto período.
  • Se um serviço for iniciado em primeiro plano enquanto a atividade estiver visível, e o usuário mover o app para o segundo plano, o app vai continuar acessando os dados relacionados até que o serviço em primeiro plano seja interrompido.

O processo de apps é encerrado quando a permissão é revogada

Se o usuário revogar a permissão única (por exemplo, nas configurações do sistema), o app não vai poder acessar os dados, mesmo que você tenha iniciado um serviço em primeiro plano. Como acontece com qualquer permissão, se o usuário revogar a permissão única do app, o processo do app será encerrado.

Da próxima vez que o usuário abrir o app e um recurso dele solicitar acesso à localização, ao microfone ou à câmera, a solicitação vai aparecer novamente.

Redefinir permissões não usadas

O Android oferece várias maneiras de redefinir as permissões de execução que não foram não usadas para o estado padrão e negado:

Remover acesso do app

No Android 13 (nível 33 da API) e versões mais recentes, é possível remover o acesso do app às permissões de execução que ele não exige mais. Ao atualizar seu app, siga esta etapa para que os usuários possam entender melhor por que ele continua a solicitar permissões específicas. Esse conhecimento ajuda a gerar confiança no usuário em relação ao seu app.

Para remover o acesso a uma permissão de execução, transmita o nome dessa permissão para revokeSelfPermissionOnKill(). Para remover o acesso a um grupo de permissões de execução ao mesmo tempo, transmita uma coleção de nomes de permissões para revokeSelfPermissionsOnKill(). O processo de remoção de permissões acontece de forma assíncrona e encerra todos os processos associados ao UID do app.

Para que o sistema remova o acesso do app às permissões, todos os processos vinculados ao app precisam ser encerrados. Quando você chama a API, o sistema determina qual é o momento mais seguro para fazer isso. Geralmente, o sistema espera o app ficar em segundo plano por um longo período.

Para informar ao usuário que seu app não exige mais acesso a permissões específicas de execução, mostre uma caixa de diálogo na próxima vez que o usuário iniciar o app. Você pode incluir nela uma lista das permissões.

Redefinir automaticamente as permissões de apps não usados

Se o app for direcionado ao Android 11 (nível 30 da API) ou a uma versão mais recente e não for usado por alguns meses, o sistema vai proteger os dados do usuário redefinindo automaticamente as permissões de execução confidenciais que o usuário concedeu ao app. Saiba mais no guia sobre hibernação de apps.

Pedir para se tornar o gerenciador padrão, se necessário

Alguns apps dependem do acesso a informações confidenciais do usuário relacionadas a registros de chamadas e mensagens SMS. Se você quiser solicitar permissões especificamente para registros de chamadas e mensagens SMS e publicar seu app na Play Store, precisará solicitar que o usuário configure seu app como o gerenciador padrão de uma função principal do sistema antes de solicitar essas permissões de execução.

Para mais informações sobre gerenciadores padrão, incluindo orientações sobre como mostrar uma solicitação de gerenciador padrão para o usuário, consulte o guia sobre permissões usadas somente em gerenciadores padrão.

Conceder todas as permissões de execução para fins de teste

Para conceder todas as permissões de execução automaticamente ao instalar um app em um emulador ou dispositivo de teste, use a opção -g para o comando adb shell install, conforme demonstrado no snippet de código a seguir:

adb shell install -g PATH_TO_APK_FILE

Outros recursos

Para mais informações sobre permissões, leia estes artigos:

Para saber mais sobre solicitação de permissões, consulte os exemplos de permissões (link em inglês).

Você também pode concluir este codelab que demonstra as práticas recomendadas de privacidade.

Anterior
Declarar permissões do app
Próxima
Solicitar permissões especiais