Lorsque vous testez votre intégration ProfilingManager localement, les requêtes peuvent être limitées par la limitation du débit ou les traces en arrière-plan peuvent ne pas être actives lors du test des déclencheurs. Utilisez les commandes adb de cette page pour désactiver la limitation, extraire des profils, conserver des traces non censurées, déclencher des captures et inspecter l'état du service sur un appareil de test.
Désactiver le limiteur de débit
Pour désactiver les limiteurs de débit du processus d'application et du système pour les requêtes requestProfiling lors des tests locaux, exécutez la commande device_config suivante :
adb shell device_config put profiling_testing rate_limiter.disabled true
Une fois les tests terminés, réinitialisez l'option :
adb shell device_config delete profiling_testing rate_limiter.disabled
Extraire des profils à l'aide d'ADB
Pour inspecter un profil masqué localement sur un appareil avec un accès racine, exécutez adb
pull avec le chemin d'accès renvoyé par getResultFilePath :
# Pull a profile
adb pull /data/user/0/<com.example.myapp>/files/profiling/<profile-file-name>
Conserver les résultats temporaires et non masqués
Lorsque vous testez le profilage localement, vous pouvez conserver les résultats dans le répertoire temporaire /data/misc/perfetto-traces/profiling/. La comparaison d'une trace système non masquée avec sa version masquée vous aide à comprendre quelles données sont supprimées lors du masquage.
La conservation des résultats temporaires et non masqués dépend de la version d'Android installée sur votre appareil :
Android 16 (niveau d'API 36) ou version ultérieure : vous pouvez conserver les résultats non masqués (le cas échéant) et masqués dans le répertoire temporaire, qui a été étendu dans Android 16 pour être accessible à l'aide de
adb pullsur tous les types de compilation sans accès racine (alors qu'Android 15 nécessite un accès racine pour lire/data/misc/perfetto-traces/profiling/). Pour empêcher le système de supprimer les résultats temporaires, exécutez la commande suivante :adb shell device_config put profiling_testing delete_temporary_results.disabled trueAndroid 15 (niveau d'API 35) : dans le répertoire temporaire, vous ne pouvez conserver que le résultat non masqué, accessible via
adbuniquement sur les builds avec accès racine. (Votre application reçoit toujours le profil masqué dans son propre répertoire/data/user/0/<app>/files/profiling/, que le code de votre application peut lire ou copier sur n'importe quel build, bien que l'extraction directe depuis/data/user/0/...avecadb pullnécessite un accès racine, ouadb shell run-as <app>sur un build débogable.) Pour empêcher le système de supprimer les traces non censurées, exécutez la commande suivante :adb shell device_config put profiling_testing delete_unredacted_trace.disabled true
Après avoir capturé un profil, extrayez le fichier conservé du répertoire temporaire :
# 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
Dans ces commandes, <trace-name> est le nom de fichier de base (sans extension) du chemin d'accès renvoyé par ProfilingResult.getResultFilePath, et la copie de trace système non masquée ajoute -unredacted à l'extension .perfetto-trace. Pour en savoir plus sur la structure des noms de fichiers et les valeurs <profile-type-ext>, consultez Emplacements des fichiers et formats de dénomination.
adb shell device_config delete profiling_testing delete_temporary_results.disabled
adb shell device_config delete profiling_testing delete_unredacted_trace.disabled
Activer de force les traces en arrière-plan pour tester les déclencheurs
Étant donné que les traces système en arrière-plan s'exécutent à des intervalles aléatoires en production, il peut être difficile de tester le profilage basé sur un déclencheur localement. Pour forcer le système à exécuter une trace continue en arrière-plan et à contourner le limiteur de débit au niveau du système pour les déclencheurs de votre application, définissez system_triggered_profiling.testing_package_name :
adb shell device_config put profiling_testing system_triggered_profiling.testing_package_name <com.example.myapp>
Tout délai d'attente par déclencheur configuré avec setRateLimitingPeriodHours s'applique toujours. Comme ce mode s'exécute en continu jusqu'à ce que vous l'effaciez, supprimez l'option lorsque vous avez terminé les tests :
adb shell device_config delete profiling_testing system_triggered_profiling.testing_package_name
Commandes de débogage utiles
Sur Android 16 (niveau d'API 36) ou version ultérieure avec une version récente du module Profiling, vous pouvez utiliser l'outil cmd profiling_service sur adb pour activer la journalisation détaillée, déclencher des collectes de profils à la demande et tester les déclencheurs directement depuis la ligne de commande.
Activer la journalisation détaillée du débogage
Pour activer les journaux ProfilingService détaillés dans logcat et diagnostiquer la gestion et la distribution des requêtes, exécutez la commande suivante :
adb shell cmd profiling_service enable-logs true
Demander une collecte de profils à la demande
Pour lancer une capture de profil immédiate pour un package spécifique à partir de la ligne de commande, exécutez la commande suivante :
adb shell cmd profiling_service request-profiling <profiling_type> <com.example.myapp> [--user <user_id>] [--duration <duration_ms>] [--sources <sources>]
Dans cette commande, <profiling_type> est la valeur de constante entière de ProfilingManager (1 pour une empreinte de la mémoire Java, 2 pour un profil du tas, 3 pour l'échantillonnage de la pile ou 4 pour une trace système). Le processus de l'application cible doit être en cours d'exécution pour les profils de mémoire et de pile. La requête est soumise au limiteur de débit, sauf s'il est désactivé, et le ProfilingResult terminé n'est envoyé qu'aux écouteurs globaux enregistrés auprès de registerForAllProfilingResults.
Enregistrer et simuler des déclencheurs
Pour enregistrer un déclencheur ou déclencher un événement de déclencheur simulé pour un package, et vérifier la gestion des rappels de déclencheur, exécutez les commandes suivantes :
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>]
Dans ces commandes, <trigger_type> est la valeur de constante entière de ProfilingTrigger (par exemple, 1 pour TRIGGER_TYPE_APP_FULLY_DRAWN, 2 pour TRIGGER_TYPE_ANR ou 7 pour TRIGGER_TYPE_OOM). L'exécution de add-trigger enregistre le déclencheur avec un temps de recharge de 0 heures, ce qui remplace tout enregistrement existant pour ce type de déclencheur. La simulation de déclencheurs qui enregistrent un instantané de la trace en arrière-plan (comme 1 ou 2) nécessite une trace en arrière-plan active (voir Activer de force les traces en arrière-plan pour tester les déclencheurs).
Collecter l'état global de ProfilingManager
Sur Android 16 (niveau d'API 36) ou version ultérieure avec une version récente du module Profiling, vous pouvez exécuter dumpsys sur profiling_service pour diagnostiquer les problèmes et inspecter l'état actuel de ProfilingManager :
adb shell dumpsys profiling_service
La sortie dumpsys profiling_service n'est destinée qu'à des fins d'information et de débogage, et son format est susceptible d'être modifié. Il fournit un instantané de l'état interne du service, y compris :
- Limites actives et état du limiteur de débit.
- Configurations de l'appareil actives.
- Déclencheurs d'application enregistrés et leurs délais de récupération pour la limitation du débit.
- Sessions de profilage actives et en file d'attente.
- Requêtes de profilage récentes, occurrences de déclencheur et événements de diffusion des résultats.