Cosmin
Un Galaxy S24 cu Android 15 și patch ul de securitate din martie 2026 începe să se restarteze singur la intervale aparent aleatorii. Telefonul funcționează normal câteva ore, apoi ecranul se stinge brusc, apare logo ul Samsung și sistemul pornește din nou.
Repornirea nu este uurmata de vreo eroare vizibilă, nu apare niciun mesaj de avertizare și nu se simte o încălzire deosebită a carcasei. Evenimentul se repetă de două, trei ori pe zi, uneori în standby, alteori în timp ce o aplicație rulează în prim plan.
În jurnalul de sistem, accesibil prin meniul de diagnosticare, apar intrări marcate ca „kernel panic” sau „watchdog reset”, ceea ce indică faptul că nucleul sistemului a detectat un blocaj intern pe care nu l a putut rezolva altfel decât prin repornire forțată.
Comportamentul a început strict după instalarea celui mai recent patch de securitate, fără alte modificări în configurație sau în aplicațiile instalate.
Ce rol are mecanismul watchdog în repornirea forțată
Android folosește mai multe niveluri de supraveghere internă pentru a preveni blocarea completă a sistemului. Cel mai relevant dintre acestea este procesul watchdog, care monitorizează continuu răspunsul serviciilor critice din system_server.
Dacă un serviciu esențial, cum ar fi WindowManagerService sau ActivityManagerService, nu răspunde într un interval prestabilit, de regulă între 30 și 60 de secunde, watchdog ul consideră că sistemul a intrat într o stare irecuperabilă. Răspunsul automat este o repornire forțată, fără intervenția utilizatorului și fără vreo notificare prealabilă.
Acest mecanism nu este un defect, ci un comportament proiectat deliberat. Scopul său este să prevină situațiile în care telefonul rămâne blocat complet, fără reacție la atingere sau la butoane. Din perspectiva utilizatorului, efectul arată identic cu o repornire aleatorie, dar cauza reală este un blocaj al unui serviciu intern pe care sistemul nu l a putut debloca în timp util.
Servicii de sistem implicate în blocajele care provoacă restartul
Procesul central al Android, numit system_server, gestionează zeci de servicii care rulează simultan. Printre cele mai solicitate se numără PackageManagerService, responsabil cu evidența aplicațiilor instalate, și PowerManagerService, care controlează stările de repaus și trezire ale dispozitivului.
Un al treilea serviciu frecvent implicat este ActivityManagerService, cel care decide ce aplicație rulează în prim plan și care procese din fundal trebuie oprite pentru a elibera memorie.
După un patch de securitate, aceste servicii pot primi actualizări la nivelul dependențelor lor interne. O bibliotecă de sistem actualizată care intră în conflict cu o versiune anterioară a unui driver hardware sau cu un modul al producătorului poate genera un deadlock, adică o situație în care două fire de execuție se blochează reciproc, fiecare așteptând ca celălalt să elibereze o resursă.
Watchdog ul (E un proces de supraveghere care rulează permanent în fundal pe Android.) detectează tocmai acest tip de impas și forțează repornirea.
Serviciile Google Play, care au propriul ciclu de actualizare independent de patch urile de securitate, adaugă un strat suplimentar de complexitate.
Modulul Google Play Services funcționează ca un intermediar între aplicații și funcțiile de sistem, iar o versiune nouă a acestui modul poate modifica modul în care interacționează cu serviciile din system_server, crescând riscul de blocaje temporare.
De ce comportamentul apare după o actualizare de securitate
Patch urile de securitate lunare nu modifică doar componente vizibile ale interfeței. Ele actualizează kernel ul, driverele pentru modem, modulul de criptare, politicile SELinux și alte elemente care funcționează la niveluri foarte joase ale sistemului.
O modificare în politicile SELinux, spre exemplu, poate restricționa accesul unui serviciu la o resursă pe care anterior o folosea fără restricții. Serviciul continuă să solicite acea resursă, primește un refuz, încearcă din nou și intră într o buclă care consumă timp de procesor până când watchdog ul intervine.
Samsung, Xiaomi, Google Pixel și ceilalți producători aplică propriile modificări peste patch ul de bază primit de la Google prin Android Open Source Project.
Aceste straturi suplimentare, numite generic vendor overlay, pot conține drivere actualizate incomplet sau module care nu au fost testate cu noua versiune a kernel ului. Pe un Pixel 9 Pro, unde Google controlează atât software ul cât și hardware ul, riscul de incompatibilitate este mai mic.
Pe dispozitive cu chipset MediaTek Dimensity sau Qualcomm Snapdragon de generație anterioară, diferența dintre driverul actualizat și firmware ul modemului rămas la versiunea veche poate genera exact tipul de kernel panic vizibil în jurnalele de sistem.
Diferența dintre restartul în standby și restartul în utilizare activă
Restartul care apare în timp ce telefonul este în standby are de obicei o cauză diferită față de cel care apare în timpul utilizării active. În standby, Android trece prin cicluri regulate de trezire parțială, numite wakelock uri, în care sistemul pornește temporar procesorul pentru a sincroniza conturi, a verifica notificări sau a executa sarcini programate prin JobScheduler.
Dacă în timpul unei astfel de treziri un serviciu intră în conflict cu un altul, blocajul apare fără ca utilizatorul să observe vreo activitate pe ecran. Telefonul pur și simplu se restartează și revine pe ecranul de blocare.
Restartul din timpul utilizării active este mai frecvent legat de presiunea pe memorie. Android gestionează memoria RAM prin mecanismul LowMemoryKiller, care oprește procese din fundal atunci când memoria disponibilă scade sub un prag critic.
Dacă o aplicație din prim plan solicită rapid cantități mari de memorie, iar LowMemoryKiller nu reușește să elibereze suficientă memorie RAM la timp, system_server poate rămâne fără resursele necesare pentru a răspunde la interogările watchdog ului. Rezultatul este același: repornire forțată.
Procese din fundal care amplifică riscul de restart
Optimizarea bateriei din Android 15 controlează ce aplicații au voie să ruleze în fundal și cât de des pot face acest lucru. Aplicațiile restricționate la nivel de fundal primesc ferestre foarte scurte de execuție, iar dacă nu își finalizează operațiunile în acel interval, procesele lor sunt oprite forțat.
Această oprire repetată și repornire a proceselor generează o încărcare suplimentară asupra ActivityManagerService, care trebuie să gestioneze fiecare tranziție.
Un alt factor este sincronizarea conturilor. Conturile Google, Samsung sau ale altor servicii au intervale proprii de sincronizare, iar atunci când mai multe conturi încearcă să se sincronizeze simultan într o fereastră de trezire, volumul de operații I/O pe stocarea internă crește brusc.
Pe telefoanele cu stocare aproape plină, unde viteza de scriere scade din cauza lipsei de blocuri libere, acest vârf de activitate poate întârzia răspunsul system_server ului suficient încât watchdog ul să intervină.
Android System WebView, componenta care permite aplicațiilor să afișeze conținut web intern, are și ea un rol indirect. Actualizarea acestei componente prin Google Play Store modifică motorul de randare pentru toate aplicațiile care o folosesc.
O versiune nouă de WebView care consumă mai multă memorie sau care are un defect în gestionarea firelor de execuție poate destabiliza aplicațiile care o încarcă în fundal, adăugând presiune pe resursele de sistem exact în momentele vulnerabile.
Comentarii (0)