Scoped Storage в Android Q змушує розробників використовувати SAF, що погано

Зміни 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 разів повільніше, ніж звичайний доступ до файлів, можливий у пиріг. У випадку з файловими менеджерами це означає, що для виконання пошуку та обчислення використання сховища знадобиться на кілька порядків більше часу. Звіт про помилку з демонстраційним додатком є доступний тут.

Зразок тестового запуску SAFTest, що показує різницю в продуктивності між звичайним файловим API введення-виведення та SAF.

Ще більшою проблемою з продуктивністю є те, що деяким програмам доведеться копіювати файли в свою локальну область «з обмеженим обсягом зберігання», перш ніж вони зможуть з ними працювати. Це може бути проблематично, якщо такі файли мають розмір у декілька гігабайтів, напр. у випадку відеофайлів або стиснутих архівів. Багато програм Android використовують переваги дивовижної кількості відкритих бібліотек Java у спільноті розробників, і ці бібліотеки зазвичай потребують прямого доступу до файлової системи для роботи. Вони не є специфічними для Android і вимагають переписування для роботи з SAF. Навіть гірше, багато власних внутрішніх бібліотек Android не працюватимуть з ним, наприклад, менеджер пакетів або zip API. Наприклад, менеджер файлів навіть не зможе відобразити піктограму файлу APK (за допомогою стандартного API Android), не скопіювавши весь 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-name

Google рекламує переваги цієї зміни щодо безпеки та конфіденційності, але з технічної точки зору покращень немає. Програми мають можливість приватно зберігати файли з Android 1.0, і майже всі програми використовують цю можливість. Коли ви надаєте програмі доступ до кореневого каталогу вашого сховища через SAF, вона може читати, записувати та надсилати будь-який файл, який хоче свого нечестивого розробника так само, як і коли ви надали додатку доступ до пам’яті в Pie.

Єдине «поліпшення безпеки» відбувається через те, що користувачеві тепер зробити це складніше. Звичайно, якщо програма не хоче викрасти вашу найбільш особисту інформацію, як-от фотографії та відео, які у вас є взято, для якого Google додав альтернативне рішення для доступу, яке використовує просте спливаюче вікно безпеки «клацніть так». діалог.

Невідомо, яких переваг Google сподівається отримати за допомогою цієї зміни. Офіційна причина в документації бета-версії Android Q полягає в тому, щоб «надати користувачам більше контролю над своїми файлами та обмежити безлад». Область зберігання в його нинішньому вигляді є новим обмеженням того, що користувачеві дозволено робити, а не розширенням його КОНТРОЛЬ. Твердження про зменшення безладу може бути певною мірою слушним, але лише тому, що зміна взагалі зменшує можливість використання файлів. І «безлад» збільшується, якщо врахувати проблему, пов’язану з тим, що деякі програми тепер мають дублювати файли для роботи з ними.

Якщо Google справді зацікавлений у тому, щоб надати користувачам більше контролю над файлами та безладом, їм слід розробити a рішення, яке безпосередньо стосується цього, а не фальшиво називає поточний дизайн Android Q таким поліпшення. Найпростішою відповіддю було б дозволити користувачам вирішувати, чи хочуть вони, щоб програма мала обмежений або загальний доступ до файлової системи, використовуючи діалогове вікно запиту дозволу на зберігання. Якщо є особливе занепокоєння щодо користувачів, які приймають неправильні рішення, це, звичайно, можливо зробити це діалогове вікно більш помітним і вимагати додаткової взаємодії з користувачем для повного схвалення програми доступу.

Відповідь на те, як Android може надати користувачам більше контролю над їхніми файлами, полягає в тому, щоб фактично дати користувачам більше контролю, а не позбавити його й фундаментально обмежити можливості платформи Android.


Примітка редактора: це гостьова стаття, написана старшим членом XDA tliebeck, найбільш відомий своєю роботою над Провідник файлів FX. Зміст цієї статті відображає його власну думку та аналіз обмежень Scoped Storage Android Q з мінімальним введенням і редагуванням Мішаалом Рахманом, головним редактором XDA-Developers. Ми звернулися до Google, щоб запитати їх про деякі з цих проблем, але не отримали відповіді від компанії до моменту публікації.