diff --git a/docs/html-intl/intl/pt-br/preview/backup/index.jd b/docs/html-intl/intl/pt-br/preview/backup/index.jd new file mode 100644 index 0000000000000..1ba039bc0f617 --- /dev/null +++ b/docs/html-intl/intl/pt-br/preview/backup/index.jd @@ -0,0 +1,327 @@ +page.title=Backup automático para aplicativos +page.tags=backup, previewresources, androidm +page.keywords=backup, autobackup, preview +page.image=images/cards/card-auto-backup_2x.png +@jd:body + +
+ Frenquentemente, os usuários investem muito tempo e esforço para criar dados e configurar preferências + nos aplicativos. Preservar esses dados para os usuários caso substituam um dispositivo quebrado ou atualizem-se para um novo + é importante para garantir uma ótima experiência de usuário. Dispositivos que executam o sistema Android M Preview + ajudam a garantir uma boa experiência para os usuários nessas circunstâncias realizando o backup dos dados do aplicativo + automaticamente no Google Drive. Os dados do aplicativo são restaurados automaticamente se um usuário alterar ou atualizar um + dispositivo. +
+ ++ Os backups automáticos estão ativos para todos os aplicativos instalados nos dispositivos que executam o Android M Preview. Nenhum + código adicional de aplicativo é necessário. O sistema fornece aos usuários a habilidade de decisão + sobre os backups automáticos de dados. Também é possível limitar quais dados do aplicativo devem ter o backup. +
+ ++ Este documento descreve o novo comportamento do sistema e como especificar quais dados terão backup + para o aplicativo. +
+ ++ O recurso de backup automático preserva os dados que o aplicativo cria em um dispositivo de usuário enviando-os + à conta do Google Drive do usuário e criptografando-os. Não há cobranças para você ou para o usuário + em relação ao armazenamento de dados e os dados salvos não contam para a cota do Drive pessoal do usuário. Durante + o período do M Preview, os usuários podem armazenar até 25 MB por aplicativo do Android. +
+ ++ Os backups automáticos ocorrem a cada 24 horas, quando o dispositivo está ocioso, carregando e conectado + a uma rede Wi-Fi. Quando esses requisitos são atendidos, o serviço Backup Manager envia todos os dados de backup + disponíveis à nuvem. Quando um usuário transita para um novo dispositivo, ou desinstala e reinstala + o aplicativo com backup realizado, uma operação de restauração copia os dados de backup para o diretório de dados + do aplicativo recém-instalado. +
+ ++ Observação: se o usuário usar o + serviço de Backup do Android de legado, este novo comportamento + não se aplicará aos trabalhos de comportamento de backup existentes com o normal. +
+ + ++ Nem todos os dados do aplicativo devem ter backup, como arquivos temporários e de armazenamento em cachê. Portanto, o serviço de backup automático + exclui determinados arquivos de dados por padrão: +
+ ++ Os dados criados por qualquer aplicativo instalado em um dispositivo M Preview têm backup, exceto + os arquivos excluídos automaticamente listados na seção anterior. É possível limitar e configurar + quais dados terão backup no seu aplicativo usando as configurações no manifesto do aplicativo. +
+ ++ Dependendo de quais dados o aplicativo precisar e do modo que forem salvos, você precisará definir + regras específicas para incluir ou excluir determinados arquivos ou diretórios. O serviço de backup automático suporta + a configuração dessas regras de backup por meio do uso de um arquivo de configuração XML e do + manifesto do aplicativo. No manifesto do aplicativo, é possível especificar o arquivo de configuração de esquema de backup como exibido + no seguinte exemplo: +
+ ++<?xml version="1.0" encoding="utf-8"?> +<manifest xmlns:android="http://schemas.android.com/apk/res/android" + xmlns:tools="http://schemas.android.com/tools" + package="com.my.appexample"> + <uses-sdk android:minSdkVersion="MNC"/> + <uses-sdk android:targetSdkVersion="MNC"/> + <app ... + android:fullBackupContent="@xml/mybackupscheme"> + </app> + ... +</manifest> ++ +
+ Neste código de exemplo, o atributo android:fullBackupContent especifica um arquivo XML,
+ localizado no diretório res/xml/ do projeto de desenvolvimento do aplicativo, chamado
+ mybackupscheme.xml. Este arquivo de configuração inclui as regras de quais arquivos terão
+ backup. O seguinte código de exemplo mostra um arquivo de configuração que exclui um arquivo específico
+ dos backups:
+
+<?xml version="1.0" encoding="utf-8"?> +<full-backup-content> + <exclude domain="database" path="device_info.db"/> +</full-backup-content> ++ +
+ Esta configuração de backup de exemplo exclui do backup somente um arquivo específico do banco de dados. + Todos os outros arquivos terão backup. +
+ ++ A configuração do serviço de backup permite que você especifique quais arquivos incluir ou excluir do +backup. A sintaxe para o arquivo XML de configuração de backup de dados é a seguinte: +
+ ++<full-backup-content> + <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" /> + <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" /> +</full-backup-content> ++ +
+ Os seguintes elementos e atributos permitem que você especifique os arquivos que serão incluídos ou excluídos + do backup: +
+ +<include>. Use este elemento se quiser especificar um conjunto de recursos
+para o backup, em vez de fazer o sistema realizar o backup de todos os dados no aplicativo por padrão. Ao especificar
+ uma tag <include>, o sistema realiza apenas o backup dos recursos especificados
+ com este elemento.
+ <exclude>. Use este elemento para especificar um conjunto de recursos que será excluído
+ do backup. O sistema realiza o backup de todos os dados no aplicativo, exceto os recursos especificados
+ com este elemento.
+ domain. O tipo de recurso que deseja excluir ou incluir no backup. Os valores válidos
+ que podem ser especificados para este atributo incluem:
+ root. Especifica que o recurso está no diretório raiz do aplicativo.
+ file. Corresponde ao recurso no diretório retornado
+ pelo método {@link android.content.Context#getFilesDir getFilesDir()}.
+ database. Corresponde ao banco de dados retornado
+ pelo método {@link android.content.Context#getDatabasePath getDatabasePath()} ou usando
+ a classe {@link android.database.sqlite.SQLiteOpenHelper}.
+ sharedpref. Corresponde a um objeto {@link android.content.SharedPreferences}
+ retornado pelo método {@link android.content.Context#getSharedPreferences getSharedPreferences()}
+.
+ external. Especifica que o recurso está no armazenamento externo e corresponde
+ a um arquivo no diretório retornado pelo método
+ {@link android.content.Context#getExternalFilesDir getExternalFilesDir()}.
+ path. O caminho de arquivo para um recurso que deseja excluir ou incluir
+ no backup.
+
+ É possível optar por evitar backups automáticos de quaisquer dados do aplicativo configurando
+ o atributo android:allowBackup para false no elemento do aplicativo
+ do manifesto. Esta configuração é ilustrada no seguinte código de exemplo:
+
+<?xml version="1.0" encoding="utf-8"?> +<manifest xmlns:android="http://schemas.android.com/apk/res/android" + xmlns:tools="http://schemas.android.com/tools" + package="com.my.appexample"> + <uses-sdk android:minSdkVersion="MNC"/> + <uses-sdk android:targetSdkVersion="MNC"/> + <app ... + android:allowBackup="false"> + </app> + ... +</manifest> ++ + +
+ Ao criar uma configuração de backup, deve-se testá-la para garantir que o aplicativo + salva os dados e que eles podem ser restaurados corretamente. +
+ + ++ Para ajudar a determinar como o recurso de backup analisa o arquivo XML, ative o registro + antes de realizar um backup de teste: +
+ ++$ adb shell setprop log.tag.BackupXmlParserLogging VERBOSE ++ +
Para executar um backup manualmente, primeiro deve-se inicializar o Backup Manager chamando o seguinte + comando: +
+ ++$ adb shell bmgr run ++ +
+ Em seguida, realiza-se o backup manualmente do aplicativo usando o seguinte comando, especificando o nome
+ do pacote para o aplicativo como o parâmetro <PACKAGE>:
+
+$ adb shell bmgr fullbackup <PACKAGE>+ + +
+ Para iniciar manualmente uma restauração após o backup dos dados do aplicativo, chame o seguinte comando,
+ especificando o nome do pacote para o aplicativo como o parâmetro <PACKAGE>:
+
+$ adb shell bmgr restore <PACKAGE> ++ +
+ Aviso: esta ação impede o aplicativo de apagar os dados antes de realizar + a operação de restauração. +
+ ++ Para iniciar o processo de restauração do aplicativo, deve-se desinstalar e reinstalá-lo. Os dados + do aplicativo são restaurados automaticamente a partir da nuvem quando a instalação do aplicativo for concluída. +
+ + ++ Caso ocorra problemas, é possível apagar os dados de backup e os metadados associados desativando o backup + e reativando-o em Settings (Configurações) > Backup, redefinindo o dispositivo para as especificações de fábrica, ou + chamando este comando: +
+ +$ adb shell bmgr wipe <TRANSPORT> <PACKAGE>+ +
+ O valor <TRANSPORT> deve ser prefixado por com.google.android.gms.
+ Para obter uma lista de transportes, chame o seguinte comando:
+
$ adb shell bmgr list transports+ +
A seguir estão os problemas conhecidos com o serviço de backup automático:
+ ++ O Android M Preview SDK inclui ferramentas de desenvolvimento, arquivos de sistema do Android e arquivos da biblioteca + para ajudar você a testar o aplicativo e novas APIs da próxima versão da plataforma. Este documento + descreve como adquirir os componentes disponíveis para download da prévia para o teste do aplicativo. +
+ + ++ O Preview SDK está disponível para download no Android SDK Manager. Para obter mais informações + sobre o download e a configuração do Preview SDK, consulte Configuração do Preview SDK. +
+ + ++ O pacote de download da documentação do desenvolvedor fornece informações de referência de API detalhadas e um relatório de diferença de API para a prévia. +
+ +| Descrição | +Download / Somas de verificação | +
|---|---|
| Android M Preview Documentações do desenvolvedor |
+ m-preview-1-developer-docs.zip + MD5: b65201b0d35416f5a1b7a071b52854a7 + SHA-1: d47e856aa65e06897e6edd902ad8d2b1f05ac3ec + |
+
| Dispositivo | +Download / Somas de verificação | +
|---|---|
| Nexus 5 (GSM/LTE) "hammerhead" |
+ hammerhead-MPZ44Q-preview-55d76d3a.tgz + MD5: 9e2631b06c6525e401ceaae3677ff320 + SHA-1: 55d76d3a379b18f3363f28d8a462c236ab96fc36 + |
+
| Nexus 6 "shamu" |
+ shamu-MPZ44Q-preview-c1d6506a.tgz + MD5: 307cbf9dab0a38df4ab2639d02be12aa + SHA-1: c1d6506a74094bdb2f4b8677c7fe4967334f9ea8 + |
+
| Nexus 9 "volantis" |
+ volantis-MPZ44Q-preview-d15ad483.tgz + MD5: fae40377fd999d2b09128665c915264d + SHA-1: 7ab05f96093b2cb370b226f65931202714cbc2ca + |
+
| Nexus Player "fugu" |
+ fugu-MPZ44Q-preview-2406ba05.tgz + MD5: 815902141a85cc65e7725f005cad31d5 + SHA-1: 2406ba0598dea1e69110497ac0bc8e16789bc8fb + |
+
+ Para usar uma imagem de dispositivo para testes, deve-se instalá-lo em um dispositivo compatível. Siga + as instruções abaixo para instalar uma imagem de sistema. +
+ ++ Observação: ao programar em flash a imagem do sistema de prévia no dispositivo de desenvolvimento, + ele é atualizado automaticamente com o próximo lançamento da prévia por meio de atualizações over-the-air (OTA). +
+ ++ Caso queira desinstalar a prévia e reverter o dispositivo para as especificações de fábrica, acesse + developers.google.com/android e + faça o download da imagem que deseja programar em flash no dispositivo. Siga as instruções nesta página + para programar em flash a imagem no dispositivo. +
+ + + + + + + + diff --git a/docs/html-intl/intl/pt-br/preview/features/app-linking.jd b/docs/html-intl/intl/pt-br/preview/features/app-linking.jd new file mode 100644 index 0000000000000..17a9896136196 --- /dev/null +++ b/docs/html-intl/intl/pt-br/preview/features/app-linking.jd @@ -0,0 +1,123 @@ +page.title=Links de aplicativos +page.image=images/cards/card-app-linking_2x.png +page.keywords=applinking, deeplinks, intents +@jd:body + ++ O sistema de intenções do Android é um mecanismo flexível para possibilitar que aplicativos lidem com conteúdos e solicitações. + Vários aplicativos podem declarar padrões de URI correspondentes em seus filtros de intenções. Quando um usuário clica em um + link da web que não tem um manipulador de inicialização padrão, a plataforma pode exibir um diálogo para + o usuário selecionar entre uma lista de aplicativos que declararam filtros de intenções correspondentes. +
+ ++ O Android M Developer Preview introduz suporte para links de aplicativos, que aprimora + a manipulação de links existentes, permitindo que desenvolvedores de aplicativos associem um aplicativo a um domínio da web pertencente a eles. Quando + os desenvolvedores criam esta associação, a plataforma pode automaticamente determinar o aplicativo padrão usado + para lidar com um link da web particular e ignorar a solicitação aos usuários. +
+ + ++ Os donos de sites da web devem declarar as associações aos aplicativos para estabelecer um link de aplicativo. O dono do site + declara a relação com um aplicativo hospedando um arquivo JSON chamado {@code statements.json} no + local bem conhecido no domínio: +
+ +http://<domain>:<optional port>/.well-known/statements.json+ +
+ Observação: + durante o período do M Developer Preview, o arquivo JSON é verificado por meio de protocolo http. Para + o lançamento oficial da plataforma, o arquivo é verificado com o protocolo http criptografado. +
+ ++ Este arquivo JSON indica o aplicativo do Android que deve ser usado como o manipulador padrão para URLs + neste domínio. Ele identifica o aplicativo com base nestes campos: +
+ +keytool -list -v -keystore my-release-key.keystore+
+ A seguinte lista de arquivos exibe um exemplo de conteúdo e formato + de um arquivo {@code statements.json}: +
+ +
+[{
+ "relation": ["delegate_permission/common.handle_all_urls"],
+ "target": {
+ "namespace": "android_app",
+ "package_name": "<package name>",
+ "sha256_cert_fingerprints": ["6C:EC:C5:0E:34:AE....EB:0C:9B"]
+ }
+}]
+
+
+
++ Um aplicativo pode solicitar que a plataforma verifique automaticamente quaisquer links de aplicativo relacionados aos arquivos {@code statements.json} + hospedados nos respectivos domínios da web que são definidos pelos nomes de host + nos elementos de dados dos seus filtros de intenções. Para solicitar a verificação de link de aplicativo, adicione um atributo {@code android:autoVerify} + a cada filtro de intenção desejado no manifesto, como exibido no seguinte fragmento + de código do manifesto: +
+ ++<activity ...> + <intent-filter android:autoVerify="true"> + <action android:name="android.intent.action.VIEW" /> + <category android:name="android.intent.category.DEFAULT" /> + <category android:name="android.intent.category.BROWSABLE" /> + <data android:scheme="http" android:host="www.android.com" /> + <data android:scheme="https" android:host="www.android.com" /> + </intent-filter> +</activity> ++ +
+ Quando o atributo {@code android:autoVerify} está presente em um manifesto do aplicativo, a plataforma + tenta verificar os links do aplicativo quando o aplicativo é instalado. Se a plataforma não conseguir + verificar os links do aplicativo, o aplicativo não será definido como o aplicativo preferencial para lidar com os links da web. Na próxima vez + que um usuário tentar abrir um dos links, a plataforma voltará a apresentar ao usuário + uma caixa de diálogo. +
+ ++ Observação: no teste, há chances de ocorrer um falso positivo se a verificação + falhar, mas o usuário explicitamente permitiu que o aplicativo abrisse links sem solicitar, usando + o aplicativo do sistema Settings (Configurações). Neste caso, nenhum diálogo é exibido e o link vai direto para o + aplicativo, mas somente devido à configuração do usuário, e não porque a verificação foi bem-sucedida. +
+ + ++ Os usuários podem alterar as configurações de link de aplicativo para que os URLs sejam tratados da maneira que preferirem. É possível revisar e + gerenciar os links de aplicativo no aplicativo Settings (Configurações) do sistema, em Settings (Configurações) > Apps (Aplicativos) > App Info (Informações do aplicativo) > + Open by default (Abrir por padrão). +
diff --git a/docs/html-intl/intl/pt-br/preview/index.jd b/docs/html-intl/intl/pt-br/preview/index.jd new file mode 100644 index 0000000000000..1e0252ffcf896 --- /dev/null +++ b/docs/html-intl/intl/pt-br/preview/index.jd @@ -0,0 +1,67 @@ +page.title=Android M Developer Preview +page.tags="preview", +meta.tags="preview, M preview", androidm +fullpage=true +section.landing=true +header.hide=1 +footer.hide=1 +@jd:body + + + ++Para começar a usar o Android SDK Preview, você deve concordar com os seguintes termos e condições. +Como descrito abaixo, observe que isto é uma versão de prévia do Android SDK, sujeita a alterações, que deve ser usada a seu risco. O Android SDK Preview não é uma versão estável e pode conter erros e defeitos que podem resultar em danos sérios aos sistemas de computador, aos dispositivos e aos dados. +
+ ++Este é o contrato de licença do Android SDK Preview (o “Contrato de Licença”). +
++ Os seguintes exemplos de código são fornecidos para o M Developer Preview. Para fazer o download + dos exemplos no Android Studio, selecione a opção do menu File (Arquivo) > Import Samples (Importar exemplos). +
+ ++ Observação: estes projetos disponíveis para download foram feitos +para serem usados com Gradle e Android Studio. +
+ + ++ O Android M altera a maneira como as permissões do sistema funcionam. Os usuários são solicitados a aprovar + as permissões em tempo de execução em vez de aprovar durante a instalação. Este exemplo mostra como solicitar + essas permissões. +
+ + + ++ Este exemplo demonstra como usar as credenciais do dispositivo como um método de autenticação no aplicativo. +
+ + + ++ Este exemplo demonstra como reconhecer as impressões digitais registradas para autenticar o usuário + no aplicativo. +
+ + + ++ O Android M introduz o backup automático para as configurações de aplicativos. Este exemplo demonstra como adicionar + regras de filtro a um aplicativo para gerenciar o backup de configurações. +
+ + + +
+ Demonstra como usar a API Camera2 API para capturar buffers de câmera RAW e salvá-los
+ como arquivos DNG.
+
+ Este exemplo demonstra como o
+ NotificationManager
+ pode dizer quantas notificações o aplicativo está exibindo.
+
O M Developer Preview SDK está disponível a partir do Android SDK Manager. +Este documento assume que você está familiarizado com o desenvolvimento de aplicativos do Android, +como o uso do Android SDK Manager e criação de projetos. Caso seja novo no +Android, consulte a lição de treinamento Como criar o primeiro +aplicativo primeiro.
+ +A prévia de desenvolvedor é melhor usada com o Android Studio 1.3, que está no estado +de prévia. É altamente recomendado que você instale a versão de prévia +do Android Studio 1.3 para que funcione com o Preview SDK.
+ +Cuidado: a prévia canário do Android +Studio 1.3 ainda está em desenvolvimento ativo. Caso esteja usando a máquina de desenvolvimento principal +para testar a prévia de desenvolvedor, é possível criar uma segunda instalação +do Android Studio para usar em testes.
+ +Para instalar a prévia do Android Studio 1.3:
+ +No OSX, é possível encontrar o painel Appearance & + Behavior (Aparência e comportamento) + na janela Preferences (Preferências) do Android Studio.
+Para adicionar os componentes do Preview SDK ao ambiente de desenvolvimento:
+ +No OSX, é possível encontrar o painel Appearance & + Behavior (Aparência e comportamento) + na janela Preferences (Preferências) do Android Studio.
+Após concluir estas etapas, os componentes de prévia estarão disponíveis + no ambiente de desenvolvimento.
+ + ++ Para usar as APIs de prévia, deve-se criar ou atualizar um projeto de desenvolvimento para usar + os componentes de prévia. +
+ + ++ Recomendamos o uso do Android Studio para criar um projeto com a prévia. Siga as etapas + descritas em Criar um projeto + até chegar na tela Form Factors (Novas especificações) no assistente do projeto. Em seguida, + realize as seguintes etapas para criar um projeto configurado para a prévia. +
+ +
+ Para projetos existentes, deve-se modificar a configuração de projeto para ativar as APIs de prévia. No
+ ambiente de desenvolvimento, abra o arquivo build.gradle para o módulo
+ e defina estes valores da seguinte forma:
+
compileSdkVersion para 'android-MNC'minSdkVersion para 'MNC'targetSdkVersion para 'MNC'+ Testar um aplicativo com a prévia requer que você tenha um dispositivo ou dispositivo virtual configurado + com a versão de prévia da plataforma. Caso tenha um dispositivo compatível, é possível instalar a plataforma + de prévia para teste. Caso contrário, é possível configurar um dispositivo virtual para o teste. +
+ ++ Caso tenha um Nexus 5, Nexus 6, Nexus 9 ou Android TV, é possível instalar uma imagem do sistema + de prévia nestes dispositivos para testar o aplicativo. + É possível configurar um dispositivo virtual com a versão de prévia da plataforma a partir do Android Studio + usando a ferramenta Android Virtual Device Manager. +
+ ++ Importante: instalar uma imagem de prévia em um dispositivo remove todos os dados + dele. Portanto, deve-se realizar o backup de quaisquer dados antes de instalar uma imagem de prévia. +
+ ++ É possível configurar um dispositivo virtual com a versão de prévia da plataforma dentro do Android Studio + usando a ferramenta Android Virtual Device Manager. +
+ +Para criar um AVD com o AVD Manager:
+ ++ Para obter mais informações sobre como criar dispositivos virtuais para teste, consulte Gerenciamento de dispositivos virtuais. +
diff --git a/docs/html-intl/intl/pt-br/preview/support.jd b/docs/html-intl/intl/pt-br/preview/support.jd new file mode 100644 index 0000000000000..63b88a75e8c68 --- /dev/null +++ b/docs/html-intl/intl/pt-br/preview/support.jd @@ -0,0 +1,67 @@ +page.title=Suporte +page.image=images/cards/card-support_16-9_2x.png + +@jd:body + ++ Caso tenha encontrado erros ou tenha feedback sobre o M Developer Preview, + crie um problema + em nosso issue tracker. +
+ ++ Para obter mais auxílio, junte-se à comunidade + M Developer + Preview do Google+ para discutir suas experiências de desenvolvimento. +
+ +
+
M Developer Preview, revisão 1 (maio de 2015)
+
+ O Android M Developer Preview fornece uma oportunidade de garantir que os aplicativos funcionem + na próxima versão da plataforma. Esta prévia inclui um número de mudanças de comportamento e APIs que podem + ter impacto no aplicativo, como descrito em Visão geral da API + e Mudanças de comportamento. No teste + do aplicativo com a prévia, há algumas alterações de sistema específicas em que você deve se concentrar + para garantir que os usuários tenham uma boa experiência. +
+ ++ Este guia descreve quais recursos de prévia testar e como testá-los com o aplicativo. Você deve + priorizar o teste destes recursos de prévia específicos, devido ao grande impacto potencial no + comportamento do aplicativo: +
+ ++ Para obter mais informações sobre como configurar dispositivos físicos ou virtuais com uma imagem do sistema de prévia + para teste, consulte Configuração do Preview SDK. +
+ + ++ O novo modelo de permissões + altera a maneira que as permissões são alocadas ao aplicativo pelo usuário. Em vez de conceder todas as permissões + durante o procedimento de instalação, o aplicativo deve pedir ao usuário permissões individuais + em tempo de execução. Para os usuários, este comportamento fornece um controle mais granular sobre as atividades de cada aplicativo, bem + como um melhor contexto para entender o porquê do aplicativo estar solicitando uma permissão específica. Os usuários + podem conceder ou revogar as permissões concedidas a um aplicativo individualmente a qualquer momento. É provável que este recurso + da prévia tenha um impacto no comportamento do aplicativo e pode impedir que alguns + dos recursos do aplicativo funcionem, ou funcionem em um estado degradado. +
+ ++ Esta alteração afeta todos os aplicativos em execução na nova plataforma, mesmo aqueles que não são destinados + para a versão nova da plataforma. A plataforma fornece um comportamento de compatibilidade limitado para aplicativos legados. No entanto, + você deve começar a planejar a migração do aplicativo para o novo modelo de permissões agora, com o objetivo + de publicar uma versão atualizada do aplicativo no lançamento oficial da plataforma. +
+ + ++ Use as seguintes dicas de teste para ajudar você a planejar e executar os testes do aplicativo com o novo + comportamento de permissões. +
+ +adb shell pm list permissions -d -g+
adb shell pm [grant|revoke] <permission.name> ...+
+ A mudança de permissões afeta a estrutura e o projeto do aplicativo, bem como + a experiência dos usuários e os fluxos fornecidos a eles. Você deve avaliar o uso das permissões atuais + do aplicativo e começar a planejar novos fluxos que deseja oferecer. O lançamento oficial + da plataforma fornece comportamento de compatibilidade, mas deve-se planejar a atualização do aplicativo e + não confiar nestes comportamentos. +
+ ++ Identifique as permissões que o aplicativo realmente precisa e usa e, em seguida, encontre os vários caminhos + de código que usam os serviços protegidos por permissões. É possível fazer isto por meio de uma combinação de + testes na nova plataforma e análise de códigos. Nos testes, você deve se concentrar em usar + as permissões em tempo de execução alterando {@code targetSdkVersion} do aplicativo para a versão da prévia. Para + obter mais informações, consulte Configuração do Preview SDK. +
+ ++ Teste com várias combinações de permissões revogadas e concedidas para destacar os fluxos de usuário +que dependem de permissões. Onde uma dependência não for óbvia ou lógica, considere +refatorar ou compartimentalizar este fluxo para eliminar a dependência ou para esclarecer por que +a permissão é necessária. +
+ ++ Para obter mais informações sobre o comportamento das permissões em tempo de execução, de testes e de melhores práticas, consulte a página + Permissões do Developer + Preview. +
+ + ++ Os recursos de economia de energia de aplicativo em espera e soneca limitam a quantidade de processamento de segundo plano que o aplicativo + pode realizar quando um dispositivo está no estado ocioso ou enquanto não está em foco. As + restrições que o sistema pode impor nos aplicativos inclui acesso a rede limitado ou restrito, + tarefas de segundo plano suspensas, notificações suspensas, solicitações de soneca ignoradas e despertadores. Para garantir + que o aplicativo se comportará adequadamente com essas otimizações de economia de energia, deve-se testá-lo + simulando estes estados de baixa energia. +
+ +Para testar a Soneca com o aplicativo:
+ ++$ adb shell dumpsys battery unplug +$ adb shell dumpsys deviceidle step +$ adb shell dumpsys deviceidle -h ++ +
Para testar o modo de espera do aplicativo:
+ ++$ adb shell am broadcast -a android.os.action.DISCHARGING +$ adb shell am set-idle <packageName> true ++ +
$ adb shell am set-idle <packageName> false+
Caso o aplicativo esteja persistindo qualquer identificador específico do dispositivo, como o ID de registro do Google +Cloud Messaging, no armazenamento interno, +certifique-se de seguir as práticas recomendadas para excluir o local de armazenamento +do backup automático, como descrito em Backup automático +para aplicativos.
diff --git a/docs/html-intl/intl/pt-br/preview/testing/performance.jd b/docs/html-intl/intl/pt-br/preview/testing/performance.jd new file mode 100644 index 0000000000000..d541be11c0a75 --- /dev/null +++ b/docs/html-intl/intl/pt-br/preview/testing/performance.jd @@ -0,0 +1,656 @@ +page.title=Teste de desempenho de exibição +page.image=images/cards/card-test-performance_2x.png +page.keywords=performance, fps, tools + +@jd:body + + ++ O teste de desempenho da interface do usuário (IU) garante que o aplicativo + não só esteja de acordo com os requisitos funcionais, como também que as interações de usuários + sejam muito mais suaves, executando a 60 quadros por segundo de forma consistente (por que + 60 qps?), sem nenhum quadro atrasado ou descartado ou, como gostamos de chamar, "jank". Este documento explica as ferramentas disponíveis + para medir o desempenho da IU e dispõe uma abordagem para integrar + as medidas de desempenho de IU nas práticas de teste. +
+ + ++ Para aprimorar o desempenho, deve-se primeiro ter a habilidade de medir o desempenho + do sistema e, em seguida, diagnosticar e identificar problemas que podem ocorrer + em várias partes do processo. +
+ ++ dumpsys é uma ferramenta + do Android que é executada no dispositivo e despeja informações interessantes sobre o estado + dos serviços do sistema. Passar o comando gfxinfo para dumpsys fornece uma saída no logcat + com informações de desempenho relacionada aos quadros de animação que ocorrem + durante a fase de registro. +
+ ++> adb shell dumpsys gfxinfo <PACKAGE_NAME> ++ +
+ Este comando pode produzir diversas variáveis de dados de precisão de quadro. +
+ ++ Com o M Preview, o comando emite uma análise agregada dos dados de quadro para logcat, + coletados em todo o ciclo de vida do processo. Por exemplo: +
+ ++Stats since: 752958278148ns +Total frames rendered: 82189 +Janky frames: 35335 (42.99%) +90th percentile: 34ms +95th percentile: 42ms +99th percentile: 69ms +Number Missed Vsync: 4706 +Number High input latency: 142 +Number Slow UI thread: 17270 +Number Slow bitmap uploads: 1542 +Number Slow draw: 23342 ++ +
+ Estas estatísticas de alto nível carregam um alto nível de desempenho de renderização do aplicativo, + bem como a estabilidade em vários quadros. +
+ + ++ Com o M Preview, há um novo comando para gfxinfo, o framestats, que fornece + informações de precisão de quadros extremamente detalhadas dos quadros recentes para que você possa rastrear + e depurar os problemas de forma mais precisa. +
+ ++>adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats ++ +
+ Este comando emite informações de precisão de quadros, com marcações de data e hora, dos últimos 120 + quadros produzidos pelo aplicativo. Abaixo, há um exemplo de saída bruta das estatísticas + de quadro de adb dumpsys gfxinfo <PACKAGE_NAME>: +
+ ++0,49762224585003,49762241251670,9223372036854775807,0,49762257627204,49762257646058,49762257969704,49762258002100,49762265541631,49762273951162,49762300914808,49762303675954, +0,49762445152142,49762445152142,9223372036854775807,0,49762446678818,49762446705589,49762447268818,49762447388037,49762453551527,49762457134131,49762474889027,49762476150120, +0,49762462118845,49762462118845,9223372036854775807,0,49762462595381,49762462619287,49762462919964,49762462968454,49762476194547,49762476483454,49762480214964,49762480911527, +0,49762479085548,49762479085548,9223372036854775807,0,49762480066370,49762480099339,49762481013089,49762481085850,49762482232152,49762482478350,49762485657620,49762486116683, ++ +
+ Cada linha desta saída representa um quadro produzido pelo aplicativo. Cada linha tem um número fixo + de colunas que descrevem o tempo gasto em cada estágio do pipeline que produz quadros. A próxima seção descreve + este formato com detalhes, incluindo o que cada coluna representa. +
+ + ++ Como o bloco de dados é a saída no formato CSV, basta colá-lo na ferramenta + de planilha de sua escolha ou coletá-lo e analisá-lo com o script. A tabela a seguir explica o formato + das colunas de dados de saída. Todas as marcações de data e hora estão em nanossegundos. +
+ ++ É possível usar estes dados de várias formas. Uma visualização simples mas útil é o histograma + exibindo a distribuição dos tempos dos quadros (FRAME_COMPLETED - INTENDED_VSYNC) + em diferentes espaços de latência. Consulte a figura abaixo. Este gráfico mostra brevemente que a maioria + dos quadros estavam bons — bem abaixo do limite de 16 ms (representado em vermelho) —, + mas que alguns quadros estavam bem acima do limite. Podemos verificar as alterações neste histograma + com o tempo para encontrar as mudanças indiscriminadas ou novas exceções sendo criadas. Também é possível colocar em gráfico a latência de entrada, + o tempo gasto no layout ou outras medidas interessantes com base + nas várias marcações de data e hora nos dados. +
+ +
+
+
+
+ Se a renderização de GPU de perfil for definida para em adb shell dumpsys gfxinfo
+ nas opções de desenvolvedor, o comando adb shell dumpsys gfxinfo emitirá informações
+ de precisão para os 120 quadros mais recentes, divididas em algumas categorias
+ com valores separados por guias. Estes dados podem ser úteis para indicar quais partes do pipeline
+ de desenho podem estar lentas em um nível alto.
+
+ Semelhante às estatísticas de quadro acima, + basta colá-los na ferramenta de planilha de sua escolha ou coletá-los e analisá-los + com um script. O gráfico a seguir exibe um detalhamento de onde os vários quadros produzidos + pelo aplicativo gastaram o tempo. +
+ +
+
++ O resultado de executar gfxinfo, copiar a saída, colá-lo no aplicativo de planilha + e gerar um gráfico dos dados como barras empilhadas. +
+ ++ Cada barra vertical representa um quadro da animação; sua altura representa a quantidade + de milissegundos para calcular este quadro de animação. Cada segmento colorido da barra + representa um estágio diferente do pipeline de renderização para que você possa ver que partes do aplicativo + podem estar criando um afunilamento. Para obter mais informações sobre o entendimento do pipeline + de renderização e como otimizá-lo, assista ao vídeo +Invalidações, layouts e desempenho. +
+ + ++ As precisões de quadro simples e estatísticas de quadro coletam dados + em um período muito curto — cerca de dois segundos de renderização. Para controlar este período de forma precisa — por exemplo, + restringir os dados para uma animação em particular —, é possível redefinir + todos os contadores e agregar as estatísticas coletadas. +
+ ++>adb shell dumpsys gfxinfo <PACKAGE_NAME> reset ++ +
+ Isto também pode ser usado em conjunto com os próprios comandos de despejo para coletar + e redefinir em uma cadência regular, capturando períodos de menos de dois segundos de quadros + continuamente. +
+ + ++ A identificação de regressões é uma boa primeira etapa para rastrear os problemas + e manter o bem-estar do aplicativo. No entanto, o dumpsys identifica apenas a existência + e a gravidade relativa dos problemas. Ainda é necessário diagnosticar a causa particular dos problemas + de desempenho e encontrar maneiras adequadas de resolvê-los. Para isso, é altamente recomendado + o uso da ferramenta systrace. +
+ + ++ Para obter mais informações sobre como o pipeline de renderização do Android funciona, + problemas comuns que podem ser encontrados e como resolvê-los, + alguns dos seguintes recursos podem ser úteis: +
+ ++ Uma abordagem para o teste de desempenho da IU é fazer com que um testador humano + realize uma série de operações de usuário no aplicativo-alvo e procure visualmente problemas + ou gaste uma grande quantidade de tempo usando uma abordagem de ferramenta para encontrá-los. No entanto, esta abordagem manual + é repleta de riscos: a habilidade humana de notar alterações na taxa de quadros varia tremendamente, + além de consumir tempo, ser tedioso e propenso a erros. +
+ ++ Uma abordagem mais eficiente é registrar e analisar as métricas de desempenho essenciais + dos testes de IU automatizados. O Android M Developer Preview inclui novas capacidades de registro que facilitam + a determinação da quantidade e da gravidade de erros nas animações do aplicativo + e que podem ser usadas para compilar um processo rigoroso para determinar o desempenho atual + e rastrear os futuros objetivos de desempenho. +
+ ++ Este artigo mostra uma abordagem recomendada para usar estes dados para automatizar + o teste de desempenho. +
+ ++ Ele é geralmente dividido em duas ações principais. Primeiro: identificar o que está testando + e como será testado. Segundo: configuração e manutenção + de um ambiente de teste automatizado. +
+ + ++ Antes de iniciar o teste automatizado, é importante determinar algumas decisões de alto nível + para entender corretamente o espaço de teste e as possíveis necessidades. +
+ ++ Lembre-se que um desempenho ruim é mais visível aos usuários quando + interrompe uma animação suave. Portanto, ao identificar que tipos de ações de IU serão testadas, é útil se concentrar + nas animações principais que os usuários veem + ou nas mais importantes para a experiência. Por exemplo, eis alguns cenários comuns que pode ser útil identificar: +
+ ++ Trabalhe com engenheiros, designers, e gerentes de produto em sua equipe para priorizar + as animações de produto essenciais para a cobertura de teste. +
+ ++ De um alto nível, talvez seja essencial identificar os objetivos específicos de desempenho + e concentrar-se em escrever testes e coletar dados. Por exemplo: +
+ ++ Em todos esses casos, você optará pelo rastreamento histórico, que exibe o desempenho + entre várias versões do aplicativo. +
+ ++ O desempenho do aplicativo varia dependendo do dispositivo em que está sendo executado. Alguns dispositivos podem + conter menos memória, GPUs menos eficientes ou chips de CPU mais lentos. Isto significa que as animações que podem + ter um bom desempenho em um conjunto de hardwares podem não ter o mesmo desempenho em outras, + podendo ser o resultado de um afunilamento em uma parte diferente do pipeline. Portanto, para contabilizar + esta variação em o que o usuário pode ver, escolha uma variação de dispositivos + para executar os testes: dispositivos e tablets de alto e baixo nível etc. Procure variações no desempenho de CPU, + RAM, densidade da tela, tamanho etc. Testes que passam em dispositivos de alto nível + podem falhar em dispositivos de baixo nível. +
+ ++ Conjuntos de ferramenta, como UI Automator e + Espresso, + são integrados para ajudar na automatização da ação de um usuário movendo-se pelo aplicativo. São estruturas simples + que imitam a interação de usuário no dispositivo. Para usar estas estruturas, + você cria efetivamente scripts únicos que executam um conjunto + de ações de usuário e reproduzem-nas no próprio dispositivo. +
+ +
+ Ao combinar estes testes automatizados, juntamente com dumpsys gfxinfo, é possível criar
+ rapidamente um sistema reproduzível que permite a execução de um teste e a medição das informações
+ de desempenho desta condição em particular.
+
+ Com a habilidade de executar um teste de IU e um pipeline para coletar + os dados de um único teste, a próxima etapa importante é adotar uma estrutura que pode executar + esse teste várias vezes, em vários dispositivos, e agregar os dados de desempenho resultados + para futuras análises da equipe de desenvolvimento. +
+ ++ Vale observar que as estruturas de teste de IU (como o UI Automator) + são executadas diretamente no emulador/dispositivo alvo. Enquanto as informações de coleta de desempenho feita + pelo dumpsys gfxinfo forem direcionadas por uma máquina hospedeira, envie comandos pelo ADB. Para ajudar a transmitir + a automatização dessas entidades separadas, a estrutura MonkeyRunner + foi desenvolvida: um sistema de script que é executado na máquina host que pode + emitir comandos para um conjunto de dispositivos conectados, bem como receber dados deles. +
+ ++ A compilação de um conjunto de scripts para uma automatização adequada de teste de desempenho de IU, + no mínimo, deve ser capaz de utilizar o MonkeyRunner para realizar as seguintes tarefas: +
+ ++ Quando os padrões ou regressões dos problemas forem identificados, a próxima etapa + é identificar e aplicar a resolução. Se a estrutura de teste automatizado preservar o detalhamento preciso para os quadros, + ela poderá ajudar na inspeção de alterações de layout/código suspeitos recentes (em caso + de regressão) ou reduzir a parte do sistema que você está analisando ao alternar + para a investigação manual. Para a investigação manual, systrace é um ótimo lugar para começar, + exibindo as informações de precisão sobre cada estágio do pipeline de renderização, + cada encadeamento e núcleo no sistema, bem como quaisquer marcadores de evento personalizados definidos. +
+ ++ É importante observar as dificuldades em obter e medir as precisões + do desempenho de renderização. Esses números são, por natureza, não determinísticos e frequentemente + oscilam dependendo do estado do sistema, da quantidade de memória disponível, + da diminuição termal e da última vez em que a luz do sol atingiu a sua área da Terra. Ou seja, é possível executar + o mesmo teste duas vezes e receber números levemente diferentes + que podem ser muito próximos, mas não idênticos. +
+ ++ A coleta e a geração de perfil de dados nesta maneira significa executar o mesmo teste, + várias vezes, e acumular os resultados como uma média ou valor mediano (para a simplicidade, + chamemos de "lote"). Isto fornece uma aproximação do desempenho do teste, + já que precisões exatas não são necessárias. +
+ ++ Os lotes podem ser usados entre alterações de códigos para verificar o impacto relativo + dessas alterações no desempenho. Se a taxa de quadros média para o lote antes da alteração + for maior do que o lote após a alteração, então o resultado de desempenho wrt geral será um sucesso + para esta alteração em particular. +
+ ++ Isto significa que qualquer teste de IU automatizado feito deve levar este conceito + em consideração, bem como quaisquer anomalias que possam ocorrer durante um teste. Por exemplo, + se o desempenho do aplicativo repentinamente cair devido a algum problema do dispositivo + (que não tenha sido causado pelo aplicativo), então talvez seja necessário executar + o lote novamente para obter precisões menos caóticas. +
+ ++ Logo, quantas vezes deve-se realizar um teste antes de as medidas terem algum sentido? 10 vezes deve ser o mínimo, + com números altos como 50 ou 10 oferecendo resultados mais precisos + (é claro que se deve levar em consideração o tempo para ter mais precisão). +