Cosmin
După instalarea unui patch de securitate din aprilie 2026 pe un telefon cu Android 15, telefonul devine vizibil mai lent în primele ore de utilizare.
Ecranul de deblocare reacționează cu întârziere, notificările apar în rafale neregulate, iar bara de stare afișează intermitent pictograma de sincronizare fără nicio acțiune inițiată manual.
Temperatura dispozitivului crește ușor chiar și fără aplicații deschise, iar procentul bateriei scade cu o rată neobișnuită comparativ cu zilele anterioare actualizării. În setări, secțiunea dedicată bateriei arată un consum anormal ridicat pentru Servicii Google Play și pentru componente listate generic sub denumirea „Sistem Android”.
Comportamentul persistă și după repornire, dar se atenuează treptat pe parcursul a una până la trei zile. Simptomele seamănă cu cele ale unei aplicații care rulează necontrolat în fundal, doar că nu există nicio aplicație specifică responsabilă, ci un set de procese interne ale sistemului care reiau operații deja finalizate.
Ce se întâmplă cu telefonul după un patch de securitate
Un patch de securitate nu adaugă funcționalități noi, dar modifică semnăturile digitale ale unor componente de sistem, actualizează biblioteci criptografice și schimbă permisiuni interne la nivel de framework.
Când aceste modificări intră în vigoare după repornirea care finalizează instalarea, mai multe servicii de fundal detectează neconcordanțe între starea anterioară stocată în cache și starea curentă a sistemului.
Mecanismul care gestionează conturile sincronizate, cel care verifică integritatea aplicațiilor prin Google Play Protect și cel care reoptimizează codul compilat al aplicațiilior prin profilurile ART intră toate într un ciclu de reverificare.
Fiecare dintre aceste servicii operează independent și își menține propriile structuri de date. Modificarea unui singur certificat de securitate sau a unei politici SELinux este suficientă pentru a invalida starea considerată sigură de fiecare serviciu în parte.
Rezultatul este un val simultan de operații de verificare, recompilare și resincronizare care concurează pentru aceleași resurse hardware: procesor, memorie RAM și acces la stocare.
Servicii Google Play și revalidarea tokenurilor de autentificare
Serviciile Google Play reprezintă componenta cu cel mai vizibil impact în acest scenariu. După aplicarea patchului, modulul de gestionare a conturilor revalidează tokenurile OAuth asociate fiecărui cont Google configurat pe dispozitiv.
Reevalidarea implică comunicare repetată cu serverele Google, iar dacă telefonul are configurate mai multe conturi sau dacă sincronizarea automată este activă pentru multe aplicații conectate la aceste conturi, volumul de cereri de rețea crește semnificativ.
Simultan, modulul de verificare a licențelor recalculează starea fiecărei aplicații instalate prin Google Play Store. Fiecare aplicație primește o reverificare a semnăturii digitale și a compatibilității cu noul nivel de patch raportat de sistem.
Pe un smartphone cu 80 până la 120 de aplicații instalate, acest proces generează sute de operații de citire de pe stocare și zeci de cereri de rețea într un interval scurt. Consumul de baterie raportat pentru Servicii Google Play în primele 6 până la 12 ore după patch poate depăși 15 procente din totalul utilizat, un nivel care în mod obișnuit nu se atinge nici pe parcursul unei zile întregi.
De ce sistemul reia verificări deja terminate
Începând cu Android 13, sistemul utilizează compilare bazată pe profiluri prin runtime ul ART, iar aceste profiluri sunt stocate local pentru fiecare aplicație.
Un patch de securitate care modifică biblioteci partajate de sistem invalidează o parte din aceste profiluri, deoarece referințele interne către metodele de sistem nu mai corespund cu adresele reale din noile biblioteci. Serviciul bg-dexopt, responsabil cu reoptimizarea în fundal, repornește compilarea pentru toate aplicațiile afectate.
Acest proces este proiectat să ruleze exclusiv când dispozitivul este inactiv, conectat la un încărcător și cu un nivel de baterie suficient. Însă pe Android 14 și 15, logica de prioritizare permite execuția parțială și în afara acestor condiții, cu o prioritate redusă dar nu nulă.
Efectul concret este că procesorul nu revine complet în starea de consum minim nici în standby, iar gestionarea proceselor în standby nu poate dezactiva un serviciu de sistem marcat ca esențial. Tranziția către starea Doze este întârziată, ceea ce amplifică consumul de baterie în perioadele în care telefonul ar trebui să fie practic inactiv.
Cum ajung Serviciile Google Play să consume atât de mult
Setările de optimizare a bateriei și restricțiile de date în fundal, configurabile individual pentru fiecare aplicație, nu au efect asupra acestor procese de sistem. Serviciile implicate rulează sub identitatea de sistem sau sub pachete semnate cu cheia platformei, ceea ce le exceptează de la orice restricție aplicabilă aplicațiilor instalate de utilizator.
Nici dezactivarea sincronizării automate a contului Google, nici activarea modului de economisire a bateriei nu opresc ciclul de reverificare, deoarece acesta nu este clasificat ca sincronizare de date, ci ca proces de mentenanță internă.
Android System WebView, care primește frecvent actualizări independente prin Play Store, adaugă un strat suplimentar de complexitate.
Dacă versiunea de WebView instalată pe dispozitiv a fost și ea actualizată în aceeași perioadă cu patchul de securitate, componentele care depind de WebView pentru randarea conținutului web în aplicații non browser sunt și ele supuse reverificării. Acest lucru include panouri de notificare cu conținut dinamic, aplicații bancare care utilizează vizualizări web integrate și chiar porțiuni din interfața Google Play Store.
De ce setările de optimizare a bateriei nu schimbă nimic
Comportamentul repetitiv al serviciilor nu indică o defecțiune și nu necesită resetarea dispozitivului. Fiecare serviciu implicat are o condiție proprie de finalizare: bg-dexopt termină când toate profilurile sunt recompilate, Play Protect termină când toate aplicațiile sunt reverificate, iar sincronizarea conturilor se stabilizează după ce toate tokenurile primesc confirmarea de la servere.
Problema percepută de utilizator apare din cauza suprapunerii temporale a acestor procese, nu din cauza unui singur serviciu care funcționează greșit.
Durata până la normalizare depinde de numărul de aplicații instalate, de numărul de conturi configurate, de viteza conexiunii la internet și de cât de frecvent este telefonul conectat la un încărcător în stare de inactivitate.
Pe modelele cu stocare mai lentă de tip eMMC, întâlnite încă pe telefoane din gama de intrare lansate în 2024 și 2025, procesul de recompilare ART poate dura semnificativ mai mult decât pe modele cu stocare UFS 3.1 sau 4.0. Diferența poate fi de ordinul orelor, nu al minutelor, iar în tot acest interval consumul anormal de baterie și încetinirea generală rămân vizibile.
Comentarii (0)