Az Android Q kiterjedt tárhelye a SAF használatára kényszeríti a fejlesztőket, ami szívás

click fraud protection

Az Android Q Scoped Storage változásai fejtörést okoznak, mivel a Storage Access Frameworknek jelenleg van néhány hibája.

Az Android Q alapjaiban változtatja meg a tárhely működését a telefonon. A Pie-ig minden verzióban az Android tárhelye úgy működött, mint egy asztali számítógép: bármilyen alkalmazást használhat, amellyel bármilyen fájlt olvasni vagy írni szeretne (ha engedélyt ad egy alkalmazásnak erre). A Q-val a Google bevezeti (és megköveteli) "Hatékony tárolás", aminek köszönhetően az Android jobban működik, mint egy iPhone, ahol a tárhely elkülönítve van az egyes alkalmazásokhoz. Egy alkalmazás csak a saját fájljaihoz férhet hozzá, és ha eltávolítják, az összes fájl törlődik.

Szerencsére az Android Q továbbra is megtartja az Android központi fájlrendszerének eredeti viselkedését. Sajnos a felhasználó számára nehézkes beállítani az alkalmazásokat a hozzáféréshez, és jelentősen csökkent a teljesítmény és a képesség. A fejlesztőknek pedig jelentősen át kell kódolniuk az alkalmazásokat, hogy támogassák ezt.

Általános fájlrendszer-hozzáférést igénylő alkalmazások, pl. egy irodai programcsomagnak, képszerkesztőnek vagy fájlkezelőnek mostantól a "" nevű Android API-t kell használnia.Storage Access Framework" (SAF), minden fájlművelethez. A SAF az Android 5.0 Lollipop óta elérhető, de a fejlesztők általában nem használják, hacsak nem szükséges, mivel nehéz és gyengén működik dokumentált API, rossz felhasználói élmény, gyenge teljesítmény és gyenge megbízhatóság (nagyrészt az eszközgyártó-specifikus megvalósítás formájában problémák). Az SAF-re való átállás nehézségei miatt a Google úgy döntött, hogy engedélyezi azokat az alkalmazásokat, amelyek még nem jelzik Az Android Q-támogatás a megszokott módon működjön, de ez megváltozik, amikor a Play Áruház minden alkalmazásnak támogatnia kell a Q-t következő év.

A legnyilvánvalóbb, a felhasználókat érintő változás az SAF-nél az, hogy egy alkalmazás hozzáférést biztosít a tárhelyhez. Ahhoz, hogy egy alkalmazás hozzáférhessen, kérést küld az operációs rendszernek, amely ezután megjelenít egy címtárválasztó képernyőt. Ezen a képernyőn a felhasználó kiválasztja a mappahierarchia gyökerét, amelyben az alkalmazás képes fájlokat olvasni és írni. A felhasználónak végig kell mennie ezen a folyamaton minden olyan alkalmazásnál, amely hozzáférést igényel a helyi fájlokhoz, vagy alkalmazásonként kétszer, ha külső SD-kártyához is hozzáférést kell biztosítania.

A Google legalább javította ezt a folyamatot Q béta 3, mivel a korábbi béták nem engedték meg, hogy az alkalmazás még egy helyet is javasoljon a felhasználónak kiválasztani, ami sok munkát igényelt a felhasználótól hogy valóban megtalálják az eszközük elsődleges tárhelyét.

A fájlok I/O-teljesítménye némileg ütős SAF alatt, de a legkiemelkedőbb probléma a fájlokkal van könyvtárműveletek, ahol ez ~25-50-szer lassabb, mint a hagyományos fájlelérés. Pite. A fájlkezelők esetében ez azt jelenti, hogy nagyságrendekkel tovább tart a keresések és a tárhasználati számítások végrehajtása. A hibajelentés bemutató alkalmazással az elérhető itt.

A SAFTest minta tesztfutása, amely bemutatja a teljesítménykülönbséget a hagyományos fájl I/O API és SAF között.

Még nagyobb teljesítményprobléma az, hogy egyes alkalmazásoknak át kell másolniuk a fájlokat a helyi „hatókörű tárhelyükre”, mielőtt dolgozhatnának velük. Ez akkor lehet problémás, ha az ilyen fájlok több gigabájt méretűek, pl. videofájlok vagy tömörített archívumok esetén. Sok Android-alkalmazás kihasználja a fejlesztői közösség elképesztő számú nyílt forráskódú Java-könyvtárát, és ezek a könyvtárak általában közvetlen fájlrendszer-hozzáférést igényelnek. Nem Android-specifikusak, és át kell írniuk, hogy működjenek a SAF-fel. Még ennél is rosszabb, hogy az Android számos saját belső könyvtára nem működik vele, például a csomagkezelő vagy a zip API. Például a fájlkezelő még az APK-fájl ikonját sem tudja megjeleníteni (a szabványos Android API-t használva) anélkül, hogy a teljes APK-t a saját hatókörű tárterületére másolja. Hibajelentés.

