Spațiul de stocare în Android Q îi obligă pe dezvoltatori să folosească SAF, ceea ce este nasol

Schimbările în domeniul stocării în Android Q sunt o durere de cap de rezolvat, deoarece cadrul de acces la stocare are câteva defecte în acest moment.

Android Q schimbă fundamental modul în care funcționează stocarea pe telefon. În fiecare versiune până la Pie, stocarea Android a funcționat ca un computer desktop: puteți folosi orice aplicație pe care doriți să citiți sau să scrieți orice fișier (dacă acordați permisiunea unei aplicații pentru a face acest lucru). Cu Q, Google introduce (și solicită) "Spațiu de stocare”, ceea ce face ca Androidul să funcționeze mai mult ca un iPhone, unde spațiul de stocare este izolat de fiecare aplicație. O aplicație poate accesa doar propriile fișiere și, dacă este dezinstalată, toate fișierele sale sunt șterse.

Din fericire, Android Q păstrează încă o parte din comportamentul original al unui sistem de fișiere central al Android. Din păcate, acum este greoi pentru utilizator să configureze aplicații pentru a-l accesa și a redus semnificativ performanța și capacitatea. Și dezvoltatorii vor trebui să recodeze substanțial aplicațiile pentru a le susține.

Aplicațiile care necesită acces general la sistemul de fișiere, de ex. o suită de birou, un editor de imagini sau un manager de fișiere, va trebui acum să utilizeze un API Android numit "Cadrul de acces la stocare" (SAF), pentru toate operațiunile cu fișiere. SAF este disponibil începând cu Android 5.0 Lollipop, dar dezvoltatorii tind să nu-l folosească decât dacă este necesar, deoarece are o soluție dificilă și slabă. API documentat, o experiență de utilizator slabă, performanță slabă și fiabilitate slabă (în mare parte sub forma implementării specifice furnizorului de dispozitive probleme). Ca urmare a dificultății de a trece la SAF, Google a decis să permită aplicațiile care nu indică încă Suportul Android Q să funcționeze așa cum era înainte, dar acest lucru se va schimba atunci când Magazinul Play va solicita ca toate aplicațiile să accepte Q anul urmator.

Cea mai evidentă schimbare pentru utilizatori cu SAF este experiența de a acorda unei aplicații acces la spațiu de stocare. Pentru ca o aplicație să aibă acces, aceasta face o solicitare către sistemul de operare, care apoi afișează un ecran de selectare a directorului. Pe acest ecran, utilizatorul selectează rădăcina unei ierarhii de foldere în care acea aplicație va putea să citească și să scrie fișiere. Utilizatorul trebuie să parcurgă acest proces pentru fiecare aplicație care necesită acces la fișiere locale sau de două ori pe aplicație dacă trebuie să îi acorde și acces la un card SD extern.

Google a îmbunătățit cel puțin acest proces pentru Q beta 3, deoarece beta-urile anterioare nu permiteau unei aplicații să sugereze nici măcar o locație pe care utilizatorul să o selecteze, care a cerut utilizatorului să facă destul de multă muncă pentru a găsi de fapt spațiul de stocare principal al dispozitivului lor.

Performanța fișierelor I/O este oarecum afectată în SAF, dar cea mai importantă problemă constă în fișier operațiuni de director, unde este de ~25 până la 50 de ori mai lent decât accesul convențional la fișiere posibil în Plăcintă. În cazul managerilor de fișiere, asta înseamnă că va dura mai mult timp pentru a efectua căutări și calcule privind utilizarea stocării. Un raport de eroare cu o aplicație demonstrativă este disponibil aici.

Exemplu de testare a SAFTest care arată diferența de performanță dintre API-ul de I/O de fișiere convențional cu SAF.

O problemă de performanță și mai mare este că unele aplicații vor trebui să copieze fișiere în zona lor locală de „stocare în domeniu” înainte de a putea lucra cu ele. Acest lucru poate fi problematic atunci când astfel de fișiere au o dimensiune de mai mulți gigaocteți, de ex. în cazul fișierelor video sau arhivelor comprimate. Multe aplicații Android profită de numărul uimitor de biblioteci Java open-source din comunitatea dezvoltatorilor, iar aceste biblioteci necesită de obicei acces direct la sistemul de fișiere pentru a funcționa. Nu sunt specifice pentru Android și ar necesita rescriere pentru a funcționa cu SAF. Și mai rău, multe dintre bibliotecile interne ale Android nu vor funcționa cu acesta, cum ar fi managerul de pachete sau API-ul zip. De exemplu, un manager de fișiere nici măcar nu va putea afișa pictograma pentru un fișier APK (folosind API-ul Android standard) fără a copia mai întâi întregul APK în propria sa zonă de stocare. Raport de eroare.

