1page.title=Permissões 2page.tags=previewresources, androidm 3page.keywords=permissions, runtime, preview 4page.image={@docRoot}preview/images/permissions_check.png 5@jd:body 6 7 8<div id="qv-wrapper"> 9 <div id="qv"> 10 <h2>Visualização rápida</h2> 11 <ul> 12 <li>Se o aplicativo direciona o M Preview SDK, ele indica aos usuários para conceder 13 permissões no tempo de execução, em vez de tempo de instalação.</li> 14 <li>Os usuários podem revogar as permissões a qualquer momento na tela de configurações 15do aplicativo.</li> 16 <li>O aplicativo precisa verificar se tem as permissões necessárias 17sempre que for executado.</li> 18 </ul> 19 20 <h2>Neste documento</h2> 21 <ol> 22 <li><a href="#overview">Visão geral</a></li> 23 <li><a href="#coding">Codificação para permissões de tempo de execução</a></li> 24 <li><a href="#testing">Teste de permissões de tempo de execução</a></li> 25 <li><a href="#best-practices">Práticas recomendadas</a></li> 26 </ol> 27 28<!-- 29 <h2>Related Samples</h2> 30 <ol> 31 <li></li> 32 </ol> 33--> 34 35<!-- 36 <h2>See also</h2> 37 <ol> 38 <li></li> 39 </ol> 40--> 41 </div> <!-- qv --> 42</div> <!-- qv-wrapper --> 43 44 45<p> 46 O M Developer Preview introduz um novo modelo de permissões de aplicativo 47que agiliza o processo de instalação e atualização de aplicativos para os usuários. Se um aplicativo 48 que está sendo executado no M Preview suporta o novo modelo de permissões, o usuário não precisa conceder 49 permissões ao instalar ou atualizar o aplicativo. Em vez disso, o aplicativo 50 solicita as permissões à medida que precisar e o sistema exibe um diálogo 51 ao usuário pedindo a permissão. 52</p> 53 54<p> 55 Se um aplicativo suportar o novo modelo de permissões, ele 56 ainda poderá ser instalado e executado em versões mais antigas do Android, usando o antigo modelo 57 de permissões nesses dispositivos. 58</p> 59 60<h2 id="overview"> 61 Visão geral 62</h2> 63 64<p> 65 Com o M Developer Preview, a plataforma introduz um novo modelo 66 de permissões. Eis um resumo dos componentes essenciais deste novo modelo: 67</p> 68 69<ul> 70 <li> 71 <strong>Declaração de permissões:</strong> O aplicativo declara todas 72 as permissões necessárias no manifesto, como nas plataformas anteriores do Android. 73 </li> 74 75 <li> 76 <strong>Grupos de permissão:</strong> As permissões são divididas em 77<em>grupos de permissão</em>, baseados na funcionalidade. Por exemplo: o grupo de permissão 78 <code>CONTACTS</code> contém permissões para ler e escrever 79 informações de perfil e contatos do usuário. 80 </li> 81 82 <li> 83 <p><strong>Permissões limitadas concedidas no tempo de instalação:</strong> Quando o usuário 84 instala ou atualiza o aplicativo, o sistema concede todas 85 as permissões que o aplicativo solicita que estão em {@link 86 android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}. 87 Por exemplo: as permissões de internet e despertador estão em {@link 88 android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}. Portanto, 89 as permissões são concedidas automaticamente no tempo de instalação. 90 </p> 91 92 <p>O sistema pode também conceder as permissões de sistema e assinatura de aplicativo, 93 como descrito em <a href="#system-apps">permissões de assinatura 94 e aplicativos do sistema</a>. O usuário <em>não</em> é alertado a conceder permissões 95 no tempo de instalação.</p> 96 </li> 97 98 <li> 99 <strong>O usuário concede permissões no tempo de execução:</strong> Quando um aplicativo solicita 100 uma permissão, o sistema exibe um diálogo ao usuário e, em seguida, 101 chama a função de retorno de chamada do aplicativo para notificá-lo se a permissão foi concedida. Se um 102 usuário concede uma permissão, o aplicativo recebe todas 103 as permissões na área funcional desta permissão que foram declaradas no manifesto do aplicativo. 104 </li> 105 106</ul> 107 108<p> 109 Este modelo de permissões altera a forma como o aplicativo se comporta diante os recursos 110 que precisam de permissões. Eis um resumo das práticas de desenvolvimento que devem 111 ser seguidas para ajustar para este modelo: 112</p> 113 114<ul> 115 116 <li> 117 <strong>Sempre verificar as permissões:</strong> Quando o aplicativo 118 precisa realizar uma ação que requer uma permissão, ele deve primeiro verificar 119 se já a tem. Caso não tenha, ele solicita 120 o concedimento desta permissão. 121 </li> 122 123 <li> 124 <strong>Lidar com falta de permissões dignamente:</strong> Se o aplicativo não 125 recebe a permissão adequada, ele deve lidar com a falha de forma limpa. 126 Por exemplo, se a permissão é necessária para um recurso adicionado, 127 o aplicativo pode desativar este recurso. Se a permissão for essencial 128 para que o aplicativo funcione, ele desativará toda sua funcionalidade 129 e informará ao usuário que precisa desta permissão. 130 </li> 131 132 <div class="figure" style="width:220px" id="fig-perms-screen"> 133 <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"> 134 <p class="img-caption"> 135 <strong>Figura 1.</strong> Tela de permissões nas configurações do aplicativo. 136 </p> 137 </div> 138 139 <li> 140 <strong>As permissões são revogáveis:</strong> Os usuários podem revogar as permissões 141 de um aplicativo a qualquer momento. Se um usuário desativar as permissões de um aplicativo, 142 o aplicativo <em>não</em> é notificado. Novamente, o aplicativo deve verificar 143 se tem todas as permissões necessárias antes de realizar qualquer ação restrita. 144 </li> 145</ul> 146 147<p class="note"> 148 <strong>Observação:</strong> se um aplicativo direcionar o M Developer Preview, ele 149 <em>deve</em> usar o novo modelo de permissões. 150</p> 151 152<p> 153 No momento do lançamento do M Developer Preview, 154 nem todos os aplicativos Google implementam completamente o novo modelo de permissões. A Google está atualizando estes aplicativos 155 durante o curso do M Developer Preview para respeitar adequadamente a configuração 156 de alternação de permissões. 157</p> 158 159<p class="note"> 160 <strong>Observação:</strong> se o aplicativo tiver a própria superfície de API, 161 não represente permissões sem antes garantir que o autor da chamada tenha as permissões necessárias 162 para acessar esses dados. 163</p> 164 165<h3 id="system-apps"> 166 Permissões de assinatura e aplicativos do sistema 167</h3> 168 169<p> 170 Geralmente, quando um usuário instala um aplicativo, o sistema somente fornece ao aplicativo o 171 {@link android.content.pm.PermissionInfo#PROTECTION_NORMAL 172 PROTECTION_NORMAL}. No entanto, sob algumas circunstâncias, o sistema concede 173 ao aplicativo mais permissões: 174</p> 175 176<ul> 177 <li>Se um aplicativo faz parte da imagem do sistema, ele recebe automaticamente 178 todas as permissões listadas no manifesto. 179 </li> 180 181 <li>Se o aplicativo solicitar as permissões no manifesto que está em {@link 182 android.content.pm.PermissionInfo#PROTECTION_SIGNATURE PROTECTION_SIGNATURE}, 183 e estiver assinado com o mesmo certificado que o aplicativo que declarou essas permissões, 184 o sistema concederá essas permissões na instalação ao aplicativo 185 que fez a solicitação. 186 </li> 187</ul> 188 189<p> 190 Em ambos os casos, o usuário ainda pode revogar as permissões a qualquer 191 momento acessando a tela de <strong>configurações</strong> do sistema e escolhendo <strong>Aplicativos 192 ></strong> <i>app_name</i> <strong>> Permissões</strong>. O aplicativo 193 deve continuar com a verificação das permissões no tempo de execução e solicitá-las 194 se necessário. 195</p> 196 197<h3 id="compatibility"> 198 Compatibilidade anterior e posterior 199</h3> 200 201<p> 202 Se um aplicativo não direciona para o M Developer Preview, ele deve continuar a usar 203 o modelo antigo de permissões mesmo nos dispositivos M Preview. Quando o usuário instala 204 o aplicativo, o sistema pede para que ele conceda todas as permissões 205 listadas no manifesto do aplicativo. 206</p> 207 208<p class="note"> 209 <strong>Observação:</strong> em dispositivos que são executados no M Developer Preview, 210 um usuário pode desativar as permissões para qualquer aplicativo (incluindo aplicativos de legado) 211 na tela de configurações do aplicativo. Se um usuário desativa as permissões de um aplicativo de legado, o sistema 212 silenciosamente desativa a funcionalidade adequada. Quando um aplicativo tentar realizar 213 uma operação que requer esta permissão, a operação não necessariamente causará 214 uma exceção. Em vez disso, ele retornará um conjunto de dados vazio, 215 sinalizará um erro ou exibirá um comportamento inesperado. Por exemplo, caso queira 216 consultar um calendário sem permissão, o método retorna um conjunto de dados vazio. 217</p> 218 219<p> 220 Se instalar um aplicativo usando o novo modelo de permissões em um dispositivo 221 que não está executando o M Preview, 222 o sistema o tratará da mesma forma que qualquer outro aplicativo: o sistema pedirá 223 para que o usuário conceda todas as permissões declaradas no momento da instalação. 224</p> 225 226<p class="note"> 227 <strong>Observação:</strong> para a liberação de prévia, deve-se definir a versão mínima de SDK 228 para o M Preview SDK para compilar com o SDK de prévia. Isto significa que você 229 não poderá testar tais aplicativos em plataformas mais antigas durante a prévia 230 de desenvolvedor. 231</p> 232 233<h3 id="perms-vs-intents">Permissões versus intenções</h3> 234 235<p> 236 Em vários casos, é possível escolher entre duas maneiras para que o aplicativo realize 237 uma tarefa. É possível fazer com que o aplicativo solicite uma permissão para realizar a operação 238 por conta própria. Alternativamente, é possível fazer com que o aplicativo use uma intenção para que outro aplicativo 239 realize a tarefa. 240</p> 241 242<p> 243 Por exemplo, imagine que o aplicativo precisa da função de tirar fotos com 244 a câmera do dispositivo. O aplicativo pode solicitar a permissão 245<code>android.permission.CAMERA</code>, que permite que ele acesse 246 a câmera diretamente. O aplicativo então usará as APIs da câmera 247 para controlar a câmera e tirar uma foto. Esta abordagem fornece ao aplicativo 248 controle completo sobre o processo de fotografia e permite 249 que você incorpore a IU da câmera. 250</p> 251 252<p> 253 No entanto, caso não precise de tal controle, é possível apenas usar uma intenção {@link 254 android.provider.MediaStore#ACTION_IMAGE_CAPTURE ACTION_IMAGE_CAPTURE} 255 para solicitar uma imagem. Ao iniciar a intenção, o usuário deve escolher 256 um aplicativo de câmera (se não houver um aplicativo padrão de câmera) 257 para tirar a foto. O aplicativo da câmera retorna a imagem ao método {@link 258 android.app.Activity#onActivityResult onActivityResult()} do aplicativo. 259</p> 260 261<p> 262 De forma semelhante, caso precise realizar uma ligação, 263 acessar os contatos do usuário etc., é possível fazer estas ações criando uma intenção adequada 264 ou solicitar a permissão e o acesso aos objetos adequados diretamente. Essas são 265 as vantagens e desvantagens de cada abordagem. 266</p> 267 268<p> 269 Se usar permissões: 270</p> 271 272<ul> 273 <li>O aplicativo tem controle completo sobre a experiência do usuário ao realizar 274 a operação. No entanto, esse controle amplo é adicionado à complexidade da tarefa, 275 levando em consideração a necessidade de projetar uma IU adequada. 276 </li> 277 278 <li>O usuário deve fornecer a permissão uma vez: na primeira realização 279 da operação. Depois, o aplicativo pode realizar a operação sem 280 precisar de mais interações do usuário. No entanto, 281 se o usuário não conceder a permissão (ou revogá-la posteriormente), 282 o aplicativo não conseguirá realizar a operação. 283 </li> 284</ul> 285 286<p> 287 Se usar uma intenção: 288</p> 289 290<ul> 291 <li>Você não terá que projetar a IU para a operação. O aplicativo que lida com 292 a intenção fornece a IU. No entanto, isso significa que você não terá controle 293 completo sobre a experiência de usuário. O usuário poderá interagir com um aplicativo 294 que você nunca viu. 295 </li> 296 297 <li>Se o usuário não tem um aplicativo padrão para a operação, 298 o sistema pede para que o usuário escolha um aplicativo. 299 Se o usuário não designar um manipulador padrão, 300 ele terá que acessar uma caixa de diálogo extra sempre que realizar a operação. 301 </li> 302</ul> 303 304<h2 id="coding">Codificação para permissões de tempo de execução</h2> 305 306<p> 307 Se um aplicativo direciona o novo M Developer Preview, ele deve usar o novo 308 modelo de permissões. Isto significa que, além de declarar as permissões necessárias no manifesto, 309 deve-se também verificar se o aplicativo 310 tem as permissões no tempo de execução e, 311 caso ainda não as tenha, solicitá-las. 312</p> 313 314<h3 id="enabling"> 315 Possibilitar um novo modelo de permissões 316</h3> 317 318<p> 319 Para possibilitar o modelo de permissões do M Developer Preview, configure o atributo 320<code>targetSdkVersion</code> do aplicativo para <code>"MNC"</code> e 321<code>compileSdkVersion</code> para <code>"android-MNC"</code>. Isto ativará 322 todos os novos recursos de permissão. 323</p> 324 325<p> 326 Para a liberação de uma prévia, deve-se definir <code>minSdkVersion</code> para 327<code>"MNC"</code> para compilar com o SDK de prévia. 328</p> 329 330<h3 id="m-only-perm"> 331 Designar uma permissão somente para o M Preview 332</h3> 333 334<p> 335 É possível usar o novo elemento <code><uses-permission-sdk-m></code> no manifesto do aplicativo 336 para indicar que uma permissão é necessária apenas no M Developer Preview. Se você 337 declarar uma permissão desta maneira, sempre que o aplicativo for instalado 338 em um dispositivo mais antigo, o sistema não solicitará ao usuário 339 nem concederá a permissão ao aplicativo. Usando o elemento <code><uses-permission-sdk-m></code> 340, é possível adicionar novas permissões 341 a versões atualizadas do aplicativo sem forçar os usuários a conceder permissões 342 ao instalar a atualização. 343</p> 344 345<p> 346 Se o aplicativo está sendo executado em um dispositivo com M Developer Preview, o 347<code><uses-permission-sdk-m></code> se comporta da mesma forma que 348<code><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code>. 349 O sistema não solicita ao usuário que conceda quaisquer permissões ao instalar o aplicativo 350 e o aplicativo solicita as permissões à medida que forem necessárias. 351</p> 352 353<h3 id="prompting"> 354 Solicitação de permissões 355</h3> 356 357<p> 358 Se o aplicativo usa o novo modelo de permissões do M Developer Preview, 359 o usuário não recebe solicitações para conceder todas as permissões quando o aplicativo é iniciado pela primeira vez em um dispositivo 360 que está sendo executado no M Preview. Em vez disso, o aplicativo solicita as permissões à medida 361 que forem necessárias. Quando um aplicativo solicita uma permissão, o sistema exibe uma caixa de diálogo 362 ao usuário. 363</p> 364 365<p> 366 Se o aplicativo executar em um dispositivo que tem SDK 22 ou inferior, 367 ele usará o antigo modelo de permissões. Quando o usuário instala o aplicativo, ele é solicitado a conceder 368 todas as permissões que o aplicativo lista no manifesto, 369 exceto as permissões que forem marcadas com <code><uses-permission-sdk-m></code>. 370</p> 371 372<h4 id="check-platform">Verifique em qual plataforma o aplicativo está sendo executado</h4> 373 374<p> 375 Este modelo de permissões é suportado apenas em dispositivos que estão executando 376 o M Developer Preview. Antes de chamar qualquer um destes métodos, 377 o aplicativo deve verificar em qual plataforma está sendo executado 378 verificando o valor de {@link android.os.Build.VERSION#CODENAME 379 Build.VERSION.CODENAME}. Se o dispositivo estiver sendo executado no M Developer Preview, 380 {@link android.os.Build.VERSION#CODENAME CODENAME} será <code>"MNC"</code>. 381</p> 382 383<h4 id="check-for-permission">Verifique se o aplicativo tem a permissão necessária</h4> 384 385<p>Quando o usuário tenta fazer algo que requer uma permissão, 386 o aplicativo verifica se tem a permissão para realizar esta operação. Para fazer isto, 387 o aplicativo chama 388 <code>Context.checkSelfPermission(<i>permission_name</i>)</code>. O aplicativo 389 deve realizar isto para verificar se sabe que o usuário já concedeu esta permissão, 390 levando em consideração que o usuário pode revogar 391 as permissões do aplicativo a qualquer momento. Por exemplo, 392 se um usuário quiser usar um aplicativo para tirar uma foto, o aplicativo chamará 393 <code>Context.checkSelfPermission(Manifest.permission.CAMERA)</code>.</p> 394 395<p class="table-caption" id="permission-groups"> 396 <strong>Tabela 1.</strong> Permissões e grupos de permissões.</p> 397<table> 398 <tr> 399 <th scope="col">Grupo de permissões</th> 400 <th scope="col">Permissões</th> 401 </tr> 402 403 <tr> 404 <td><code>android.permission-group.CALENDAR</code></td> 405 <td> 406 <ul> 407 <li> 408 <code>android.permission.READ_CALENDAR</code> 409 </li> 410 </ul> 411 <ul> 412 <li> 413 <code>android.permission.WRITE_CALENDAR</code> 414 </li> 415 </ul> 416 </td> 417 </tr> 418 419 <tr> 420 <td><code>android.permission-group.CAMERA</code></td> 421 <td> 422 <ul> 423 <li> 424 <code>android.permission.CAMERA</code> 425 </li> 426 </ul> 427 </td> 428 </tr> 429 430 <tr> 431 <td><code>android.permission-group.CONTACTS</code></td> 432 <td> 433 <ul> 434 <li> 435 <code>android.permission.READ_CONTACTS</code> 436 </li> 437 <li> 438 <code>android.permission.WRITE_CONTACTS</code> 439 </li> 440 <li> 441 <code>android.permission.READ_PROFILE</code> 442 </li> 443 <li> 444 <code>android.permission.WRITE_PROFILE</code> 445 </li> 446 </ul> 447 </td> 448 </tr> 449 450 <tr> 451 <td><code>android.permission-group.LOCATION</code></td> 452 <td> 453 <ul> 454 <li> 455 <code>android.permission.ACCESS_FINE_LOCATION</code> 456 </li> 457 <li> 458 <code>android.permission.ACCESS_COARSE_LOCATION</code> 459 </li> 460 </ul> 461 </td> 462 </tr> 463 464 <tr> 465 <td><code>android.permission-group.MICROPHONE</code></td> 466 <td> 467 <ul> 468 <li> 469 <code>android.permission.RECORD_AUDIO</code> 470 </li> 471 </ul> 472 </td> 473 </tr> 474 475 <tr> 476 <td><code>android.permission-group.PHONE</code></td> 477 <td> 478 <ul> 479 <li> 480 <code>android.permission.READ_PHONE_STATE</code> 481 </li> 482 <li> 483 <code>android.permission.CALL_PHONE</code> 484 </li> 485 <li> 486 <code>android.permission.READ_CALL_LOG</code> 487 </li> 488 <li> 489 <code>android.permission.WRITE_CALL_LOG</code> 490 </li> 491 <li> 492 <code>com.android.voicemail.permission.ADD_VOICEMAIL</code> 493 </li> 494 <li> 495 <code>android.permission.USE_SIP</code> 496 </li> 497 <li> 498 <code>android.permission.PROCESS_OUTGOING_CALLS</code> 499 </li> 500 </ul> 501 </td> 502 </tr> 503 504 <tr> 505 <td><code>android.permission-group.SENSORS</code></td> 506 <td> 507 <ul> 508 <li> 509 <code>android.permission.BODY_SENSORS</code> 510 </li> 511 </ul> 512 <ul> 513 <li> 514 <code>android.permission.USE_FINGERPRINT</code> 515 </li> 516 </ul> 517 </td> 518 </tr> 519 520 <tr> 521 <td><code>android.permission-group.SMS</code></td> 522 <td> 523 <ul> 524 <li> 525 <code>android.permission.SEND_SMS</code> 526 </li> 527 <li> 528 <code>android.permission.RECEIVE_SMS</code> 529 </li> 530 <li> 531 <code>android.permission.READ_SMS</code> 532 </li> 533 <li> 534 <code>android.permission.RECEIVE_WAP_PUSH</code> 535 </li> 536 <li> 537 <code>android.permission.RECEIVE_MMS</code> 538 </li> 539 <li> 540 <code>android.permission.READ_CELL_BROADCASTS</code> 541 </li> 542 </ul> 543 </td> 544 </tr> 545 546</table> 547 548<h4 id="request-permissions">Solicitar permissões se necessário</h4> 549 550<p>Se o aplicativo já não tem a permissão necessária, ele chama o método 551 <code>Activity.requestPermissions(String[], int)</code> para solicitar 552 as permissões necessárias. O aplicativo passa 553 as permissões que deseja e também um "código de solicitação" do inteiro. 554 Este método funciona de forma assíncrona: ele retorna imediatamente e, 555 depois que o usuário responde à caixa de diálogo, o sistema chama 556 o método de retorno de chamada do aplicativo com os resultados, passando o mesmo "código de solicitação" que o aplicativo passou 557 para <code>requestPermissions()</code>.</p> 558 559 <p>O seguinte código verifica se o aplicativo tem a permissão 560 para ler os contatos do usuário e solicita a permissão, se necessário:</p> 561 562<pre> 563if (checkSelfPermission(Manifest.permission.READ_CONTACTS) 564 != PackageManager.PERMISSION_GRANTED) { 565 requestPermissions(new String[]{Manifest.permission.READ_CONTACTS}, 566 MY_PERMISSIONS_REQUEST_READ_CONTACTS); 567 568 // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an 569 // app-defined int constant 570 571 return; 572} 573</pre> 574 575<h4 id="handle-response">Lidar com a resposta de solicitação das permissões</h4> 576 577<p> 578 Quando um aplicativo solicita as permissões, o sistema apresenta uma caixa de diálogo 579 ao usuário. Quando o usuário responde, o sistema invoca o 580 <code>Activity.onRequestPermissionsResult(int, String[], int[])</code> 581 do aplicativo, passando a ele a resposta do usuário. O aplicativo precisa substituir este método. O retorno de chamada 582 recebe o mesmo código de solicitação passado para 583 <code>requestPermissions()</code>. Por exemplo, se um aplicativo solicita o acesso 584 <code>READ_CONTACTS</code>, ele pode ter o seguinte 585 método de retorno de chamada: 586</p> 587 588<pre> 589@Override 590public void onRequestPermissionsResult(int requestCode, 591 String permissions[], int[] grantResults) { 592 switch (requestCode) { 593 case MY_PERMISSIONS_REQUEST_READ_CONTACTS: { 594 if (grantResults[0] == PackageManager.PERMISSION_GRANTED) { 595 596 // permission was granted, yay! do the 597 // calendar task you need to do. 598 599 } else { 600 601 // permission denied, boo! Disable the 602 // functionality that depends on this permission. 603 } 604 return; 605 } 606 607 // other 'switch' lines to check for other 608 // permissions this app might request 609 } 610} 611</pre> 612 613 <p>Se o usuário concede a permissão, o sistema fornece ao aplicativo todas as permissões 614 que o manifesto do aplicativo lista para esta área funcional. Se o usuário negar a solicitação, 615 deve-se tomar a ação adequada. Por exemplo, deve-se desativar 616 quaisquer ações de menu que dependam desta permissão. 617 </li> 618</p> 619 620<p> 621 Quando o sistema pede para que o usuário conceda uma permissão, esse usuário tem a opção 622 de dizer ao sistema para que não peça esta permissão novamente. Nesse caso, 623 quando um aplicativo usa <code>requestPermissions()</code> para solicitar esta permissão, 624 o sistema nega imediatamente. Neste caso, o sistema chama 625 <code>onRequestPermissionsResult()</code> da mesma forma que faria se o usuário tivesse 626 rejeitado explicitamente a solicitação novamente. Por este motivo, o aplicativo 627 não pode presumir que uma interação direta com o usuário ocorreu. 628</p> 629 630<h2 id="testing">Teste de permissões de tempo de execução</h2> 631 632 633<p> 634 Se o aplicativo for direcionado para o M Developer Preview, deve-se testar 635 se ele lida com as permissões corretamente. Não se pode presumir que o aplicativo 636 terá qualquer permissão quando executado. Quando o aplicativo é iniciado pela primeira vez, 637 é provável que não tenha permissões. O usuário pode revogar e restaurar permissões 638 a qualquer momento. 639</p> 640 641<p> 642 Deve-se testar o aplicativo para garantir que ele se comporte corretamente em todas 643 as situações de permissão. Com o M Preview SDK, fornecemos os novos comandos 644 de <a href="{@docRoot}tools/help/adb.html">Android 645 Debug Bridge (adb)</a> para possibilitar que o aplicativo seja testado com quaisquer 646 configurações de permissões necessárias. 647</p> 648 649<h3> 650 Novas opções e comandos adb 651</h3> 652 653<p> 654 As ferramentas da plataforma M Preview SDK fornecem vários comandos novos para permitir 655 que você teste como o aplicativo lida com permissões. 656</p> 657 658<h4> 659 Instalar com permissões 660</h4> 661 662<p> 663 É possível usar a nova opção <code>-g</code> do comando <a href="{@docRoot}tools/help/adb.html#move"><code>adb 664 install</code></a>, que instala o aplicativo 665 e fornece todas as permissões listadas em seu manifesto: 666</p> 667 668<pre class="no-pretty-print"> 669$ adb install -g <path_to_apk> 670</pre> 671 672<h4> 673 Conceder e revogar permissões 674</h4> 675 676<p> 677 É possível usar os novos comandos do <a href="{@docRoot}tools/help/adb.html#pm">gerenciador 678 de pacotes (pm)</a> de ADB para conceder e revogar as permissões de um aplicativo instalado. 679 Esta funcionalidade pode ser útil para testes automatizados. 680</p> 681 682<p> 683 Para conceder uma permissão, use o comando <code>grant</code> do gerenciador de pacote: 684</p> 685 686<pre class="no-pretty-print"> 687$ adb pm grant <package_name> <permission_name> 688</pre> 689 690<p> 691 Por exemplo: para conceder a permissão do pacote com.example.myapp para gravar áudios, 692 use este comando: 693</p> 694 695<pre class="no-pretty-print"> 696$ adb pm grant com.example.myapp android.permission.RECORD_AUDIO 697</pre> 698 699<p> 700 Para revogar uma permissão, use o comando <code>revoke</code> do gerenciador de pacote: 701</p> 702 703<pre class="no-pretty-print"> 704$ adb pm revoke <package_name> <permission_name> 705</pre> 706 707<h2 id="best-practices">Práticas recomendadas</h2> 708 709<p> 710 O novo modelo de permissões fornece aos usuários uma experiência mais suave 711 e facilita a instalação de aplicativos, deixando-os mais confortáveis 712 com o que os aplicativos estão fazendo. Sugerimos que você siga as práticas recomendadas para aproveitar 713 todas as vantagens do novo modelo. 714</p> 715 716 717<h3 id="bp-what-you-need">Peça somente as permissões necessárias</h3> 718 719<p> 720 Sempre que você pede uma permissão, o usuário é forçado a tomar uma decisão. 721 Se o usuário negar a solicitação, a funcionalidade do aplicativo será reduzida. 722 Deve-se minimizar o número de solicitações realizadas. 723</p> 724 725<p> 726 Por exemplo: o aplicativo pode frequentemente adquirir a funcionalidade necessária usando 727 uma <a href="{@docRoot}guide/components/intents-filters.html">intenção</a> em vez 728 de solicitar permissões. Se o aplicativo precisa tirar fotos com a câmera do telefone, 729 é possível usar uma intenção {@link 730 android.provider.MediaStore#ACTION_IMAGE_CAPTURE 731 MediaStore.ACTION_IMAGE_CAPTURE}. Quando o aplicativo executa a intenção, 732 o sistema pede para que o usuário escolha um aplicativo de câmera já instalado 733 para tirar a foto. 734</p> 735 736<h3 id="bp-dont-overwhelm"> 737 Não oprima o usuário 738</h3> 739 740<p> 741 Se você confrontar o usuário com várias solicitações de permissão de uma só vez, 742 é possível que ele se sinta oprimido e saia do aplicativo. 743 Em vez disso, deve-se solicitar as permissões somente quando necessário. 744</p> 745 746<p> 747 Em alguns casos, uma ou mais permissões podem ser absolutamente essenciais para o aplicativo. 748 Nesta situação, faz sentido solicitar todas as permissões assim 749 que o aplicativo é iniciado. Por exemplo: se você fizer um aplicativo de fotografia, 750 ele precisará de acesso à câmera do dispositivo. Quando o usuário iniciar o aplicativo 751 pela primeira vez, ele não se surpreenderá quando receber 752 uma solicitação de permissão para usar a câmera. Mas, se o mesmo aplicativo tiver um recurso 753 para compartilhar fotos com os contatos do usuário, <em>não</em> se deve 754 pedir esta permissão na primeira inicialização. Em vez disso, espere o usuário tentar usar 755 o recurso de compartilhamento para pedir a permissão. 756</p> 757 758<p> 759 Se o aplicativo fornecer um tutorial, faz sentido solicitar as permissões 760 necessárias no final da sequência do tutorial. 761</p> 762 763<h3 id="bp-explain"> 764 Explique o porquê da necessidade das permissões 765</h3> 766 767<p> 768 O diálogo de permissões exibido pelo sistema ao chamar 769 <code>requestPermissions()</code> diz quais permissões o aplicativo requer, 770 mas não diz o porquê. Em alguns casos, o usuário pode achar isto confuso. 771 É uma boa ideia explicar ao usuário o porquê da necessidade das permissões 772 para o aplicativo antes de chamar <code>requestPermissions()</code>. 773</p> 774 775<p> 776 Por exemplo: um aplicativo de fotografia pode precisar usar serviços de localização 777 para poder marcar as fotos geograficamente. Um usuário normal pode não entender que uma foto 778 pode conter informações de localização e ficar confuso quando 779 o aplicativo de fotografia quiser saber a localização. Portanto, neste caso, é uma boa ideia o aplicativo explicar 780 ao usuário sobre este recurso <em>antes</em> de chamar 781 <code>requestPermissions()</code>. 782</p> 783 784<p> 785 Uma maneira de fazer isto é incorporar estas solicitações em um tutorial do aplicativo. O tutorial pode exibir cada um dos recursos 786 do aplicativo e, à medida que fizer isto, 787 pode também explicar quais permissões são necessárias. Por exemplo, o tutorial do aplicativo de fotografia 788 pode demonstrar os recursos de compartilhamento de fotos com os contatos e, 789 em seguida, dizer ao usuário que ele precisa fornecer as permissões 790 para que o aplicativo possa visualizar os contatos. O aplicativo pode então chamar <code>requestPermissions()</code> para solicitar 791 ao usuário este acesso. É claro que nem todos os usuários seguirão o tutorial. 792 Portanto, ainda é necessário verificar e solicitar as permissões durante 793 a operação normal do aplicativo. 794</p> 795