Technikailag hajlamos emberek számára jelenleg lehetőség van az Android Q „Scoped Storage” alkalmazásonkénti letiltására az ADB-n keresztül egy appops paranccsal. A root felhasználók közvetlenül az eszközükön hajthatják végre a parancsokat asztali számítógép nélkül. Az ilyen parancsokat a dokumentáció fejlesztői funkciókként írja le, ezért bármikor eltávolíthatók.

Általános tárhely-hozzáférés engedélyezése egy alkalmazás számára:

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

Az alkalmazás általános tárhely-hozzáférésének letiltása:

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

A Google kiemeli ennek a változásnak a biztonsági és adatvédelmi előnyeit, de technikailag nincs javulás. Az alkalmazások az Android 1.0 óta képesek fájlok privát tárolására, és szinte minden alkalmazás használja ezt a lehetőséget. Ha egy alkalmazásnak hozzáférést ad a tárhely gyökérkönyvtárához a SAF-on keresztül, az képes olvasni, írni és elküldeni bármilyen fájlt. pontosan ugyanúgy akarja kezelni aljas fejlesztőjét, mint akkor, amikor hozzáférést adott egy alkalmazásnak a Pie tárhelyéhez.

Az egyetlen „biztonsági fejlesztés” azért következik be, mert a felhasználó számára ez most már nehezebb folyamat. Kivéve persze, ha egy alkalmazás csak az Ön legszemélyesebb adatait, például fotóit és videóit akarja ellopni vett, amelyhez a Google egy alternatív hozzáférési megoldást adott, amely egyszerű felugró kattintás-igen biztonságot használ párbeszéd.

Nem ismert, hogy a Google milyen előnyöket remél ezzel a változtatással. Az Android Q béta dokumentációjában szereplő hivatalos indok az, hogy „több irányítást biztosítsunk a felhasználóknak fájljaik felett, és korlátozzuk a fájlokat zűrzavar." A kiterjedt tárolás jelenlegi formájában egy új korlátozása annak, amit a felhasználó megtehet, nem pedig kiterjesztése. ellenőrzés. A rendetlenség csökkentésére vonatkozó állítás némileg helytálló lehet, de csak azért, mert a változtatás egyáltalán csökkenti a fájlok használatának lehetőségét. A „rendetlenség” pedig fokozódik, ha figyelembe vesszük azt a problémát, hogy egyes alkalmazásoknak most meg kell duplikálniuk a fájlokat, hogy működjenek velük.

Ha a Google valóban aggódik amiatt, hogy a felhasználók nagyobb ellenőrzést biztosítsanak a fájlok és a rendetlenség felett, akkor meg kell tervezniük a olyan megoldás, amely közvetlenül foglalkozik ezzel, ahelyett, hogy a jelenlegi Android Q dizájnt hamisan márkázza javulás. A legegyszerűbb válasz az lenne, ha a felhasználók dönthetik el, hogy egy alkalmazáshoz hatókörű vagy általános fájlrendszer-hozzáférést szeretnének-e a meglévő tárolási engedélykérés párbeszédpanelen keresztül. Ha különös aggodalomra ad okot a rossz döntéseket hozó felhasználók, ez minden bizonnyal lehetséges szembetűnőbbé teheti ezt a párbeszédpanelt, és további felhasználói beavatkozás szükséges az alkalmazás teljes körű jóváhagyásához hozzáférés.

Arra a válasz, hogy az Android miként adhat nagyobb irányítást a felhasználóknak fájljaik felett, az az, hogy ténylegesen több irányítást adunk a felhasználóknak, nem pedig elvenni és alapvetően korlátozni az Android platform képességeit.


A szerkesztő megjegyzése: Ez egy vendég cikk, amelyet az XDA vezető tagja írt tliebeck, legismertebb munkáiról FX File Explorer. A cikk tartalma tükrözi saját véleményét és elemzését az Android Q hatókörű tárolási korlátozásairól, minimális bevitellel és szerkesztéssel Mishaal Rahmantól, az XDA-Developers főszerkesztőjétől. Megkerestük a Google-t, hogy megkérdezzük őket ezen aggályok némelyikéről, de a közzététel időpontjáig nem kaptunk választ a cégtől.