Pentru cei înclinați din punct de vedere tehnic, este în prezent posibil să dezactivați „Scoped Storage” Android Q pe bază de aplicație prin ADB folosind o comandă apps. Utilizatorii root pot executa comenzile direct pe dispozitivul lor, fără un computer desktop. Astfel de comenzi sunt descrise în documentație ca caracteristici pentru dezvoltatori și, prin urmare, pot fi eliminate în orice moment.

Activați accesul la stocarea generală pentru o aplicație:

adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-name

Dezactivați accesul general la stocare pentru o aplicație:

adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-name

Google promovează avantajele de securitate și confidențialitate ale acestei schimbări, dar din punct de vedere tehnic, nu există nicio îmbunătățire. Aplicațiile au capacitatea de a stoca fișiere în mod privat începând cu Android 1.0 și aproape toate aplicațiile folosesc această capacitate. Când acordați unei aplicații acces la directorul rădăcină al spațiului de stocare prin SAF, aceasta poate citi, scrie și trimite orice fișier. dorește dezvoltatorului său nefast exact în același mod în care ar fi făcut-o atunci când ați acordat unei aplicații acces la stocarea în Pie.

Singura „îmbunătățire a securității” vine pentru că acum este un proces mai anevoios pentru un utilizator să facă acest lucru. Cu excepția cazului în care, desigur, o aplicație dorește doar să vă fure cele mai personale informații, cum ar fi fotografiile și videoclipurile pe care le aveți luate, pentru care Google a adăugat o soluție de acces alternativă care utilizează o simplă securitate pop-up clic-da dialog.

Nu se știe ce beneficii speră să obțină Google cu această schimbare. Motivul declarat oficial în documentația Android Q beta este de a „oferi utilizatorilor mai mult control asupra fișierelor lor și de a limita fișierele dezordine." Stocarea acoperită, în forma sa actuală, este o nouă limitare a ceea ce utilizatorului are voie să facă, nu o extensie a Control. Pretenția de a reduce dezordinea poate fi oarecum validă, dar numai pentru că modificarea reduce capacitatea de a utiliza fișiere. Iar „dezordinea” este crescută atunci când luați în considerare problema unor aplicații care acum trebuie să dubleze fișiere pentru a lucra cu ele.

Dacă Google este cu adevărat preocupat să ofere utilizatorilor mai mult control asupra fișierelor și a dezordinei, ar trebui să proiecteze un soluție care abordează direct acest lucru, mai degrabă decât să marcheze în mod fals designul actual Android Q ca atare îmbunătăţire. Cel mai simplu răspuns ar fi acela de a permite utilizatorilor să decidă dacă doresc ca o aplicație să aibă acces la sistemul de fișiere în domeniu sau general, folosind dialogul de solicitare a permisiunii de stocare existentă. Dacă există o preocupare specială pentru utilizatorii care iau decizii proaste aici, este cu siguranță posibil faceți dialogul mai proeminent și solicitați interacțiune suplimentară a utilizatorului pentru a aproba o aplicație completă acces.

Răspunsul la modul în care Android poate oferi utilizatorilor mai mult control asupra fișierelor lor este să le ofere utilizatorilor mai mult control, nu să-l îndepărteze și să limiteze în mod fundamental capacitățile platformei Android.


Nota editorului: Acesta este un articol invitat scris de un membru senior XDA tliebeck, cel mai cunoscut pentru munca sa la FX File Explorer. Conținutul acestui articol reflectă propria sa părere și analiză cu privire la restricțiile de stocare în domeniul de aplicare a Android Q, cu o contribuție și o editare minime din partea Mishaal Rahman, redactor-șef al XDA-Developers. Am contactat Google pentru a-i întreba despre unele dintre aceste preocupări, dar nu am primit răspuns de la companie până la data publicării.