Google oznaczy w Play Store aplikacje nadmiernie zużywające baterię. Co to znaczy dla deweloperów i użytkowników?

Wprowadzenie do problemu / definicja luki

Google ogłosiło, iż wprowadzi do Sklepu Play ostrzeżenia dla aplikacji, które nadmiernie drenują baterię poprzez długotrwałe utrzymywanie partial wake locks (blokad uniemożliwiających uśpienie CPU przy wyłączonym ekranie). Nowa polityka opiera się na metryce “excessive partial wake locks” w Android Vitals i będzie wpływała zarówno na widoczność aplikacji, jak i komunikaty ostrzegawcze widoczne dla użytkowników na kartach aplikacji. Zmiany zaczną obowiązywać od 1 marca 2026 r..

W skrócie

• Nowa metryka Android Vitals: „excessive partial wake locks” mierzy sesje użytkownika, w których czas skumulowanych, nie-wyłączonych (non-exempt) wake locków > 2h w ciągu 24h. o ile ≥5% sesji z ostatnich 28 dni spełnia ten warunek, aplikacja przekracza próg „złego zachowania”.
• Skutki: aplikacja może zostać wyłączona z kluczowych powierzchni rekomendacyjnych Sklepu Play i/lub otrzyma czerwony komunikat ostrzegawczy na stronie listingu: iż „może zużywać więcej baterii niż oczekiwano z powodu wysokiej aktywności w tle”. Wejście w życie: 1.03.2026.
• Kto to wymyślił: metryka była w becie od kwietnia, a algorytm Google rozwijało wspólnie z Samsungiem; teraz jest GA.

Kontekst / historia / powiązania

Android od lat walczy z aplikacjami, które „przytrzymują” urządzenie w stanie aktywnym bez korzyści dla użytkownika. Wcześniej Google promowało praktyki ograniczania pracy w tle (JobScheduler/WorkManager) oraz monitorowania energii (Batterystats/Battery Historian). Nowa metryka włącza te zasady do twardego progu jakości technicznej Android Vitals — obok crash rate czy ANR rate — i wiąże je z algorytmiczną widocznością w Play. To zmienia rekomendacje w wymogi: zignorowanie problemu będzie miało realny wpływ na wzrost/instale.

Analiza techniczna / szczegóły metryki

Czym jest partial wake lock?
To mechanizm utrzymujący CPU w stanie aktywnym przy zgaszonym ekranie, aby aplikacja mogła wykonywać pracę w tle (np. synchronizację). Nadużywany — potrafi wyssać baterię w nocy.

Definicje Google dla metryki:

• Sesja użytkownika jest „excessive”, gdy >2h skumulowanych nie-wyłączonych partial wake locków w okresie 24h. Wyłączenia (exemptions) obejmują m.in. odtwarzanie audio czy transfer zainicjowany przez użytkownika.
• Próg złego zachowania: jeżeli ≥5% sesji z 28 dni jest „excessive”.
• Konsekwencje w Play: ograniczenie ekspozycji w discovery i możliwe publiczne ostrzeżenie na listingu aplikacji. Start egzekwowania: 1 marca 2026 r..

Jak Google wykrywa problem?
Zespół połączył dane platformy z „real-world insights” od Samsunga i feedbackiem deweloperów z bety (od kwietnia), kalibrując algorytm pod rzeczywiste wzorce drenażu.

Praktyczne konsekwencje / ryzyko

Dla deweloperów:

• Ryzyko spadku instalacji (mniejsza widoczność) i zaufania (ostrzeżenie na stronie aplikacji). Wzrośnie presja na audyt wake locków, SDK i bibliotek sieciowych.
• Potrzeba telemetrii i testów energetycznych na etapie CI/CD, a nie tylko QA manualnego. (Patrz sekcja „Co zrobić teraz”.)

Dla użytkowników:

• Lepsza przejrzystość — łatwiej rozpoznać „pożeracze baterii” przed instalacją.

Dla bezpieczeństwa (defensywnie):

• Choć Google podkreśla, iż to nie jest detektor spyware/adware, metryka pośrednio utrudni trwałe utrzymywanie kanałów exfiltracji w tle bez wiedzy użytkownika (ciągłe podtrzymywanie CPU stanie się kosztowne reputacyjnie). To wzmocni higienę energetyczną ekosystemu, powiązaną z dostępnością (CWE-920). (Wniosek + kontekst teoretyczny).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów developerskich

1. Skan wake locków po nazwach (tagach)
   • Wejdź w Play Console → Android Vitals → Excessive partial wake locks i przejrzyj nową tabelę wake lock names (P90/P99). Skup się na tagach z P90/P99 > 60 min.
