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>