Scoped Storage v Androidu Q sili razvijalce v uporabo SAF, kar je zanič

Spremembe Scoped Storage v Androidu Q povzročajo glavobol, saj ima Storage Access Framework trenutno nekaj pomanjkljivosti.

Android Q temeljito spreminja način delovanja pomnilnika v vašem telefonu. V vseh različicah do Pie je shramba Androida delovala kot namizni računalnik: uporabite lahko katero koli aplikacijo, ki jo želite prebrati, ali zapisati katero koli datoteko (če aplikaciji daste dovoljenje za to). Google s Q uvaja (in zahteva) "Obseg shranjevanja,« zaradi česar Android deluje bolj kot iPhone, kjer je shramba ločena za vsako aplikacijo. Aplikacija lahko dostopa samo do svojih datotek in če je odstranjena, so vse njene datoteke izbrisane.

Na srečo Android Q še vedno ohranja nekaj Androidovega prvotnega obnašanja osrednjega datotečnega sistema. Na žalost je zdaj za uporabnika okorno nastaviti aplikacije za dostop do njega, kar je bistveno zmanjšalo zmogljivost in zmogljivost. In razvijalci bodo morali znatno na novo kodirati aplikacije, da bodo to podpirali.

Aplikacije, ki potrebujejo splošni dostop do datotečnega sistema, npr. pisarniški paket, urejevalnik slik ali upravitelj datotek, bodo zdaj morali uporabljati API za Android, imenovan "

Storage Access Framework" (SAF), za vse operacije datotek. SAF je na voljo že od Android 5.0 Lollipop, vendar ga razvijalci običajno ne uporabljajo, razen če je to potrebno, saj ima težko in slabo dokumentiran API, slaba uporabniška izkušnja, slaba zmogljivost in slaba zanesljivost (večinoma v obliki izvedbe, specifične za prodajalca naprave vprašanja). Zaradi težav pri prehodu na SAF se je Google odločil dovoliti aplikacije, ki še ne kažejo Podpora za Android Q bo delovala kot včasih, vendar se bo to spremenilo, ko bo Trgovina Play zahtevala, da vse aplikacije podpirajo Q naslednje leto.

Najbolj očitna sprememba, s katero se sooča uporabnik pri SAF, je izkušnja odobritve dostopa aplikaciji do pomnilnika. Da bi aplikacija dobila dostop, pošlje zahtevo operacijskemu sistemu, ki nato prikaže zaslon za izbiro imenika. Na tem zaslonu uporabnik izbere koren hierarhije map, v kateri bo ta aplikacija lahko brala in zapisovala datoteke. Uporabnik mora opraviti ta postopek za vsako aplikacijo, ki zahteva dostop do lokalnih datotek, ali dvakrat na aplikacijo, če ji mora omogočiti tudi dostop do zunanje kartice SD.

Google je ta postopek vsaj izboljšal za Q beta 3, saj prejšnje različice beta aplikaciji niso dovoljevale niti predlaganja lokacije, ki bi jo lahko uporabnik izbral, kar od uporabnika zahtevalo kar nekaj dela da dejansko najdejo primarni pomnilnik svoje naprave.

Učinkovitost V/I datotek je pod SAF nekoliko slabša, vendar je največja težava v datoteki operacije imenika, kjer je približno 25- do 50-krat počasnejši od običajnega dostopa do datotek, ki je mogoč v pita. V primeru upraviteljev datotek to pomeni, da bo za izvajanje iskanja in izračune uporabe prostora za shranjevanje potrebnih nekaj več časa. Poročilo o napaki z demonstracijsko aplikacijo je na voljo tukaj.

Vzorec preskusnega zagona SAFTest, ki prikazuje razliko v zmogljivosti med običajnim datotečnim I/O API in SAF.

Še večja težava pri zmogljivosti je, da bodo morale nekatere aplikacije kopirati datoteke v svoje lokalno območje »omejenega pomnilnika«, preden bodo lahko delale z njimi. To je lahko problematično, če so takšne datoteke velike več gigabajtov, npr. v primeru video datotek ali stisnjenih arhivov. Številne aplikacije za Android izkoriščajo neverjetno število odprtokodnih knjižnic Java v skupnosti razvijalcev in te knjižnice običajno zahtevajo neposreden dostop do datotečnega sistema za delovanje. Niso specifični za Android in bi jih bilo treba prepisati, da bi delovali s SAF. Še huje, številne lastne notranje knjižnice Androida ne bodo delovale z njim, na primer upravitelj paketov ali API zip. Na primer, upravitelj datotek sploh ne bo mogel prikazati ikone za datoteko APK (z uporabo standardnega API-ja za Android), ne da bi prej kopiral celoten APK v svoje območje za shranjevanje. Poročilo o napaki.

