Any way to learn how often Custota will check for updates "at current condition"?

[LindaFerum]

It seems that for some reason the check is really rare on one of my droids.

Any way to learn "when next check is supposed to happen"?

P.S.: IMHO it would be neat to let user specify the check frequency rather than letting android do this opaquely but that's my opinion :-)

[chenxiaolong]

Android doesn't make this super obvious to check, but it's possible via adb:

adb shell 'dumpsys jobscheduler | grep -A50 "JOB.*com.chiller3.custota/.updater.UpdaterJob"'

It will print out something like this:

  JOB #u0a104/2: 4541ad0 com.chiller3.custota/.updater.UpdaterJob
    u0a104 tag=*job*r/com.chiller3.custota/.updater.UpdaterJob
    Source: uid=u0a104 user=0 pkg=com.chiller3.custota
    JobInfo:
      Service: com.chiller3.custota/.updater.UpdaterJob
      PERIODIC: interval=+6h0m0s0ms flex=+6h0m0s0ms
      PERSISTED
      Priority: 300 [DEFAULT]
      Requires: charging=false batteryNotLow=false deviceIdle=false
      Extras: {action=1}
      Network type: NetworkRequest [ NONE id=0, [ Capabilities: INTERNET&TRUSTED&VALIDATED&NOT_VCN_MANAGED&NOT_BANDWIDTH_CONSTRAINED Uid: 10104 UnderlyingNetworks: Null] ]
      Backoff: policy=1 initial=+30s0ms
      Has early constraint
      Has late constraint
    Required constraints: TIMING_DELAY DEADLINE CONNECTIVITY FLEXIBILITY [0xd0200000]
    Dynamic constraints:
    Satisfied constraints: CONNECTIVITY FLEXIBILITY DEVICE_NOT_DOZING BACKGROUND_NOT_RESTRICTED WITHIN_QUOTA [0x13600000]
    Unsatisfied constraints: TIMING_DELAY DEADLINE [0xc0000000]
    Num Required Flexible constraints: 0
    Num Dropped Flexible constraints: 0
    Constraint history:
      -1h2m4s163ms = FLEXIBILITY [0x200000]
      -1h2m4s163ms = CONNECTIVITY FLEXIBILITY [0x10200000]
      -1h2m4s163ms = CONNECTIVITY FLEXIBILITY BACKGROUND_NOT_RESTRICTED [0x10600000]
      -1h2m4s163ms = CONNECTIVITY FLEXIBILITY DEVICE_NOT_DOZING BACKGROUND_NOT_RESTRICTED [0x12600000]
      -1h2m4s163ms = CONNECTIVITY FLEXIBILITY DEVICE_NOT_DOZING BACKGROUND_NOT_RESTRICTED WITHIN_QUOTA [0x13600000]
      -1h1m36s884ms = CONNECTIVITY FLEXIBILITY BACKGROUND_NOT_RESTRICTED WITHIN_QUOTA [0x11600000]
      -2m35s49ms = CONNECTIVITY FLEXIBILITY DEVICE_NOT_DOZING BACKGROUND_NOT_RESTRICTED WITHIN_QUOTA [0x13600000]
    Tracking: CONNECTIVITY TIME QUOTA
    Implicit constraints:
      readyNotDozing: true
      readyNotRestrictedInBg: true
      readyComponentEnabled: true
    Started with foreground flag: false
    Network: 102
    Standby bucket: EXEMPTED
    Enqueue time: -1h2m4s163ms
    Run time: earliest=+3h1m29s652ms, latest=+9h1m29s652ms, original latest=+9h1m29s652ms
    Last successful run: 2025-11-23 19:10:56
    Last failed run: 2025-11-02 23:14:45
    Restricted due to: none.
    Ready: false (job=false user=true !restricted=true !pending=true !active=true !backingup=true comp=true)

The "Run time" line will show the time range for the next run (somewhere between 3 to 9 hours in my example):

    Run time: earliest=+3h1m29s652ms, latest=+9h1m29s652ms, original latest=+9h1m29s652ms

The "Unsatisfied constraints" line can also be useful. If it's "TIMING_DELAY DEADLINE", then it's just waiting for the right time to run. If there are additional unsatisfied conditions (such as CONNECTIVITY for network connection), then Android won't allow Custota to run.

P.S.: IMHO it would be neat to let user specify the check frequency rather than letting android do this opaquely but that's my opinion :-)

Currently, Custota asks Android to schedule the check to run every 6 hours, but the "flex" window is set to the default value, which is equal to the interval. So each check could potentially run up to 3 hours early or 3 hours late.

Android allows this flex window to be reduced to 5%, which for a 6 hour interval would be an 18 minute window (up to 9 minutes early or 9 minutes late). It would allow the job run much closer to once every 6 hours. If this sounds useful, I can implement this.