Промените в Scoped Storage в Android Q са главоболие, с което трябва да се справите, тъй като Storage Access Framework има няколко недостатъка в момента.
Android Q фундаментално променя начина, по който работи съхранението на вашия телефон. Във всяка версия до Pie, хранилището на Android работеше като настолен компютър: можете да използвате всяко приложение, което искате, за да четете или да пишете всеки файл (ако дадете разрешение на приложението да го направи). С Q Google въвежда (и изисква) "Съхранение с обхват”, което кара Android да работи по-скоро като iPhone, където паметта е изолирана за всяко приложение. Едно приложение има достъп само до собствените си файлове и ако е деинсталирано, всичките му файлове се изтриват.
За щастие Android Q все още запазва част от оригиналното поведение на Android на централна файлова система. За съжаление сега е тромаво за потребителя да настройва приложения за достъп до него и значително намалява производителността и възможностите. И разработчиците ще трябва значително да прекодират приложенията, за да го поддържат.
Приложения, които се нуждаят от общ достъп до файловата система, напр. офис пакет, редактор на изображения или файлов мениджър, сега ще трябва да използва Android API, наречен "Рамка за достъп до съхранение" (SAF), за всички файлови операции. SAF е наличен от Android 5.0 Lollipop, но разработчиците са склонни да не го използват, освен ако не е необходимо, тъй като има трудно и лошо документиран API, лошо потребителско изживяване, лоша производителност и слаба надеждност (до голяма степен под формата на внедряване, специфично за доставчика на устройство въпроси). В резултат на трудността при прехода към SAF, Google реши да разреши приложения, които все още не показват Поддръжката на Android Q ще работи както преди, но това ще се промени, когато Play Store изисква всички приложения да поддържат Q следващата година.
Най-очевидната промяна, пред която са изправени потребителите със SAF, е изживяването при предоставяне на достъп на приложение до хранилище. За да получи достъп дадено приложение, то прави заявка до операционната система, която след това показва екран за избор на директория. На този екран потребителят избира корена на йерархията на папки, в която това приложение ще може да чете и записва файлове. Потребителят трябва да премине през този процес за всяко приложение, което изисква достъп до локални файлове, или два пъти на приложение, ако трябва да му предостави достъп и до външна SD карта.
Google поне подобри този процес за Q бета 3, тъй като предишните бета версии не позволяваха на приложението дори да предложи местоположение, което потребителят да избере, което изискваше от потребителя да свърши доста работа действително да намерят основното хранилище на устройството си.
Производителността на входно-изходния файл се влошава донякъде при SAF, но най-забележителният проблем се крие във файла операции с директории, където е ~25 до 50 пъти по-бавно от конвенционалния достъп до файлове, възможен в пай. В случай на файлови мениджъри това означава, че ще отнеме много повече време за извършване на търсения и изчисления на използването на хранилището. Доклад за грешка с демонстрационно приложение е налични тук.
Още по-голям проблем с производителността е, че някои приложения ще трябва да копират файлове в своята локална област за „обхватно съхранение“, преди да могат да работят с тях. Това може да бъде проблематично, когато такива файлове са с размер няколко гигабайта, напр. в случай на видео файлове или компресирани архиви. Много приложения за Android се възползват от невероятния брой Java библиотеки с отворен код в общността на разработчиците и тези библиотеки обикновено изискват директен достъп до файловата система, за да работят. Те не са специфични за Android и ще изискват пренаписване, за да работят със SAF. Дори по-лошо, много от собствените вътрешни библиотеки на Android няма да работят с него, като мениджъра на пакети или zip API. Например, файловият мениджър дори няма да може да покаже иконата за APK файл (използвайки стандартния Android API), без първо да копира целия APK в собствената си област за съхранение. Доклад за грешка.
За технически склонни хора, понастоящем е възможно да деактивирате „Scoped Storage“ на Android Q за всяко приложение чрез ADB с помощта на команда appops. Потребителите на root могат да изпълняват командите директно на своето устройство без настолен компютър. Такива команди са описани в документацията като функции за разработчици и следователно могат да бъдат премахнати по всяко време.
Разрешете общ достъп до хранилището за приложение:
adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-nameДеактивирайте общия достъп до хранилището за приложение:
adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-nameGoogle рекламира ползите за сигурността и поверителността от тази промяна, но технически погледнато, няма подобрение. Приложенията имат способността да съхраняват частно файлове от Android 1.0 и почти всички приложения използват тази възможност. Когато предоставите на приложение достъп до главната директория на вашето хранилище чрез SAF, то може да чете, пише и изпраща всеки файл иска на своя подъл разработчик по абсолютно същия начин, както би могъл, когато сте предоставили на приложение достъп до хранилището в Pie.
Единственото „подобрение на сигурността“ идва, защото сега е по-труден процес за потребителя да направи това. Освен ако, разбира се, приложението не иска да открадне само най-личната ви информация, като снимки и видеоклипове, които имате взето, за което Google е добавил алтернативно решение за достъп, което използва обикновена защита с изскачащо кликване и да диалогов прозорец.
Не е известно какви ползи Google се надява да постигне с тази промяна. Официалната посочена причина в бета документацията на Android Q е „да се даде на потребителите повече контрол върху техните файлове и да се ограничи файлът бъркотия.” Съхранение с обхват, в сегашната му форма, е ново ограничение на това, което потребителят има право да прави, а не разширение на техните контрол. Твърдението за намаляване на бъркотията може да е донякъде валидно, но само защото промяната намалява възможността за използване на файлове изобщо. И „бъркотията“ се увеличава, когато вземете предвид проблема с някои приложения, които сега трябва да дублират файлове, за да работят с тях.
Ако Google наистина е загрижен да даде на потребителите повече контрол върху файловете и бъркотията, те трябва да създадат a решение, което се отнася директно до това, вместо да брандира фалшиво текущия дизайн на Android Q като такъв подобрение. Най-простият отговор би бил да се позволи на потребителите да решат дали искат приложението да има достъп с обхват или общ достъп до файловата система, като използват диалоговия прозорец за искане на съществуващо разрешение за съхранение. Ако има особена загриженост за потребителите, които вземат лоши решения тук, със сигурност е възможно направи този диалогов прозорец по-забележим и изисква допълнително взаимодействие с потребителя, за да одобри напълно приложение достъп.
Отговорът на това как Android може да даде на потребителите повече контрол върху техните файлове е всъщност да им даде повече контрол, а не да ги отнеме и фундаментално да ограничи възможностите на платформата Android.
Бележка на редактора: Това е статия за гост, написана от старши член на XDA тлибек, най-известен с работата си по FX File Explorer. Съдържанието на тази статия отразява неговото собствено мнение и анализ на ограниченията за обхватно съхранение на Android Q, с минимално въвеждане и редактиране от Mishaal Rahman, главен редактор на XDA-Developers. Свързахме се с Google, за да ги попитаме за някои от тези опасения, но не получихме отговор от компанията до момента на публикуване.