Za tehnično nagnjene ljudi je trenutno mogoče onemogočiti »Scoped Storage« Androida Q za vsako aplikacijo prek ADB z ukazom appops. Korenski uporabniki lahko izvajajo ukaze neposredno v svoji napravi brez namiznega računalnika. Takšni ukazi so v dokumentaciji opisani kot funkcije za razvijalce in jih je zato mogoče kadar koli odstraniti.

Omogoči splošni dostop do shrambe za aplikacijo:

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

Onemogoči splošni dostop do pomnilnika za aplikacijo:

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

Google hvali prednosti te spremembe glede varnosti in zasebnosti, vendar tehnično gledano ni izboljšav. Aplikacije imajo možnost zasebnega shranjevanja datotek od Androida 1.0 in skoraj vse aplikacije uporabljajo to možnost. Ko aplikaciji omogočite dostop do korenskega imenika vašega pomnilnika prek SAF, lahko bere, piše in pošilja katero koli datoteko, želi svojemu zlobnemu razvijalcu na povsem enak način kot bi ga lahko, ko bi aplikaciji odobrili dostop do shrambe v Pie.

Edina "izboljšava varnosti" je posledica tega, da je zdaj to za uporabnika bolj naporen postopek. Razen seveda, če želi aplikacija ukrasti samo vaše najbolj osebne podatke, kot so fotografije in videoposnetki, ki jih imate sprejeto, za kar je Google dodal alternativno rešitev za dostop, ki uporablja preprosto varnostno pojavno okno s klikom in da dialog.

Kakšne koristi želi Google doseči s to spremembo, ni znano. Uradni razlog, naveden v dokumentaciji beta za Android Q, je, da bi uporabnikom dali več nadzora nad njihovimi datotekami in omejili datoteke navlaka." Shranjevanje v obsegu je v sedanji obliki nova omejitev tega, kar lahko uporabnik počne, in ne razširitev njegovega nadzor. Trditev o zmanjševanju nereda je morda nekoliko veljavna, vendar le zato, ker sprememba sploh zmanjša možnost uporabe datotek. In "nered" se poveča, če pomislite na težavo nekaterih aplikacij, ki morajo zdaj podvajati datoteke, da delajo z njimi.

Če Google resnično skrbi, da bi uporabnikom omogočil več nadzora nad datotekami in neredom, bi morali oblikovati a rešitev, ki to neposredno obravnava, namesto da bi lažno označila trenutno zasnovo Android Q kot tako izboljšava. Najenostavnejši odgovor bi bil, da bi uporabnikom dovolili, da se odločijo, ali želijo, da ima aplikacija omejen ali splošen dostop do datotečnega sistema, z uporabo obstoječega pogovornega okna za zahtevo za dovoljenje za shranjevanje. Če obstaja posebna skrb za uporabnike, ki sprejemajo slabe odločitve, je to zagotovo mogoče naredi to pogovorno okno bolj vidno in zahteva dodatno interakcijo uporabnika za popolno odobritev aplikacije dostop.

Odgovor na to, kako lahko Android uporabnikom omogoči večji nadzor nad njihovimi datotekami, je, da uporabnikom dejansko omogoči več nadzora, ne pa da ga odvzame in bistveno omeji zmogljivosti platforme Android.


Opomba urednika: To je gostujoči članek, ki ga je napisal višji član XDA tliebeck, najbolj znan po svojem delu na Raziskovalec datotek FX. Vsebina tega članka odraža njegovo lastno mnenje in analizo omejitev Scoped Storage v sistemu Android Q z minimalnim vnosom in urejanjem Mishaala Rahmana, glavnega urednika XDA-Developers. Obrnili smo se na Google, da bi jih povprašali o nekaterih od teh pomislekov, vendar nam podjetje do objave ni odgovorilo.