blob: 762e1ae8243d88962a3d39690bb9748cee2f96bf [file] [log] [blame]
page.title=Permissões
page.tags=previewresources, androidm
page.keywords=permissions, runtime, preview
page.image={@docRoot}preview/images/permissions_check.png
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>Visualização rápida</h2>
<ul>
<li>Se o aplicativo direciona o M Preview SDK, ele indica aos usuários para conceder
permissões no tempo de execução, em vez de tempo de instalação.</li>
<li>Os usuários podem revogar as permissões a qualquer momento na tela de configurações
do aplicativo.</li>
<li>O aplicativo precisa verificar se tem as permissões necessárias
sempre que for executado.</li>
</ul>
<h2>Neste documento</h2>
<ol>
<li><a href="#overview">Visão geral</a></li>
<li><a href="#coding">Codificação para permissões de tempo de execução</a></li>
<li><a href="#testing">Teste de permissões de tempo de execução</a></li>
<li><a href="#best-practices">Práticas recomendadas</a></li>
</ol>
<!--
<h2>Related Samples</h2>
<ol>
<li></li>
</ol>
-->
<!--
<h2>See also</h2>
<ol>
<li></li>
</ol>
-->
</div> <!-- qv -->
</div> <!-- qv-wrapper -->
<p>
O M Developer Preview introduz um novo modelo de permissões de aplicativo
que agiliza o processo de instalação e atualização de aplicativos para os usuários. Se um aplicativo
que está sendo executado no M Preview suporta o novo modelo de permissões, o usuário não precisa conceder
permissões ao instalar ou atualizar o aplicativo. Em vez disso, o aplicativo
solicita as permissões à medida que precisar e o sistema exibe um diálogo
ao usuário pedindo a permissão.
</p>
<p>
Se um aplicativo suportar o novo modelo de permissões, ele
ainda poderá ser instalado e executado em versões mais antigas do Android, usando o antigo modelo
de permissões nesses dispositivos.
</p>
<h2 id="overview">
Visão geral
</h2>
<p>
Com o M Developer Preview, a plataforma introduz um novo modelo
de permissões. Eis um resumo dos componentes essenciais deste novo modelo:
</p>
<ul>
<li>
<strong>Declaração de permissões:</strong> O aplicativo declara todas
as permissões necessárias no manifesto, como nas plataformas anteriores do Android.
</li>
<li>
<strong>Grupos de permissão:</strong> As permissões são divididas em
<em>grupos de permissão</em>, baseados na funcionalidade. Por exemplo: o grupo de permissão
<code>CONTACTS</code> contém permissões para ler e escrever
informações de perfil e contatos do usuário.
</li>
<li>
<p><strong>Permissões limitadas concedidas no tempo de instalação:</strong> Quando o usuário
instala ou atualiza o aplicativo, o sistema concede todas
as permissões que o aplicativo solicita que estão em {@link
android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}.
Por exemplo: as permissões de internet e despertador estão em {@link
android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}. Portanto,
as permissões são concedidas automaticamente no tempo de instalação.
</p>
<p>O sistema pode também conceder as permissões de sistema e assinatura de aplicativo,
como descrito em <a href="#system-apps">permissões de assinatura
e aplicativos do sistema</a>. O usuário <em>não</em> é alertado a conceder permissões
no tempo de instalação.</p>
</li>
<li>
<strong>O usuário concede permissões no tempo de execução:</strong> Quando um aplicativo solicita
uma permissão, o sistema exibe um diálogo ao usuário e, em seguida,
chama a função de retorno de chamada do aplicativo para notificá-lo se a permissão foi concedida. Se um
usuário concede uma permissão, o aplicativo recebe todas
as permissões na área funcional desta permissão que foram declaradas no manifesto do aplicativo.
</li>
</ul>
<p>
Este modelo de permissões altera a forma como o aplicativo se comporta diante os recursos
que precisam de permissões. Eis um resumo das práticas de desenvolvimento que devem
ser seguidas para ajustar para este modelo:
</p>
<ul>
<li>
<strong>Sempre verificar as permissões:</strong> Quando o aplicativo
precisa realizar uma ação que requer uma permissão, ele deve primeiro verificar
se já a tem. Caso não tenha, ele solicita
o concedimento desta permissão.
</li>
<li>
<strong>Lidar com falta de permissões dignamente:</strong> Se o aplicativo não
recebe a permissão adequada, ele deve lidar com a falha de forma limpa.
Por exemplo, se a permissão é necessária para um recurso adicionado,
o aplicativo pode desativar este recurso. Se a permissão for essencial
para que o aplicativo funcione, ele desativará toda sua funcionalidade
e informará ao usuário que precisa desta permissão.
</li>
<div class="figure" style="width:220px" id="fig-perms-screen">
<img src="{@docRoot}preview/features/images/app-permissions-screen_2x.png" srcset="{@docRoot}preview/features/images/app-permissions-screen.png 1x, {@docRoot}preview/features/images/app-permissions-screen_2x.png 2x" alt="" width="220">
<p class="img-caption">
<strong>Figura 1.</strong> Tela de permissões nas configurações do aplicativo.
</p>
</div>
<li>
<strong>As permissões são revogáveis:</strong> Os usuários podem revogar as permissões
de um aplicativo a qualquer momento. Se um usuário desativar as permissões de um aplicativo,
o aplicativo <em>não</em> é notificado. Novamente, o aplicativo deve verificar
se tem todas as permissões necessárias antes de realizar qualquer ação restrita.
</li>
</ul>
<p class="note">
<strong>Observação:</strong> se um aplicativo direcionar o M Developer Preview, ele
<em>deve</em> usar o novo modelo de permissões.
</p>
<p>
No momento do lançamento do M Developer Preview,
nem todos os aplicativos Google implementam completamente o novo modelo de permissões. A Google está atualizando estes aplicativos
durante o curso do M Developer Preview para respeitar adequadamente a configuração
de alternação de permissões.
</p>
<p class="note">
<strong>Observação:</strong> se o aplicativo tiver a própria superfície de API,
não represente permissões sem antes garantir que o autor da chamada tenha as permissões necessárias
para acessar esses dados.
</p>
<h3 id="system-apps">
Permissões de assinatura e aplicativos do sistema
</h3>
<p>
Geralmente, quando um usuário instala um aplicativo, o sistema somente fornece ao aplicativo o
{@link android.content.pm.PermissionInfo#PROTECTION_NORMAL
PROTECTION_NORMAL}. No entanto, sob algumas circunstâncias, o sistema concede
ao aplicativo mais permissões:
</p>
<ul>
<li>Se um aplicativo faz parte da imagem do sistema, ele recebe automaticamente
todas as permissões listadas no manifesto.
</li>
<li>Se o aplicativo solicitar as permissões no manifesto que está em {@link
android.content.pm.PermissionInfo#PROTECTION_SIGNATURE PROTECTION_SIGNATURE},
e estiver assinado com o mesmo certificado que o aplicativo que declarou essas permissões,
o sistema concederá essas permissões na instalação ao aplicativo
que fez a solicitação.
</li>
</ul>
<p>
Em ambos os casos, o usuário ainda pode revogar as permissões a qualquer
momento acessando a tela de <strong>configurações</strong> do sistema e escolhendo <strong>Aplicativos
&gt;</strong> <i>app_name</i> <strong>&gt; Permissões</strong>. O aplicativo
deve continuar com a verificação das permissões no tempo de execução e solicitá-las
se necessário.
</p>
<h3 id="compatibility">
Compatibilidade anterior e posterior
</h3>
<p>
Se um aplicativo não direciona para o M Developer Preview, ele deve continuar a usar
o modelo antigo de permissões mesmo nos dispositivos M Preview. Quando o usuário instala
o aplicativo, o sistema pede para que ele conceda todas as permissões
listadas no manifesto do aplicativo.
</p>
<p class="note">
<strong>Observação:</strong> em dispositivos que são executados no M Developer Preview,
um usuário pode desativar as permissões para qualquer aplicativo (incluindo aplicativos de legado)
na tela de configurações do aplicativo. Se um usuário desativa as permissões de um aplicativo de legado, o sistema
silenciosamente desativa a funcionalidade adequada. Quando um aplicativo tentar realizar
uma operação que requer esta permissão, a operação não necessariamente causará
uma exceção. Em vez disso, ele retornará um conjunto de dados vazio,
sinalizará um erro ou exibirá um comportamento inesperado. Por exemplo, caso queira
consultar um calendário sem permissão, o método retorna um conjunto de dados vazio.
</p>
<p>
Se instalar um aplicativo usando o novo modelo de permissões em um dispositivo
que não está executando o M Preview,
o sistema o tratará da mesma forma que qualquer outro aplicativo: o sistema pedirá
para que o usuário conceda todas as permissões declaradas no momento da instalação.
</p>
<p class="note">
<strong>Observação:</strong> para a liberação de prévia, deve-se definir a versão mínima de SDK
para o M Preview SDK para compilar com o SDK de prévia. Isto significa que você
não poderá testar tais aplicativos em plataformas mais antigas durante a prévia
de desenvolvedor.
</p>
<h3 id="perms-vs-intents">Permissões versus intenções</h3>
<p>
Em vários casos, é possível escolher entre duas maneiras para que o aplicativo realize
uma tarefa. É possível fazer com que o aplicativo solicite uma permissão para realizar a operação
por conta própria. Alternativamente, é possível fazer com que o aplicativo use uma intenção para que outro aplicativo
realize a tarefa.
</p>
<p>
Por exemplo, imagine que o aplicativo precisa da função de tirar fotos com
a câmera do dispositivo. O aplicativo pode solicitar a permissão
<code>android.permission.CAMERA</code>, que permite que ele acesse
a câmera diretamente. O aplicativo então usará as APIs da câmera
para controlar a câmera e tirar uma foto. Esta abordagem fornece ao aplicativo
controle completo sobre o processo de fotografia e permite
que você incorpore a IU da câmera.
</p>
<p>
No entanto, caso não precise de tal controle, é possível apenas usar uma intenção {@link
android.provider.MediaStore#ACTION_IMAGE_CAPTURE ACTION_IMAGE_CAPTURE}
para solicitar uma imagem. Ao iniciar a intenção, o usuário deve escolher
um aplicativo de câmera (se não houver um aplicativo padrão de câmera)
para tirar a foto. O aplicativo da câmera retorna a imagem ao método {@link
android.app.Activity#onActivityResult onActivityResult()} do aplicativo.
</p>
<p>
De forma semelhante, caso precise realizar uma ligação,
acessar os contatos do usuário etc., é possível fazer estas ações criando uma intenção adequada
ou solicitar a permissão e o acesso aos objetos adequados diretamente. Essas são
as vantagens e desvantagens de cada abordagem.
</p>
<p>
Se usar permissões:
</p>
<ul>
<li>O aplicativo tem controle completo sobre a experiência do usuário ao realizar
a operação. No entanto, esse controle amplo é adicionado à complexidade da tarefa,
levando em consideração a necessidade de projetar uma IU adequada.
</li>
<li>O usuário deve fornecer a permissão uma vez: na primeira realização
da operação. Depois, o aplicativo pode realizar a operação sem
precisar de mais interações do usuário. No entanto,
se o usuário não conceder a permissão (ou revogá-la posteriormente),
o aplicativo não conseguirá realizar a operação.
</li>
</ul>
<p>
Se usar uma intenção:
</p>
<ul>
<li>Você não terá que projetar a IU para a operação. O aplicativo que lida com
a intenção fornece a IU. No entanto, isso significa que você não terá controle
completo sobre a experiência de usuário. O usuário poderá interagir com um aplicativo
que você nunca viu.
</li>
<li>Se o usuário não tem um aplicativo padrão para a operação,
o sistema pede para que o usuário escolha um aplicativo.
Se o usuário não designar um manipulador padrão,
ele terá que acessar uma caixa de diálogo extra sempre que realizar a operação.
</li>
</ul>
<h2 id="coding">Codificação para permissões de tempo de execução</h2>
<p>
Se um aplicativo direciona o novo M Developer Preview, ele deve usar o novo
modelo de permissões. Isto significa que, além de declarar as permissões necessárias no manifesto,
deve-se também verificar se o aplicativo
tem as permissões no tempo de execução e,
caso ainda não as tenha, solicitá-las.
</p>
<h3 id="enabling">
Possibilitar um novo modelo de permissões
</h3>
<p>
Para possibilitar o modelo de permissões do M Developer Preview, configure o atributo
<code>targetSdkVersion</code> do aplicativo para <code>"MNC"</code> e
<code>compileSdkVersion</code> para <code>"android-MNC"</code>. Isto ativará
todos os novos recursos de permissão.
</p>
<p>
Para a liberação de uma prévia, deve-se definir <code>minSdkVersion</code> para
<code>"MNC"</code> para compilar com o SDK de prévia.
</p>
<h3 id="m-only-perm">
Designar uma permissão somente para o M Preview
</h3>
<p>
É possível usar o novo elemento <code>&lt;uses-permission-sdk-m&gt;</code> no manifesto do aplicativo
para indicar que uma permissão é necessária apenas no M Developer Preview. Se você
declarar uma permissão desta maneira, sempre que o aplicativo for instalado
em um dispositivo mais antigo, o sistema não solicitará ao usuário
nem concederá a permissão ao aplicativo. Usando o elemento <code>&lt;uses-permission-sdk-m&gt;</code>
, é possível adicionar novas permissões
a versões atualizadas do aplicativo sem forçar os usuários a conceder permissões
ao instalar a atualização.
</p>
<p>
Se o aplicativo está sendo executado em um dispositivo com M Developer Preview, o
<code>&lt;uses-permission-sdk-m&gt;</code> se comporta da mesma forma que
<code><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html">&lt;uses-permission&gt;</a></code>.
O sistema não solicita ao usuário que conceda quaisquer permissões ao instalar o aplicativo
e o aplicativo solicita as permissões à medida que forem necessárias.
</p>
<h3 id="prompting">
Solicitação de permissões
</h3>
<p>
Se o aplicativo usa o novo modelo de permissões do M Developer Preview,
o usuário não recebe solicitações para conceder todas as permissões quando o aplicativo é iniciado pela primeira vez em um dispositivo
que está sendo executado no M Preview. Em vez disso, o aplicativo solicita as permissões à medida
que forem necessárias. Quando um aplicativo solicita uma permissão, o sistema exibe uma caixa de diálogo
ao usuário.
</p>
<p>
Se o aplicativo executar em um dispositivo que tem SDK 22 ou inferior,
ele usará o antigo modelo de permissões. Quando o usuário instala o aplicativo, ele é solicitado a conceder
todas as permissões que o aplicativo lista no manifesto,
exceto as permissões que forem marcadas com <code>&lt;uses-permission-sdk-m&gt;</code>.
</p>
<h4 id="check-platform">Verifique em qual plataforma o aplicativo está sendo executado</h4>
<p>
Este modelo de permissões é suportado apenas em dispositivos que estão executando
o M Developer Preview. Antes de chamar qualquer um destes métodos,
o aplicativo deve verificar em qual plataforma está sendo executado
verificando o valor de {@link android.os.Build.VERSION#CODENAME
Build.VERSION.CODENAME}. Se o dispositivo estiver sendo executado no M Developer Preview,
{@link android.os.Build.VERSION#CODENAME CODENAME} será <code>"MNC"</code>.
</p>
<h4 id="check-for-permission">Verifique se o aplicativo tem a permissão necessária</h4>
<p>Quando o usuário tenta fazer algo que requer uma permissão,
o aplicativo verifica se tem a permissão para realizar esta operação. Para fazer isto,
o aplicativo chama
<code>Context.checkSelfPermission(<i>permission_name</i>)</code>. O aplicativo
deve realizar isto para verificar se sabe que o usuário já concedeu esta permissão,
levando em consideração que o usuário pode revogar
as permissões do aplicativo a qualquer momento. Por exemplo,
se um usuário quiser usar um aplicativo para tirar uma foto, o aplicativo chamará
<code>Context.checkSelfPermission(Manifest.permission.CAMERA)</code>.</p>
<p class="table-caption" id="permission-groups">
<strong>Tabela 1.</strong> Permissões e grupos de permissões.</p>
<table>
<tr>
<th scope="col">Grupo de permissões</th>
<th scope="col">Permissões</th>
</tr>
<tr>
<td><code>android.permission-group.CALENDAR</code></td>
<td>
<ul>
<li>
<code>android.permission.READ_CALENDAR</code>
</li>
</ul>
<ul>
<li>
<code>android.permission.WRITE_CALENDAR</code>
</li>
</ul>
</td>
</tr>
<tr>
<td><code>android.permission-group.CAMERA</code></td>
<td>
<ul>
<li>
<code>android.permission.CAMERA</code>
</li>
</ul>
</td>
</tr>
<tr>
<td><code>android.permission-group.CONTACTS</code></td>
<td>
<ul>
<li>
<code>android.permission.READ_CONTACTS</code>
</li>
<li>
<code>android.permission.WRITE_CONTACTS</code>
</li>
<li>
<code>android.permission.READ_PROFILE</code>
</li>
<li>
<code>android.permission.WRITE_PROFILE</code>
</li>
</ul>
</td>
</tr>
<tr>
<td><code>android.permission-group.LOCATION</code></td>
<td>
<ul>
<li>
<code>android.permission.ACCESS_FINE_LOCATION</code>
</li>
<li>
<code>android.permission.ACCESS_COARSE_LOCATION</code>
</li>
</ul>
</td>
</tr>
<tr>
<td><code>android.permission-group.MICROPHONE</code></td>
<td>
<ul>
<li>
<code>android.permission.RECORD_AUDIO</code>
</li>
</ul>
</td>
</tr>
<tr>
<td><code>android.permission-group.PHONE</code></td>
<td>
<ul>
<li>
<code>android.permission.READ_PHONE_STATE</code>
</li>
<li>
<code>android.permission.CALL_PHONE</code>
</li>
<li>
<code>android.permission.READ_CALL_LOG</code>
</li>
<li>
<code>android.permission.WRITE_CALL_LOG</code>
</li>
<li>
<code>com.android.voicemail.permission.ADD_VOICEMAIL</code>
</li>
<li>
<code>android.permission.USE_SIP</code>
</li>
<li>
<code>android.permission.PROCESS_OUTGOING_CALLS</code>
</li>
</ul>
</td>
</tr>
<tr>
<td><code>android.permission-group.SENSORS</code></td>
<td>
<ul>
<li>
<code>android.permission.BODY_SENSORS</code>
</li>
</ul>
<ul>
<li>
<code>android.permission.USE_FINGERPRINT</code>
</li>
</ul>
</td>
</tr>
<tr>
<td><code>android.permission-group.SMS</code></td>
<td>
<ul>
<li>
<code>android.permission.SEND_SMS</code>
</li>
<li>
<code>android.permission.RECEIVE_SMS</code>
</li>
<li>
<code>android.permission.READ_SMS</code>
</li>
<li>
<code>android.permission.RECEIVE_WAP_PUSH</code>
</li>
<li>
<code>android.permission.RECEIVE_MMS</code>
</li>
<li>
<code>android.permission.READ_CELL_BROADCASTS</code>
</li>
</ul>
</td>
</tr>
</table>
<h4 id="request-permissions">Solicitar permissões se necessário</h4>
<p>Se o aplicativo já não tem a permissão necessária, ele chama o método
<code>Activity.requestPermissions(String[], int)</code> para solicitar
as permissões necessárias. O aplicativo passa
as permissões que deseja e também um "código de solicitação" do inteiro.
Este método funciona de forma assíncrona: ele retorna imediatamente e,
depois que o usuário responde à caixa de diálogo, o sistema chama
o método de retorno de chamada do aplicativo com os resultados, passando o mesmo "código de solicitação" que o aplicativo passou
para <code>requestPermissions()</code>.</p>
<p>O seguinte código verifica se o aplicativo tem a permissão
para ler os contatos do usuário e solicita a permissão, se necessário:</p>
<pre>
if (checkSelfPermission(Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
// MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
// app-defined int constant
return;
}
</pre>
<h4 id="handle-response">Lidar com a resposta de solicitação das permissões</h4>
<p>
Quando um aplicativo solicita as permissões, o sistema apresenta uma caixa de diálogo
ao usuário. Quando o usuário responde, o sistema invoca o
<code>Activity.onRequestPermissionsResult(int, String[], int[])</code>
do aplicativo, passando a ele a resposta do usuário. O aplicativo precisa substituir este método. O retorno de chamada
recebe o mesmo código de solicitação passado para
<code>requestPermissions()</code>. Por exemplo, se um aplicativo solicita o acesso
<code>READ_CONTACTS</code>, ele pode ter o seguinte
método de retorno de chamada:
</p>
<pre>
&#64;Override
public void onRequestPermissionsResult(int requestCode,
String permissions[], int[] grantResults) {
switch (requestCode) {
case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
// permission was granted, yay! do the
// calendar task you need to do.
} else {
// permission denied, boo! Disable the
// functionality that depends on this permission.
}
return;
}
// other 'switch' lines to check for other
// permissions this app might request
}
}
</pre>
<p>Se o usuário concede a permissão, o sistema fornece ao aplicativo todas as permissões
que o manifesto do aplicativo lista para esta área funcional. Se o usuário negar a solicitação,
deve-se tomar a ação adequada. Por exemplo, deve-se desativar
quaisquer ações de menu que dependam desta permissão.
</li>
</p>
<p>
Quando o sistema pede para que o usuário conceda uma permissão, esse usuário tem a opção
de dizer ao sistema para que não peça esta permissão novamente. Nesse caso,
quando um aplicativo usa <code>requestPermissions()</code> para solicitar esta permissão,
o sistema nega imediatamente. Neste caso, o sistema chama
<code>onRequestPermissionsResult()</code> da mesma forma que faria se o usuário tivesse
rejeitado explicitamente a solicitação novamente. Por este motivo, o aplicativo
não pode presumir que uma interação direta com o usuário ocorreu.
</p>
<h2 id="testing">Teste de permissões de tempo de execução</h2>
<p>
Se o aplicativo for direcionado para o M Developer Preview, deve-se testar
se ele lida com as permissões corretamente. Não se pode presumir que o aplicativo
terá qualquer permissão quando executado. Quando o aplicativo é iniciado pela primeira vez,
é provável que não tenha permissões. O usuário pode revogar e restaurar permissões
a qualquer momento.
</p>
<p>
Deve-se testar o aplicativo para garantir que ele se comporte corretamente em todas
as situações de permissão. Com o M Preview SDK, fornecemos os novos comandos
de <a href="{@docRoot}tools/help/adb.html">Android
Debug Bridge (adb)</a> para possibilitar que o aplicativo seja testado com quaisquer
configurações de permissões necessárias.
</p>
<h3>
Novas opções e comandos adb
</h3>
<p>
As ferramentas da plataforma M Preview SDK fornecem vários comandos novos para permitir
que você teste como o aplicativo lida com permissões.
</p>
<h4>
Instalar com permissões
</h4>
<p>
É possível usar a nova opção <code>-g</code> do comando <a href="{@docRoot}tools/help/adb.html#move"><code>adb
install</code></a>, que instala o aplicativo
e fornece todas as permissões listadas em seu manifesto:
</p>
<pre class="no-pretty-print">
$ adb install -g &lt;path_to_apk&gt;
</pre>
<h4>
Conceder e revogar permissões
</h4>
<p>
É possível usar os novos comandos do <a href="{@docRoot}tools/help/adb.html#pm">gerenciador
de pacotes (pm)</a> de ADB para conceder e revogar as permissões de um aplicativo instalado.
Esta funcionalidade pode ser útil para testes automatizados.
</p>
<p>
Para conceder uma permissão, use o comando <code>grant</code> do gerenciador de pacote:
</p>
<pre class="no-pretty-print">
$ adb pm grant &lt;package_name&gt; &lt;permission_name&gt;
</pre>
<p>
Por exemplo: para conceder a permissão do pacote com.example.myapp para gravar áudios,
use este comando:
</p>
<pre class="no-pretty-print">
$ adb pm grant com.example.myapp android.permission.RECORD_AUDIO
</pre>
<p>
Para revogar uma permissão, use o comando <code>revoke</code> do gerenciador de pacote:
</p>
<pre class="no-pretty-print">
$ adb pm revoke &lt;package_name&gt; &lt;permission_name&gt;
</pre>
<h2 id="best-practices">Práticas recomendadas</h2>
<p>
O novo modelo de permissões fornece aos usuários uma experiência mais suave
e facilita a instalação de aplicativos, deixando-os mais confortáveis
com o que os aplicativos estão fazendo. Sugerimos que você siga as práticas recomendadas para aproveitar
todas as vantagens do novo modelo.
</p>
<h3 id="bp-what-you-need">Peça somente as permissões necessárias</h3>
<p>
Sempre que você pede uma permissão, o usuário é forçado a tomar uma decisão.
Se o usuário negar a solicitação, a funcionalidade do aplicativo será reduzida.
Deve-se minimizar o número de solicitações realizadas.
</p>
<p>
Por exemplo: o aplicativo pode frequentemente adquirir a funcionalidade necessária usando
uma <a href="{@docRoot}guide/components/intents-filters.html">intenção</a> em vez
de solicitar permissões. Se o aplicativo precisa tirar fotos com a câmera do telefone,
é possível usar uma intenção {@link
android.provider.MediaStore#ACTION_IMAGE_CAPTURE
MediaStore.ACTION_IMAGE_CAPTURE}. Quando o aplicativo executa a intenção,
o sistema pede para que o usuário escolha um aplicativo de câmera já instalado
para tirar a foto.
</p>
<h3 id="bp-dont-overwhelm">
Não oprima o usuário
</h3>
<p>
Se você confrontar o usuário com várias solicitações de permissão de uma só vez,
é possível que ele se sinta oprimido e saia do aplicativo.
Em vez disso, deve-se solicitar as permissões somente quando necessário.
</p>
<p>
Em alguns casos, uma ou mais permissões podem ser absolutamente essenciais para o aplicativo.
Nesta situação, faz sentido solicitar todas as permissões assim
que o aplicativo é iniciado. Por exemplo: se você fizer um aplicativo de fotografia,
ele precisará de acesso à câmera do dispositivo. Quando o usuário iniciar o aplicativo
pela primeira vez, ele não se surpreenderá quando receber
uma solicitação de permissão para usar a câmera. Mas, se o mesmo aplicativo tiver um recurso
para compartilhar fotos com os contatos do usuário, <em>não</em> se deve
pedir esta permissão na primeira inicialização. Em vez disso, espere o usuário tentar usar
o recurso de compartilhamento para pedir a permissão.
</p>
<p>
Se o aplicativo fornecer um tutorial, faz sentido solicitar as permissões
necessárias no final da sequência do tutorial.
</p>
<h3 id="bp-explain">
Explique o porquê da necessidade das permissões
</h3>
<p>
O diálogo de permissões exibido pelo sistema ao chamar
<code>requestPermissions()</code> diz quais permissões o aplicativo requer,
mas não diz o porquê. Em alguns casos, o usuário pode achar isto confuso.
É uma boa ideia explicar ao usuário o porquê da necessidade das permissões
para o aplicativo antes de chamar <code>requestPermissions()</code>.
</p>
<p>
Por exemplo: um aplicativo de fotografia pode precisar usar serviços de localização
para poder marcar as fotos geograficamente. Um usuário normal pode não entender que uma foto
pode conter informações de localização e ficar confuso quando
o aplicativo de fotografia quiser saber a localização. Portanto, neste caso, é uma boa ideia o aplicativo explicar
ao usuário sobre este recurso <em>antes</em> de chamar
<code>requestPermissions()</code>.
</p>
<p>
Uma maneira de fazer isto é incorporar estas solicitações em um tutorial do aplicativo. O tutorial pode exibir cada um dos recursos
do aplicativo e, à medida que fizer isto,
pode também explicar quais permissões são necessárias. Por exemplo, o tutorial do aplicativo de fotografia
pode demonstrar os recursos de compartilhamento de fotos com os contatos e,
em seguida, dizer ao usuário que ele precisa fornecer as permissões
para que o aplicativo possa visualizar os contatos. O aplicativo pode então chamar <code>requestPermissions()</code> para solicitar
ao usuário este acesso. É claro que nem todos os usuários seguirão o tutorial.
Portanto, ainda é necessário verificar e solicitar as permissões durante
a operação normal do aplicativo.
</p>