Cosmin
După actualizarea unei aplicații, pe ecran apare din nou fereastra care solicită acces la cameră, locație sau stocare. Aplicația fusese deja autorizată, permisiunile fuseseră acordate cu luni în urmă, iar acum sistemul le cere ca și cum ar fi o instalare proaspătă. Comportamentul apare frecvent pe dispozitive precum Samsung Galaxy A54 cu Android 14 sau Pixel 7a cu Android 15, unde utilizatorul observă că o aplicație actualizată solicită aceleași permisiuni pe care le primise anterior.
Fereastra de permisiuni nu vine de la aplicație în sine, ci de la sistemul de operare. Android gestionează independent autorizările, iar în anumite condiții, o actualizare poate declanșa o nouă solicitare, chiar dacă aplicația avea deja acces la resursele respective.
Ce se întâmplă în sistem la nivel de permisiuni
El tratează permisiunile ca autorizări granulare, legate de identitatea aplicației și de versiunea API targetată. Fiecare aplicație are un manifest care declară ce permisiuni solicită, iar sistemul verifică la runtime dacă utilizatorul a acordat sau nu accesul. Când o aplicație primește un update, sistemul revalidează manifestul și compară permisiunile declarate cu cele existente în baza de date internă a dispozitivului.
Dacă dezvoltatorul adaugă o permisiune nouă în manifest sau modifică modul în care o permisiune existentă este declarată, Android tratează solicitarea ca pe una nouă. Sistemul nu presupune că utilizatorul dorește să extindă automat accesul doar pentru că a acceptat anterior o permisiune similară.
Mecanismul targetSdkVersion și impactul asupra permisiunilor
Fiecare aplicație declară în manifest un targetSdkVersion, care indică versiunea pentru care a fost optimizată. Când un dezvoltator actualizează targetSdkVersion la o versiune mai recentă, se aplica reguli de permisiuni diferite. Permisiuni care anterior erau acordate implicit sau grupate pot deveni granulare și necesită aprobare separată.
Un exemplu concret: accesul la locație. Până la Android 10, o singură permisiune acoperea accesul la locație. Din Android 10, sistemul separă accesul în foreground și background. Dacă o aplicație își actualizează targetSdkVersion de la 28 la 33, sistemul de operare va solicita din nou permisiunea pentru locație în background, chiar dacă utilizatorul acordase anterior acces complet la locație.
Semnătura aplicației și identitatea în sistem
Android identifică aplicațiile printr-o combinație de nume de pachet și semnătură criptografică. Permisiunile sunt stocate în baza de date a sistemului, asociate cu această identitate. În situații rare, dacă semnătura aplicației se modifică între versiuni, sistemul tratează update-ul ca pe o instalare nouă.
Scenariuul apare când dezvoltatorul schimbă cheia de semnare sau când utilizatorul instalează o versiune din altă sursă decât cea originală. Google Play Store și alte magazine de aplicații validează consistența semnăturii, dar instalările din surse necunoscute pot ocoli această verificare.
Când identitatea criptografică nu se potrivește, Android revocă toate permisiunile acordate anterior și solicită reautorizare completă. Comportamentul protejează utilizatorul împotriva înlocuirii frauduloase a aplicațiilor, ceea ce este normal.
Permisiuni runtime versus permisiuni la instalare
Diferențiază între permisiuni normale, acordate automat la instalare, și permisiuni periculoase, care necesită aprobare explicită la runtime. Permisiunile periculoase includ accesul la cameră, microfon, contacte, locație, stocare și senzori corporali.
Un update care adaugă o nouă permisiune periculoasă va declanșa întotdeauna o solicitare la runtime, indiferent de istoricul aplicației. Sistemul nu poate presupune că utilizatorul dorește să acorde acces la cameră doar pentru că anterior acordase acces la stocare.
Permisiunile normale, precum accesul la internet sau verificarea stării rețelei, nu generează dialoguri de confirmare. Acestea sunt acordate automat dacă sunt declarate în manifest.
Contextul în care apare comportamentul
Solicitarea repetată de permisiuni se manifestă în câteva scenarii specifice. Primul și cel mai frecvent: dezvoltatorul actualizează targetSdkVersion pentru a respecta cerințele Google Play, care impune periodic versiuni minime pentru aplicațiile publicate. Această actualizare poate activa noi restricții de permisiuni introduse în versiunile recente de Android.
Al doilea scenariu implică adăugarea de funcționalități noi. O aplicație de mesagerie care adaugă funcția de apeluri video va solicita acces la cameră și microfon, chiar dacă anterior folosea doar stocarea pentru atașamente.
Al treilea context apare după actualizări majore ale sistemului de operare. Când telefonul sau tableta primește o nouă versiune Android, sistemul poate reseta sau revalida anumite permisiuni, în special cele considerate sensibile precum accesul la locație în background sau la fișiere media.
De ce sistemul nu păstrează automat permisiunile anterioare
Modelul de securitate prioritizează consimțământul informat al utilizatorului. Sistemul presupune că orice schimbare în cerințele de acces merită o nouă confirmare, chiar dacă utilizatorul acordase anterior permisiuni similare.
O aplicație nu poate obține acces la resurse noi fără ca utilizatorul să fie notificat explicit. Mecanismul protejează împotriva actualizărilor care ar putea adăuga funcționalități de supraveghere sau colectare de date fără consimțământ.
Android menține un jurnal intern al permisiunilor acordate, dar acest jurnal este legat de versiunea specifică a manifestului. Când manifestul se modifică, sistemul compară noua configurație cuu cea anterioară și solicită aprobare pentru orice diferență detectată.
Comportamentul în cazul permisiunilor revocate automat
Din Android 11, sistemul poate revoca automat permisiunile pentru aplicații neutilizate pe perioade extinse. Dacă o aplicație nu a fost deschisă timp de câteva luni, poate elimina permisiunile acordate anterior pentru a reduce riscurile de securitate.
Când deschideți din nou aplicația după o astfel de revocare automată, aceasta va solicita permisiunile ca și cum ar fi o instalare nouă. Comportamentul nu este legat de un update, ci de politica sistemului de a limita accesul aplicațiilor inactive la resurse sensibile.
Setările de sistem permit dezactivarea acestei funcții pentru aplicații individuale, dar implicit sistemulde operare aplică revocarea automată pentru toate aplicațiile care targetează Android 11 sau versiuni ulterioare.
Comentarii (0)