Doze Mode: суштина, фазе и механизам уштеде енергије

Шта је Doze Mode

Doze Mode је уграђени механизам уштеде енергије у Android-у, који се активира када уређај није прикључен на пуњач, екран је искључен и корисник не интерагује са уређајем одређено време. Циљ Doze-а је да минимизира позадинску активност апликација како би максимално продужио век батерије у режиму приправности. Систем одлаже JobScheduler, синхронизацију налога, AlarmManager и мрежне захтеве.

Режим је представљен у Android 6.0 Marshmallow (API 23) и значајно је унапређен у каснијим верзијама. У Android 7.0 Nougat појавила се друга фаза (Light Doze), која се активира при покрету уређаја. Android 8.0 увео је додатна ограничења на позадинске сервисе који раде у пару са Doze-ом. У Android 12+, Doze је интегрисан са ажурираним системом управљања батеријом, који анализира понашање корисника.

Важно је разумети: Doze Mode не искључује апликације у потпуности. Пребацује их у стање са одложеним задацима, али не убија процесе. Foreground Service са обавештењем наставља да ради, push обавештења високог приоритета (FCM high-priority) се достављају, а аларми се покрећу по распореду. Doze утиче само на позадинске операције које корисник не види и не очекује у датом тренутку.

Услови активације

Doze Mode се активира када су испуњени сви услови: екран искључен преко 30 минута (прва активација), уређај непомичан (користи се акцелерометар), није прикључен на пуњач. Ако корисник узме телефон у руке или прикључи пуњач, Doze се одмах деактивира. У Android 7+, Light Doze се активира већ након 5 минута неактивности, чак и при покрету уређаја.

Како ради Doze Mode

Doze Mode управља позадинском активношћу кроз системски сервис DeviceIdleController, који анализира стање сензора, екрана и пуњача. Када су сви услови активације испуњени, систем пребацује апликације у режим чекања, групишући њихове захтеве у прозоре сервиса. Унутар ових прозора, сви одложени задаци — мрежни позиви, синхронизација, AlarmManager — извршавају се у групама.

Системски PowerManager контролише које апликације могу да изађу из Doze-а. Push обавештења високог приоритета (FCM high-priority) могу да пробуде уређај за доставу поруке. Систем такође игнорише Doze за апликације које је корисник додао у Whitelist оптимизације батерије. Све остале апликације морају да сачекају следећи прозор сервиса.

Трајање прозора сервиса у Deep Doze-у се повећава експоненцијално: први прозор након 1 сата, други након 2 сата, трећи након 4 сата и тако даље до максималног интервала од 12 сати. То значи да што дуже уређај остаје у Doze-у, то ређе апликације могу да извршавају позадинске задатке — батерија се штеди максимално агресивно.

Утицај на мрежне захтеве

У Doze Mode-у, сви мрежни захтеви се суспендују до наступа прозора сервиса. Изузетак су само FCM high-priority поруке (са ознаком „high_priority” у payload-у) и сигнали из AlarmManager-а са заставицама setAndAllowWhileIdle() или setExactAndAllowWhileIdle(). Обични мрежни позиви путем Retrofit-а, OkHttp-а или Volley-а неће бити извршени док се прозор не отвори.

Фазе Doze Mode-а

Doze Mode се састоји из две фазе: Light Doze (лак сан) и Deep Doze (дубок сан). Свака фаза намеће своја ограничења и има различите прагове активације. Разумевање разлике између фаза је кључно за програмера који пројектује позадинске задатке отпорне на режим уштеде енергије.

Light Doze (лак сан)

Light Doze се активира након 5–30 минута неактивности уређаја (екран искључен, без покрета). У овој фази, мрежни захтеви и синхронизација се суспендују, али AlarmManager и JobScheduler настављају да раде са малим закашњењима. Апликације могу да изађу из Light Doze-а при пријему push обавештења или при прикључивању на пуњач. Light Doze не захтева потпуну непомичност — уређај може да се креће.

Deep Doze (дубок сан)

Deep Doze наступа након 60–90 минута неактивности са непомичним уређајем (акцелерометар не бележи покрете). У Deep Doze-у, систем значајно агресивније одлаже задатке: прозори сервиса се отварају ређе (са експоненцијалним повећањем интервала), AlarmManager се покреће само са заставицама setAndAllowWhileIdle(), а WakeLock не ради у уобичајеном режиму. Апликације које нису у Whitelist-у готово потпуно губе позадинску активност.

Ограничења при Doze Mode-у

Doze Mode намеће неколико категорија ограничења које програмер мора узети у обзир при пројектовању апликације. Игнорисање ових ограничења доводи до тога да се позадински задаци не извршавају, а корисник види неисправан рад апликације — недостатак ажурирања, непослате поруке, неизвршену синхронизацију.

Мрежна ограничења

Сви мрежни захтеви се блокирају до наступа прозора сервиса. Ово се односи на HTTP позиве, WebSocket конекције, преузимање датотека. Изузетак — FCM high-priority поруке, које пролазе кроз посебан канал Google Play Services, независан од Doze-а. За синхронизацију критичних података препоручује се коришћење WorkManager-а са политиком NetworkType.CONNECTED.

Ограничења AlarmManager-а

AlarmManager у Deep Doze-у одлаже све аларме, осим оних креираних методама setAndAllowWhileIdle() и setExactAndAllowWhileIdle(). Међутим, чак и ове методе имају ограничење — не више од 1 активације на 9 минута по апликацији. Тачни аларми setExact() у Deep Doze-у не гарантују активацију у задато време.

Ограничења WakeLock-а