2. Usuń manualne wake locki, zastąp pracą planowaną
   • Preferuj WorkManager/JobScheduler z warunkami (ładowanie, Wi-Fi) zamiast własnych wake locków.
   Kotlin (przykład): class SyncWorker(ctx: Context, params: WorkerParameters) : CoroutineWorker(ctx, params) { override suspend fun doWork(): Result { // ...realna praca sieciowa... return Result.success() } } val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresCharging(true) .build() val req = OneTimeWorkRequestBuilder<SyncWorker>() .setConstraints(constraints) .build() WorkManager.getInstance(context).enqueue(req)
3. Jeśli musisz użyć WakeLock — trzymaj go krótko i bezpiecznieval pm = context.getSystemService(Context.POWER_SERVICE) as PowerManager val wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "app:shortTask") try { wl.acquire(30_000L) // maks. 30s – twardy limit! doShortTask() } finally { if (wl.isHeld) wl.release() }
   • Nigdy nie trzymaj wake locka „na wszelki wypadek”; zawsze czasowo ograniczaj i zwalniaj w finally.
4. Ogranicz czujniki i sieć
   • Używaj FusedLocationProvider (batching, caching), grupuj transfery danych, stosuj backoff/retries przez WorkManager.
5. Włącz testy energetyczne w CI
   • Profilowanie dzięki Batterystats + Battery Historian: # reset licznika adb shell dumpsys batterystats --reset # uruchom scenariusz testowy ... # zrzut do pliku adb shell dumpsys batterystats > /sdcard/bstats.txt adb pull /sdcard/bstats.txt .
     • W pipeline uruchamiaj scenariusze (np. 30–60 min w tle), parsuj metryki wake locków po tagach.
   • Bugreport → Historian (HTML): adb bugreport bug.zip # otwórz w Battery Historian i sprawdź wakelocki/alarms/sync
6. Audyt bibliotek/SDK
   • Przeglądaj wake lock tags powiązane z bibliotekami reklamowymi, analitycznymi, VoIP, I/O. Wymagaj wersji z batchingiem/limitami.
7. Definiuj SLO energetyczne
   • Ustalcie SLO: „<1% sesji excessive w 28d” + alert w monitoringu, gate w CI (blokada releasu, o ile trend rośnie).

Dla zespołów bezpieczeństwa (SecOps/Blue)

• Anomalie energii jako sygnał: Nadzwyczajny wzrost wake locków może korelować z niedozwolonym monitoringiem lub nadużyciem SDK. Integruj sygnały z Vitals do SIEM/UBA.
• Polityki MDM/EMM: W środowiskach korporacyjnych — blokuj aplikacje, które dostają ostrzeżenie Sklepu Play; wymuś allow-listy.
• Testy red team: W scenariuszach DLP/Exfil — sprawdź, czy agent nie generuje excessive wake locks (weryfikowalne w Vitals).

Różnice / porównania z innymi przypadkami

• Wear OS – ostrzeżenia dla tarcz zegarków: Google wcześniej dodało w Play ostrzeżenia o drenażu w watch faces (osobna metryka dla zegarków). Nowa inicjatywa rozszerza podejście na aplikacje telefoniczne z naciskiem na partial wake locks. (Kontekst techniczny; praktyki oszczędzania energii są spójne).
• Tradycyjne wskaźniki jakości (crash/ANR) vs. energia: Do tej pory brakowało „twardego” progu dla energii. Teraz „excessive partial wake locks” dołącza do „technical quality bars” i ma bezpośredni wpływ na ranking w Play.

Podsumowanie / najważniejsze wnioski

• Od 1 marca 2026 r. aplikacje przekraczające próg excessive partial wake locks mogą stracić ekspozycję i dostać czerwone ostrzeżenie na karcie w Play.
• Metryka: >2h non-exempt wake locków/24h w ≥5% sesji (28 dni).
• Deweloperzy powinni usunąć manualne wake locki, przejść na WorkManager/JobScheduler, zintegrować Batterystats/Historian i monitorować tagi w Android Vitals.
• Z perspektywy bezpieczeństwa poprawi się higiena energetyczna, co utrudni nadużycia tła, choć metryka nie jest skanerem malware.

Źródła / bibliografia

1. Android Developers Blog – „Raising the bar on battery performance: excessive partial wake locks metric is now out of beta” (szczegóły progu, wpływ na widoczność, data 1.03.2026). (Android Developers Blog)
2. BleepingComputer – „Google to flag Android apps with excessive battery use on the Play Store” (podsumowanie, beta od kwietnia, kooperacja z Samsungiem). (BleepingComputer)
3. 9to5Google – „Google Play will soon warn about apps that cause excessive battery drain” (cytaty definicji, ostrzeżenie na listingu). (9to5Google)
4. The Verge – „Google Play will label apps that use ‘excessive’ battery in the background” (termin egzekwowania, ograniczenie rekomendacji). (The Verge)
5. Android Developers – „Battery consumption for billions” (best practices: FusedLocation, batching, WorkManager, Batterystats/Historian). (Android Developers)