Scoped Storage i Android Q tvinger udviklere til at bruge SAF, hvilket stinker

Ændringerne af Scoped Storage i Android Q er en hovedpine at håndtere, fordi Storage Access Framework har et par fejl lige nu.

Android Q ændrer fundamentalt den måde, opbevaring fungerer på din telefon. I alle versioner op til Pie fungerede Androids lager som en stationær computer: du kan bruge enhver app, du vil læse eller skrive enhver fil (hvis du giver en app tilladelse til at gøre det). Med Q introducerer (og kræver) Google "Omfanget opbevaring," hvilket får Android til at fungere mere som en iPhone, hvor lagring er isoleret til hver app. En app kan kun få adgang til sine egne filer, og hvis den afinstalleres, slettes alle dens filer.

Heldigvis bevarer Android Q stadig noget af Androids oprindelige adfærd som et centralt filsystem. Desværre er det nu besværligt for brugeren at konfigurere apps for at få adgang til det og har væsentligt reduceret ydeevne og kapacitet. Og udviklere bliver nødt til at omkode apps væsentligt for at understøtte det.

Apps, der har brug for generel filsystemadgang, f.eks. en kontorpakke, billededitor eller filhåndtering skal nu bruge en Android API kaldet "

Storage Access Framework" (SAF), for alle filhandlinger. SAF har været tilgængelig siden Android 5.0 Lollipop, men udviklere har en tendens til ikke at bruge det, medmindre det er nødvendigt, da det har en vanskelig og dårlig dokumenteret API, en dårlig brugeroplevelse, dårlig ydeevne og dårlig pålidelighed (hovedsageligt i form af enhedsleverandørspecifik implementering problemer). Som et resultat af vanskeligheden med at skifte til SAF, har Google besluttet at tillade apps, der endnu ikke angiver Android Q-understøttelse fungerer, som de plejede, men dette ændres, når Play Butik kræver, at alle apps understøtter Q næste år.

Den mest åbenlyse brugervendte ændring med SAF er oplevelsen af ​​at give en app adgang til lagerplads. For at en app skal få adgang, sender den en anmodning til OS, som derefter viser en mappevælgerskærm. På denne skærm vælger brugeren roden af ​​et mappehierarki, hvor denne app vil være i stand til at læse og skrive filer. Brugeren skal gennemgå denne proces for hver app, der kræver adgang til lokale filer, eller to gange pr. app, hvis de også skal give den adgang til et eksternt SD-kort.

Google forbedrede i det mindste denne proces for Q beta 3, da tidligere betaversioner ikke tillod en app at foreslå en placering, som brugeren kunne vælge, hvilket krævede, at brugeren lavede en del arbejde for rent faktisk at finde deres enheds primære lager.

Fil I/O ydeevne tager noget af et hit under SAF, men det mest udestående problem ligger i filen mappeoperationer, hvor det er ~25 til 50 gange langsommere end den konventionelle filadgang, der er mulig i Pie. I tilfælde af filhåndtering betyder det, at det vil tage størrelsesordener længere tid at udføre søgninger og beregninger af lagerforbrug. En fejlrapport med en demonstrationsapp er tilgængelig her.

Prøveprøvekørsel af SAFTest, der viser ydeevneforskellen mellem den konventionelle fil I/O API med SAF.

Et endnu større ydelsesproblem er, at nogle apps bliver nødt til at kopiere filer til deres lokale "scoped storage"-område, før de kan arbejde med dem. Dette kan være problematisk, når sådanne filer er flere gigabyte store, f.eks. i tilfælde af videofiler eller komprimerede arkiver. Mange Android-apps drager fordel af det fantastiske antal open source Java-biblioteker i udviklerfællesskabet, og disse biblioteker kræver almindeligvis direkte filsystemadgang for at fungere. De er ikke Android-specifikke og vil kræve omskrivning for at fungere med SAF. Endnu værre, mange af Androids egne interne biblioteker vil ikke fungere med det, såsom pakkehåndtering eller zip API. For eksempel vil en filhåndtering ikke engang være i stand til at vise ikonet for en APK-fil (ved hjælp af standard Android API) uden først at kopiere hele APK'en til dets eget lagerområde. Fejlrapport.

For teknisk indstillede folk er det i øjeblikket muligt at deaktivere Android Q's "Scoped Storage" på en per-app-basis via ADB ved hjælp af en appops-kommando. Rootbrugere kan udføre kommandoerne direkte på deres enhed uden en stationær computer. Sådanne kommandoer er beskrevet i dokumentationen som udviklerfunktioner og kan derfor fjernes til enhver tid.

Aktiver generel lageradgang for en app:

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

Deaktiver generel lageradgang for en app:

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

Google fremhæver sikkerheds- og privatlivsfordelene ved denne ændring, men teknisk set er der ingen forbedring. Apps har haft mulighed for at gemme filer privat siden Android 1.0, og næsten alle apps gør brug af denne mulighed. Når du giver en app adgang til rodmappen på dit lager via SAF, kan den læse, skrive og sende enhver fil den vil sin ondsindede udvikler på nøjagtig samme måde, som det kunne, da du gav en app adgang til lagring i Pie.

Den eneste "sikkerhedsforbedring" kommer, fordi det nu er en mere besværlig proces for en bruger at gøre dette. Medmindre en app selvfølgelig kun ønsker at stjæle dine mest personlige oplysninger, såsom billeder og videoer, du har taget, som Google har tilføjet en alternativ adgangsløsning til, som bruger en simpel pop-up klik-ja sikkerhed dialog.

Det vides ikke, hvilke fordele Google håber at opnå med denne ændring. Den officielle angivne årsag i Android Q beta-dokumentationen er at "give brugerne mere kontrol over deres filer og begrænse filen uorden." Omfanget opbevaring er i sin nuværende form en ny begrænsning af, hvad brugeren må gøre, ikke en udvidelse af deres styring. Påstanden om at reducere rod kan være noget gyldig, men kun fordi ændringen reducerer muligheden for overhovedet at bruge filer. Og "rod" øges, når du tænker på problemet med, at nogle apps nu skal duplikere filer for at arbejde med dem.

Hvis Google virkelig er bekymret for at give brugerne mere kontrol over filer og rod, bør de bygge en løsning, der direkte adresserer det, i stedet for falsk branding af det nuværende Android Q-design som sådan forbedring. Det enkleste svar ville være at lade brugerne beslutte, om de ønsker, at en app skal have scoped eller generel filsystemadgang, ved at bruge den eksisterende dialogboks for anmodning om lagringstilladelse. Hvis der er en særlig bekymring for brugere, der træffer dårlige beslutninger her, er det bestemt muligt gøre denne dialog mere fremtrædende og kræve yderligere brugerinteraktion for at godkende en app fuldt ud adgang.

Svaret på, hvordan Android kan give brugerne mere kontrol over deres filer, er faktisk at give brugerne mere kontrol, ikke at tage den væk og grundlæggende begrænse Android-platformens muligheder.


Redaktørens note: Dette er en gæsteartikel skrevet af XDA Senior Member tliebeck, bedst kendt for sit arbejde vedr FX File Explorer. Indholdet af denne artikel afspejler hans egen mening og analyse af Android Q's Scoped Storage-begrænsninger med minimal input og redigering fra Mishaal Rahman, chefredaktør for XDA-Developers. Vi kontaktede Google for at spørge dem om nogle af disse bekymringer, men vi har ikke hørt tilbage fra virksomheden inden udgivelsestidspunktet.