WakeLock у Doze Mode-у ради нестандардно: систем не одржава блокаду спавања за апликације ван Whitelist-а. Чак и ако је апликација исправно ухватила PARTIAL_WAKE_LOCK, при наступу Deep Doze-а систем може принудно да га ослободи. Једини начин да се гарантује извршење задатка у Doze-у је коришћење Foreground Service-а са обавештењем.

• Мрежа — сви захтеви одложени до прозора сервиса, осим FCM high-priority
• AlarmManager — тачни аларми се одлажу; setAndAllowWhileIdle — не чешће од 1/9 мин
• WakeLock — принудно се ослобађа за апликације ван Whitelist-а
• JobScheduler — задаци се групишу у прозоре сервиса са експоненцијалним интервалом
• Синхронизација — Account SyncManager се суспендује до изласка из Doze-а

Whitelist и изузеци

Whitelist (бела листа) Doze-а је списак апликација којима систем дозвољава позадинску активност у режиму уштеде енергије са минималним ограничењима. Корисник може ручно да додаје апликације у листу кроз Подешавања → Батерија → Оптимизација батерије. Системске апликације, лансери и Google Play Services се налазе у Whitelist-у подразумевано.

Програмер може да затражи додавање у Whitelist кроз системски дијалог са Intent-ом ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. За то је у манифесту потребна дозвола REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Међутим, Google не препоручује захтевање изузетка без ваљаног разлога — апликације које злоупотребљавају ову могућност ризикују да буду одбијене при објављивању на Google Play-у.

Без Whitelist-а, апликација може да користи FCM high-priority за буђење уређаја из Doze-а. Свака таква порука даје апликацији кратак прозор (10–30 секунди) за извршење задатка. За дуже операције, апликација треба да покрене Foreground Service, који ће наставити рад у прозорима сервиса Doze-а. Google такође пружа механизам изузећа за одређене типове апликација: навигационе, медицинске, месинџере.

Како проверити статус Whitelist-а

За проверу да ли се апликација налази у Whitelist-у оптимизације батерије, користи се метода powerManager.isIgnoringBatteryOptimizations(). Ако метода враћа false, апликација се повинује свим ограничењима Doze-а. Ако true — апликација може да користи Wakelock, AlarmManager и мрежу без ограничења чак и у Deep Doze-у. Међутим, злоупотреба ове привилегије довешће до лоших оцена корисника.

Тестирање Doze Mode-а

Тестирање понашања апликације у Doze Mode-у је обавезна фаза развоја, јер Doze може да поремети позадинске функције. Android пружа алатке командне линије кроз ADB за принудно пребацивање уређаја у Light Doze и Deep Doze. Тестирање се мора обавити на физичком уређају или емулатору са Android 6.0+.

За улазак у Light Doze користи се команда adb shell dumpsys deviceidle step light. За Deep Doze — adb shell dumpsys deviceidle step deep. Команда adb shell dumpsys deviceidle force-idle deep одмах пребацује уређај у Deep Doze без чекања стандардног временског ограничења. Након тестирања, Doze се искључује командом adb shell dumpsys deviceidle unforce.

# Принудни улазак у Light Doze
$ adb shell dumpsys deviceidle step light

# Принудни улазак у Deep Doze
$ adb shell dumpsys deviceidle step deep

# Тренутни прелазак у Deep Doze
$ adb shell dumpsys deviceidle force-idle deep

# Излазак из Doze-а
$ adb shell dumpsys deviceidle unforce

# Преглед статуса Doze-а
$ adb shell dumpsys deviceidle

Провера рада апликације

Након пребацивања у Doze Mode, потребно је проверити: да ли мрежни захтеви раде (треба да буду одложени), да ли се AlarmManager покреће, да ли се FCM поруке достављају, да ли се задаци WorkManager-а исправно извршавају. WorkManager у Doze-у наставља да ради: његови задаци се извршавају у прозорима сервиса. Међутим, ако задатак захтева тренутно извршење, потребно је навести setExpedited() или користити Foreground Service.

Најбоље праксе за Doze Mode

Развој апликације отпорне на Doze Mode захтева преиспитивање приступа позадинским задацима. Google препоручује пројектовање апликације тако да исправно ради при било којим ограничењима Doze-а, не ослањајући се на тренутно извршење позадинских операција. Основни принцип — користити WorkManager за све позадинске задатке који могу бити одложени.

Користите WorkManager

WorkManager је препоручени Google API за позадинске задатке, јер се аутоматски прилагођава Doze-у. WorkManager користи JobScheduler (API 23+) или AlarmManager + BroadcastReceiver на старијим верзијама. Задаци WorkManager-а се извршавају у најближем прозору сервиса Doze-а, а по потреби — одмах кроз Expedited Work (Foreground Service испод хаубе).

Foreground Service за критичне задатке

Ако задатак не може бити одложен (репродукција медија, навигација, VoIP), користите Foreground Service са обавезним обавештењем. Foreground Service добија изузетак из Doze-а: може да одржава WakeLock и извршава мрежне захтеве. Међутим, чак и Foreground Service се повинује политици прозора сервиса Deep Doze-а за неке типове задатака — на пример, dataSync.

FCM high-priority за обавештења

За доставу порука које захтевају тренутну пажњу (долазни позив, хитно обавештење), користите FCM high-priority поруке. Такве поруке буде уређај из Doze-а и дају апликацији кратак прозор за обраду. Немојте користити high-priority за обична обавештења — то ће довести до брзог пражњења батерије и може бити протумачено од стране Google Play-а као кршење политике.

• WorkManager — пожељни API за све одложене позадинске задатке
• Foreground Service — за критичне задатке са видљивим обавештењем
• FCM high-priority — за доставу хитних порука са буђењем уређаја
• Не тражите Whitelist без крајње потребе — погоршава корисничко искуство
• Тестирајте апликацију у Light и Deep Doze-у кроз ADB пре објављивања