Participe do evento ⁠#Android11: apresentação de lançamento da versão Beta no dia 3 de junho.

Como depurar o WorkManager

Se você perceber que seus workers são executados com muita frequência ou não são executados, veja algumas etapas de depuração que podem ajudar a descobrir o que está acontecendo.

Ativar o registro

Para determinar o motivo pelo qual seus workers não estão sendo executados corretamente, pode ser muito útil analisar os registros detalhados do WorkManager. Para ativar o registro, é preciso usar a inicialização personalizada. Primeiro, desative o WorkManagerInitializer padrão no AndroidManifest.xml:

    <provider
        android:name="androidx.work.impl.WorkManagerInitializer"
        android:authorities="${applicationId}.workmanager-init"
        tools:node="remove" />
    

Observe que a regra de combinação de manifesto remove está sendo usada.

Agora que o inicializador padrão está desativado, você pode usar a inicialização sob demanda. Para fazer isso, a classe android.app.Application precisa fornecer uma implementação para androidx.work.Configuration.Provider.

class MyApplication() : Application(), Configuration.Provider {
        override fun getWorkManagerConfiguration() =
            Configuration.Builder()
                .setMinimumLoggingLevel(android.util.Log.DEBUG)
                .build()
    }
    

Depois que o registro de DEBUG é ativado, muitos novos registros com o prefixo WM- da tag de registro começam a aparecer.

Usar adb shell dumpsys jobscheduler

Na API de nível 23 ou versões mais recentes, execute o comando adb shell dumpsys jobscheduler para ver a lista de jobs atribuídos ao pacote.

Você verá algo como:

    JOB #u0a172/4: 6412553 com.google.android.youtube/androidx.work.impl.background.systemjob.SystemJobService
      u0a172 tag=*job*/com.google.android.youtube/androidx.work.impl.background.systemjob.SystemJobService
      Source: uid=u0a172 user=0 pkg=com.google.android.youtube
      JobInfo:
        Service: com.google.android.youtube/androidx.work.impl.background.systemjob.SystemJobService
        Requires: charging=false batteryNotLow=false deviceIdle=false
        Extras: mParcelledData.dataSize=180
        Network type: NetworkRequest [ NONE id=0, [ Capabilities: NOT_METERED&INTERNET&NOT_RESTRICTED&TRUSTED&VALIDATED Uid: 10172] ]
        Minimum latency: +1h29m59s687ms
        Backoff: policy=1 initial=+30s0ms
        Has early constraint
      Required constraints: TIMING_DELAY CONNECTIVITY [0x90000000]
      Satisfied constraints: DEVICE_NOT_DOZING BACKGROUND_NOT_RESTRICTED WITHIN_QUOTA [0x3400000]
      Unsatisfied constraints: TIMING_DELAY CONNECTIVITY [0x90000000]
      Tracking: CONNECTIVITY TIME QUOTA
      Implicit constraints:
        readyNotDozing: true
        readyNotRestrictedInBg: true
      Standby bucket: RARE
      Base heartbeat: 0
      Enqueue time: -51m29s853ms
      Run time: earliest=+38m29s834ms, latest=none, original latest=none
      Last run heartbeat: 0
      Ready: false (job=false user=true !pending=true !active=true !backingup=true comp=true)
    

Ao usar o WorkManager, o componente responsável por gerenciar a execução de workers é SystemJobService (na API de nível 23 ou versões mais recentes). Procure instâncias de jobs atribuídas ao nome do pacote e a androidx.work.impl.background.systemjob.SystemJobService.

Para cada job, a saída do comando lista as restrições obrigatórias, satisfeitas e não satisfeitas. É necessário verificar se as restrições do seu worker foram totalmente satisfeitas.

Você pode usar isso para verificar se o SystemJobService foi invocado recentemente. A saída também inclui o histórico de jobs executados recentemente:

Job history:
         -1h35m26s440ms   START: #u0a107/9008 com.google.android.youtube/androidx.work.impl.background.systemjob.SystemJobService
         -1h35m26s362ms  STOP-P: #u0a107/9008 com.google.android.youtube/androidx.work.impl.background.systemjob.SystemJobService app called jobFinished