Ao testar a integração do ProfilingManager localmente, as solicitações podem ser
limitadas por limitação de taxa ou os traces em segundo plano podem não estar ativos ao
testar acionadores. Use os comandos adb nesta página para desativar a limitação,
extrair perfis, reter traces não editados, acionar capturas e inspecionar o estado
do serviço em um dispositivo de teste.
Desativar o limitador de taxa
Para desativar os limitadores de taxa do sistema e do processo do app para solicitações de requestProfiling
durante o teste local, execute o seguinte comando device_config:
adb shell device_config put profiling_testing rate_limiter.disabled true
Quando terminar o teste, redefina a flag:
adb shell device_config delete profiling_testing rate_limiter.disabled
Extrair perfis usando o ADB
Para inspecionar um perfil editado localmente em um dispositivo com acesso root, execute adb
pull com o caminho retornado por getResultFilePath:
# Pull a profile
adb pull /data/user/0/<com.example.myapp>/files/profiling/<profile-file-name>
Reter resultados temporários e não editados
Ao testar a criação de perfil localmente, é possível reter os resultados no diretório temporário
em /data/misc/perfetto-traces/profiling/. Comparar um rastreamento do sistema
não editado com a versão editada ajuda a entender quais dados são
removidos durante a edição.
A forma como os resultados temporários e não editados são retidos depende da versão do Android que seu dispositivo usa:
Android 16 (nível 36 da API) e versões mais recentes: é possível manter os resultados não editados (quando aplicável) e editados no diretório temporário, que foi expandido no Android 16 para ser acessível usando
adb pullem todos os tipos de build sem acesso root (enquanto o Android 15 exige acesso root para ler/data/misc/perfetto-traces/profiling/). Para evitar que o sistema exclua resultados temporários, execute o seguinte comando:adb shell device_config put profiling_testing delete_temporary_results.disabled trueAndroid 15 (nível 35 da API): no diretório temporário, é possível manter apenas o resultado não editado, que pode ser acessado por
adbapenas em builds com acesso root. O app ainda recebe o perfil editado no próprio diretório/data/user/0/<app>/files/profiling/, que o código do app pode ler ou copiar em qualquer build, embora a extração direta de/data/user/0/...comadb pullexija acesso root ouadb shell run-as <app>em um build depurável. Para evitar que o sistema exclua traces não editados, execute o seguinte comando:adb shell device_config put profiling_testing delete_unredacted_trace.disabled true
Depois de capturar um perfil, extraia o arquivo retido do diretório temporário:
# Pull a retained redacted profile (Android 16 and higher)
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.<profile-type-ext>
# Pull an unredacted system trace
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.perfetto-trace-unredacted
Nesses comandos, <trace-name> é o nome de arquivo base (sem extensão) do
caminho retornado por ProfilingResult.getResultFilePath, e a cópia do rastreamento do sistema
não editada adiciona -unredacted à extensão .perfetto-trace. Para
detalhes sobre a estrutura do nome de arquivo e os valores de <profile-type-ext>, consulte Locais
de arquivos e formatos de nomenclatura.
adb shell device_config delete profiling_testing delete_temporary_results.disabled
adb shell device_config delete profiling_testing delete_unredacted_trace.disabled
Forçar a ativação de traces em segundo plano para testes de acionadores
Como os traces em segundo plano do sistema são executados em intervalos aleatórios na produção, pode ser difícil testar a criação de perfil baseada em acionadores localmente. Para forçar o sistema a
executar um rastro contínuo em segundo plano e ignorar o limitador de taxa no nível do sistema para
os acionadores do app, defina system_triggered_profiling.testing_package_name:
adb shell device_config put profiling_testing system_triggered_profiling.testing_package_name <com.example.myapp>
Qualquer período de espera por gatilho configurado com setRateLimitingPeriodHours ainda
é válido. Como esse modo é executado continuamente até que você o limpe, remova a
flag quando terminar o teste:
adb shell device_config delete profiling_testing system_triggered_profiling.testing_package_name
Comandos úteis de depuração
No Android 16 (nível 36 da API) e versões mais recentes com uma versão recente do módulo Profiling,
é possível usar a ferramenta cmd profiling_service em adb para ativar
a geração de registros detalhados, acionar coletas de perfis sob demanda e testar acionadores
diretamente na linha de comando.
Ativar a geração de registros de depuração detalhados
Para ativar os registros detalhados do ProfilingService no logcat e diagnosticar o processamento e a entrega de solicitações, execute o seguinte comando:
adb shell cmd profiling_service enable-logs true
Solicitar uma coleção de perfis on demand
Para iniciar uma captura de perfil imediata para um pacote específico na linha de comando, execute o seguinte comando:
adb shell cmd profiling_service request-profiling <profiling_type> <com.example.myapp> [--user <user_id>] [--duration <duration_ms>] [--sources <sources>]
Nesse comando, <profiling_type> é o valor constante inteiro de
ProfilingManager (1 para um heap dump do Java, 2 para um perfil de alocação heap, 3 para
amostragem de pilha ou 4 para um rastreamento do sistema). O processo do app de destino precisa estar
em execução para perfis de memória e pilha, a solicitação está sujeita ao limitador
de taxa, a menos que esteja desativado, e o ProfilingResult concluído é entregue apenas
a listeners globais registrados com registerForAllProfilingResults.
Registrar e simular gatilhos
Para registrar um acionador ou disparar um evento de acionador simulado para um pacote e verificar o processamento de callback do acionador, execute os seguintes comandos:
adb shell cmd profiling_service add-trigger <trigger_type> <com.example.myapp> [--user <user_id>]
adb shell cmd profiling_service trigger <trigger_type> <com.example.myapp> [--user <user_id>]
Nesses comandos, <trigger_type> é o valor constante inteiro de
ProfilingTrigger (por exemplo, 1 para TRIGGER_TYPE_APP_FULLY_DRAWN,
2 para TRIGGER_TYPE_ANR ou 7 para TRIGGER_TYPE_OOM). A execução de
add-trigger registra o acionador com um período de espera de 0 horas, substituindo qualquer
registro atual para esse tipo de acionador. A simulação de acionadores que salvam um
snapshot do rastro em segundo plano (como 1 ou 2) requer um rastro em segundo plano
ativo (consulte Forçar a ativação de rastros em segundo plano para testes de acionadores).
Coletar o estado geral do ProfilingManager
No Android 16 (nível 36 da API) e versões mais recentes com uma versão recente do módulo Profiling,
é possível executar dumpsys em profiling_service para diagnosticar problemas
e inspecionar o estado atual de ProfilingManager:
adb shell dumpsys profiling_service
A saída dumpsys profiling_service é destinada apenas para fins informativos e de depuração, e o formato dela está sujeito a alterações. Ele fornece um snapshot
do estado interno do serviço, incluindo:
- Limitações ativas e status do limitador de taxa.
- Configurações de dispositivos ativos.
- Acionadores de apps registrados e os períodos de espera de limitação de taxa.
- Sessões de criação de perfil ativas e em fila.
- Solicitações de criação de perfil recentes, ocorrências de acionadores e eventos de entrega de resultados.