Telefonul pierde conexiunea la internet pentru câteva secunde, pagina se încarcă parțial, o aplicație de streaming se oprește brusc și apoi totul revine la normal.
Scenariul acesta enervant se repetă mai ales în zone urbane aglomerate sau la marginea acoperirii unui operator, fără nicio acțiune din partea celui care folosește telefonul.
Ceea ce se întâmplă, de fapt, este o comutare automată între celulele rețelei mobile sau între tehnologiile de acces (de la 5G la LTE, de la LTE la 3G și invers), iar această tranziție nu este întotdeauna transparentă pentru aplicațiile care depind de o conexiune stabilă.
Modemul telefonului primește un semnal mai slab de la celula curentă, identifică o celulă vecină cu semnal mai bun și inițiază un handover.
Procesul acesta durează teoretic milisecunde, dar în practică introduce întreruperi detectabile la nivel de sesiune TCP, vizibile ca pauze de încărcare, reconectări sau erori temporare de rețea.
Cum funcționează handoverul la nivel de modem și sistem
Comutarea între celule este gestionată de modemul baseband al telefonului, o componentă hardware separată de procesorul principal, cu firmware propriu.
Când intensitatea semnalului de la celula curentă scade sub un prag definit de operator (de regulă, măsurat în dBm pentru putere și în dB pentru raportul semnal/zgomot), modemul solicită rețelei un handover către o celulă vecină.
Pe rețelele LTE, acest proces se numește handopver intra sau inter frecvență, în funcție de banda utilizată. Pe rețelele 5G NSA (Non Standalone), implementate de majoritatea operatorilor europeni și nord americani în 2025 și 2026, comutarea implică și o componentă de ancorare LTE, ceea ce adaugă un strat suplimentar de negociere între modem și rețea.
Android nu controlează direct acest proces. Sistemul de operare primește notificări de la modemul baseband prin intermediul Radio Interface Layer (RIL) și al Telephony Framework, dar decizia de comutare aparține firmware ului modemului și rețelei operatorului.
El gestionează este reacția la schimbarea stării conexiunii: actualizarea indicatorului de semnal din bara de stare, notificarea aplicațiilor prin ConnectivityManager și, eventual, comutarea între interfețele de rețea disponibile (date mobile, Wi-Fi, Ethernet).
Tranziția între tehnologii diferite și impactul asupra sesiunilor active
Problema devine vizibilă când comutarea nu se face între două celule de aceeași tehnologie, ci între tehnologii diferite. Trecerea de la 5G la LTE sau de la LTE la 3G implică schimbarea completă a stivei de protocoale radio, ceea ce presupune renegocierea conexiunii la nivel de rețea.
În acest interval, adresa IP atribuită telefonului se poate schimba, iar sesiunile TCP active sunt întrerupte. Aplicațiile care nu implementează mecanisme proprii de reconectare (retry logic) pierd pur și simplu conexiunea și afișează erori.
Pe telefoanele Samsung cu One UI 6.x și 7, modul de rețea setat pe „5G/LTE/3G/2G (conectare automată)” permite modemului să aleagă liber între toate tehnologiile disponibile. Setarea aceasta, accesibilă din meniul Conexiuni, Rețele mobile, Mod rețea, lasă decizia la latitudinea firmware ului Exynos sau Qualcomm, care aplică algoritmi proprii de selecție bazați pe intensitatea semnalului, încărcarea celulei și parametrii trimiși de operatorul de rețea.
Pe telefoanele Pixel cu Android 15 și Android 16 Developer Preview, comportamentul este similar, dar firmware ul modemului Tensor G4 și G5 are praguri diferite de comutare, ceea ce explică de ce același operator poate oferi stabilitate diferită pe dispozitive diferite.
Ce rol au Serviciile Google Play și gestionarea conexiunilor
Serviciile Google Play (Google Play Services) intermediază mai multe funcții legate de conectivitate, inclusiv sincronizarea contului Google, actualizarea tokenurilor de autentificare și funcționarea notificărilor push prin Firebase Cloud Messaging (FCM).
Când conexiunea de date se întrerupe din cauza unui handover prelungit, FCM pierde legătura cu serverele Google și intră într un ciclu de reconectare cu backoff elxponențial. Aplicațiile care depind de FCM pentru notificări (Gmail, WhatsApp, Telegram, aplicații bancare) nu mai primesc mesaje în timp real până când reconectarea nu se finalizează.
Android System WebView, componenta care redă conținut web în aplicațiile care nu folosesc browser propriu, este și ea afectată.
O pagină încărcată prin WebView într o aplicație de știri sau de e-commerce pierde conexiunea la resurse (CSS, JavaScript, imagini) în timpul tranziției, iar rezultatul este o pagină parțial afișată sau o eroare de tip ERR_CONNECTION_RESET. WebView nu reîncearcă automat încărcarea resurselor individuale; comportamentul depinde de modul în care dezvoltatorul aplicației a implementat gestionarea erorilor de rețea.
Optimizarea bateriei și restricțiile de date în fundal agravează efectul
Mecanismele de economisire a energiei din Android interacționează cu instabilitatea rețelei într un mod care amplifică problema. Optimizarea bateriei (Battery Optimization), activată implicit pentru majoritatea aplicațiilor, limitează activitatea de rețea a proceselor aflate în fundal.
Când o aplicație este restricționată prin App Standby Buckets (sistemul de clasificare introdus în Android 9 și rafinat constant până în Android 16), reconectarea după un handover eșuat este amânată. Aplicația nu mai poate iniția imediat o nouă conexiune de date, ci trebuie să aștepte fereastra de execuție alocată de sistem.
Restricțiile de date în fundal (Background Data Restriction), configurabile individual per aplicație din Setări, Aplicații, Utilizare date, adaugă un alt nivel de filtrare.
O aplicație cu date în fundal dezactivate nu poate reconecta sesiunea pierdută decât atunci când revine în prim plan. Combinația dintre un handover prelungit și aceste restricții produce un efect vizibil: aplicația pare că nu mai funcționează, deși rețeaua este deja restabilită.
Gestionarea proceselor în standby (Doze Mode) contribuie suplimentar, suspendând accesul la rețea în perioadele de inactivitate ale ecranului, ceea ce face ca reconectarea post handover să fie și mai lentă pe telefoanele care stau mult timp în buzunar cu ecranul stins.
Diferența de comportament între operatori și între firmware uri de modem
Operatorii de rețea configurează parametrii de hndover la nivel de infrastructură. Pragurile de comutare, listele de celule vecine și prioritățile între benzi de frecvență sunt transmise telefonului prin mesaje SIB (System Information Block) difuzate de fiecare celulă.
Un operator care prioritizează banda n78 (3.5 GHz) pentru 5G, dar are acoperire limitată pe această frecvență, va forța tranziții mai frecvente către LTE Band 3 sau Band 20 în zonele marginale. Operatorii cu spectru contiguu și densitate mare de celule (caracteristic piețelor din Coreea de Sud sau Japonia) produc handovere mai rapide și cu impact mai mic asupra stabilității.
Firmware ul modemului joacă un rol la fel de important. Qualcomm Snapdragon X75 și X80 (prezente în telefoane flagship din 2025 și 2026) implementează algoritmi de predicție a handoverului bazați pe istoricul de mobilitate al utilizatorului, ceea ce reduce numărul de comutări inutile.
MediaTek Dimensity 9400, folosit în segmentul premium al unor producători precum OPPO și vivo, aplică o strategie diferită, cu praguri mai agresive de revenire la LTE pentru conservarea bateriei.
Exynos 2500, prezent în anumite variante Samsung Galaxy S25 ș S26, a avut la lansare probleme documentate cu handoverul între benzi n78 și n1, rezolvate parțial prin actualizări de firmware distribuite ca patch uri de securitate lunare.
Aceste diferențe de implementare fac ca același traseu urban, parcurs cu două telefoane diferite pe același operator, să producă experiențe de conectivitate diferite. Cauza nu este acoperirea rețelei, ci modul în care fiecare modem interpretează și execută instrucțiunile de handover primite de la infrastructura operatorului.
Comentarii (0)