Comandi di debug per la profilazione locale

Quando testi l'integrazione di ProfilingManager localmente, le richieste potrebbero essere limitate dalla limitazione di frequenza o le tracce in background potrebbero non essere attive durante il test dei trigger. Utilizza i comandi adb in questa pagina per disattivare la limitazione, estrarre i profili, conservare le tracce non oscurate, attivare le acquisizioni e ispezionare lo stato del servizio su un dispositivo di test.

Disattiva il limitatore di frequenza

Per disattivare i limitatori di frequenza del processo dell'app e del sistema per le richieste requestProfiling durante i test locali, esegui il seguente comando device_config:

adb shell device_config put profiling_testing rate_limiter.disabled true

Al termine del test, reimposta il flag:

adb shell device_config delete profiling_testing rate_limiter.disabled

Estrai i profili utilizzando ADB

Per ispezionare un profilo oscurato localmente su un dispositivo con accesso root, esegui adb pull con il percorso restituito da getResultFilePath:

# Pull a profile
adb pull /data/user/0/<com.example.myapp>/files/profiling/<profile-file-name>

Conserva i risultati temporanei e non oscurati

Quando testi la profilazione localmente, puoi conservare i risultati nella directory temporanea in /data/misc/perfetto-traces/profiling/. Il confronto di una traccia di sistema non oscurata con la sua controparte oscurata ti aiuta a capire quali dati vengono eliminati durante l'oscuramento.

La modalità di conservazione dei risultati temporanei e non oscurati dipende dalla versione di Android installata sul dispositivo:

  • Android 16 (livello API 36) e versioni successive: puoi conservare i risultati non oscurati (se applicabile) e oscurati nella directory temporanea, che è stata ampliata in Android 16 per essere accessibile utilizzando adb pull su tutti i tipi di build senza accesso root (mentre Android 15 richiede l'accesso root per leggere /data/misc/perfetto-traces/profiling/). Per impedire al sistema di eliminare i risultati temporanei, esegui questo comando:

    adb shell device_config put profiling_testing delete_temporary_results.disabled true

  • Android 15 (livello API 35): nella directory temporanea, puoi conservare solo il risultato non oscurato, accessibile tramite adb solo nelle build con accesso root. (La tua app riceve comunque il profilo oscurato nella propria directory /data/user/0/<app>/files/profiling/, che il codice dell'app può leggere o copiare su qualsiasi build, anche se l'estrazione diretta da /data/user/0/... con adb pull richiede l'accesso root o adb shell run-as <app> su una build abilitata al debug.) Per impedire al sistema di eliminare le tracce non oscurate, esegui questo comando:

    adb shell device_config put profiling_testing delete_unredacted_trace.disabled true

Dopo aver acquisito un profilo, estrai il file conservato dalla directory temporanea:

# 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

In questi comandi, <trace-name> è il nome file di base (senza estensione) dal percorso restituito da ProfilingResult.getResultFilePath e la copia del tracciamento del sistema non oscurata aggiunge -unredacted all'estensione .perfetto-trace. Per maggiori dettagli sulla struttura del nome file e sui valori <profile-type-ext>, consulta Posizioni dei file e formati di denominazione.

adb shell device_config delete profiling_testing delete_temporary_results.disabled
adb shell device_config delete profiling_testing delete_unredacted_trace.disabled

Forza l'attivazione delle tracce in background per i test dei trigger

Poiché le tracce in background del sistema vengono eseguite a intervalli casuali in produzione, testare la profilazione basata su trigger localmente può essere difficile. Per forzare il sistema a eseguire una traccia in background continua e bypassare il limitatore di frequenza a livello di sistema per gli attivatori della tua app, imposta system_triggered_profiling.testing_package_name:

adb shell device_config put profiling_testing system_triggered_profiling.testing_package_name <com.example.myapp>

Qualsiasi periodo di attesa per trigger configurato con setRateLimitingPeriodHours è ancora valido. Poiché questa modalità viene eseguita continuamente finché non la disattivi, rimuovi il flag al termine del test:

adb shell device_config delete profiling_testing system_triggered_profiling.testing_package_name

Comandi di debug utili

Su Android 16 (livello API 36) e versioni successive con una versione recente del modulo Profiling, puoi utilizzare lo strumento cmd profiling_service su adb per attivare il logging dettagliato, attivare le raccolte di profili on demand e testare gli attivatori direttamente dalla riga di comando.

Attiva il logging di debug dettagliato

Per abilitare i log dettagliati di ProfilingService in logcat e diagnosticare la gestione e la distribuzione delle richieste, esegui questo comando:

adb shell cmd profiling_service enable-logs true

Richiedi una raccolta di profili on demand

Per avviare un'acquisizione immediata del profilo per un pacchetto specifico dalla riga di comando, esegui questo comando:

adb shell cmd profiling_service request-profiling <profiling_type> <com.example.myapp> [--user <user_id>] [--duration <duration_ms>] [--sources <sources>]

In questo comando, <profiling_type> è il valore della costante intera di ProfilingManager (1 per un dump dell'heap Java, 2 per un profilo heap, 3 per il campionamento dello stack o 4 per un tracciamento del sistema). Il processo dell'app di destinazione deve essere in esecuzione per i profili di memoria e stack, la richiesta è soggetta al limitatore di frequenza, a meno che non sia disattivato, e il ProfilingResult completato viene inviato solo ai listener globali registrati con registerForAllProfilingResults.

Registra e simula i trigger

Per registrare un trigger o attivare un evento di trigger simulato per un pacchetto e verificare la gestione del callback del trigger, esegui i seguenti comandi:

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>]

In questi comandi, <trigger_type> è il valore della costante intera di ProfilingTrigger (ad esempio, 1 per TRIGGER_TYPE_APP_FULLY_DRAWN, 2 per TRIGGER_TYPE_ANR o 7 per TRIGGER_TYPE_OOM). L'esecuzione di add-trigger registra l'attivatore con un periodo di attesa di 0 ore, sostituendo qualsiasi registrazione esistente per quel tipo di attivatore. La simulazione di trigger che salvano uno snapshot della traccia in background (come 1 o 2) richiede una traccia in background attiva (consulta Forza l'attivazione delle tracce in background per i test dei trigger).

Raccogli lo stato complessivo di ProfilingManager

Su Android 16 (livello API 36) e versioni successive con una versione recente del modulo Profiling, puoi eseguire dumpsys su profiling_service per diagnosticare i problemi e ispezionare lo stato attuale di ProfilingManager:

adb shell dumpsys profiling_service

L'output dumpsys profiling_service è destinato solo a scopi informativi e di debug e il suo formato è soggetto a modifiche. Fornisce un'istantanea dello stato interno del servizio, tra cui:

  • Limitazioni attive e stato del limitatore di frequenza.
  • Configurazioni dispositivo attive.
  • Trigger di app registrate e relativi cooldown di limitazione di frequenza.
  • Sessioni di profilazione attive e in coda.
  • Richieste di profilazione, occorrenze di trigger ed eventi di invio dei risultati recenti.