Android 13 запретит сторонним файловым менеджерам доступ к папкам в каталоге '/Android'

В Android 11 Google ввела такую вещь, как Scoped Storage, суть которой заключалась в том, чтобы предоставлять приложениям доступ только к своим собственным файлам кэша, специфичным для приложения, но не никак ни к чужим. То есть, даже если приложение имеет разрешение на "доступ ко всем файлам", ему не разрешается доступ к каталогу /Android и его подкаталогам /Android/obb и Android/data.

Пользуясь случаем, мы хотели бы вас пригласить в наш Telegram канал, где вы найдете еще больше новостей, связанных с Google, устройствами Pixel и Android!

Но как же разработчикам до сих пор удавалось обходить ограничение введенное в Android 11? Всё благодаря лазейке в Storage Access Framework (SAF). Используя лазейку, файловые менеджеры могли получать доступ к подкаталогам в каталоге /Android. 

К сожалению, как обнаружил Мишаал Рахман на Esper Blog, в Android 13 эта лазейка теперь была закрыта, что ограничивает возможности сторонних файловых менеджеров выполнять свою работу. Он продемонстировал это на примере файлового менеджера MixPlorer. 

Повторюсь, речь идет именно о сторонних файловых менеджерах. Такие системные решения, как AOSP Files и приложение Google Files, являющееся частью предустановленных Google Mobile Services, по-прежнему имеют доступ к этим директориям.

Так почему же закрытие этой лазейки так важно для пользователей? Для этого нужно немного подтянуть теорию.

Основы

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

Например, приложение Telegram хранит свой кэш в папке /Android/data/org.telegram.messenger/cache, поэтому если вы забыли сохранить какой-то файл, но хотите его извлечь, вы можете найти его там. /Android/data — это не единственное место, где приложения могут хранить файлы, но для таких целей оно предлагает больше пространства, чем внутренняя память, и к нему к тому же удобно обращаться, поэтому зачастую используется именно эта директория.

В течение многих лет Google Play ограничивал размер APK-файлов, которые могли загружать разработчики, объемом 100 мб и меньше. Но есть приложение, которые работают с большим количеством высококачественных ресурсов, например игры. В этом случае Google предлагает возможность создавать файлы дополнительные для APK файлы размером до 2 ГБ. Эти файлы хранятся в папке /Android/obb с расширением .obb. Наверняка, вы сталкивались с этим, если когда-либо скачивали объемные Android игры со сторонних ресурсов.

В связи с этим, неудивительно, что введенное в Android 11 ограничение вызвало бурю недовольства среди пользователей. Однако довольно быстро было замечено, что многие файловые менеджеры выпустили обновления, позволяющие получить доступ к /Android/data и /Android/obb. Пользователю достаточно было нажать "использовать эту папку", а затем "разрешить", и файловый менеджер получал доступ к этим каталогам.

Ниже вы видите пример из Android 12L и файлового менеджера MiXplorer. После попытки открытия подпапок в каталоге /Android, пользователя перекидывает в системное приложение AOSP Файлы, где предлагается разрешить доступ к /Android/data. Такой же запрос появляется при получении доступа к /Android/obb.

Лазейка в Storage Access Framework (SAF)

Файловые менеджеры, подобные MiXplorer, используют Storage Access Framework (SAF) для запроса доступа к содержимому определенного каталога. SAF был представлен еще в Android 4.4, а возможность использовать SAF для того, чтобы предложить пользователю выбрать каталог для доступа к нему, была добавлена в Android 5.0.

Таким образом, эта возможность существует уже довольно долгое время, поэтому не похоже, что Google не учел, что приложения будут пытаться использовать SAF для запроса доступа к каталогам, доступ к которым должен быть ограничен. На самом деле, Google явно блокировал доступ SAF к каталогу /Android, но эта реализация имела недостаток: она не блокировала доступ SAF к подкаталогам под /Android.

Другими словами, хоть файловые менеджеры и не могли просто использовать SAF для запроса доступа ко всей директории /Android, они могли использовать его для запроса доступа к /Android/data и /Android/obb, тем самым почти полностью обходя ограничения Android.

Метод, лежащий в основе этой лазейки, довольно просто найти в Интернете. Она достаточно хорошо описана на ресурсе StackOverflow. Это работает следующим образом: при создании намерения запустить SAF приложения могут установить начальное местоположение выбора документа как /Android/data или /Android/obb. Это функциональность SAF, которая изначально была в нем заложена, но, похоже, что Google, не учел этого при реализации в Android ограничений на эти каталоги. ¯\_(ツ)_/¯

Закрытие лазейки

Спустя полгода после того, как кто-то сообщил Google о существовании лазейки, сотрудник компании заявил, что проблема будет исправлена в одном из будущих релизов Android. Этот "будущий релиз Android" уже здесь, в виде Android 13. Как заметил Мишаал Рахман на Esper Blog, лазейка устранена путем собственного тестирования и изучения кода. Как видно из видео ниже, лазейка работает на Android 12L, но не на Android 13:

В Android 13 Google обновил метод shouldBlockFromTree в ExternalStorageProvider. В обновленном методе появилось новое условие для проверки соответствия запускаемого каталога одному из каталогов, которые должны быть скрыты от приложений. Если совпадение есть, то к директории будет применен флаг, который блокирует ее выбор через SAF.

Разница между методом shouldBlockFromTree в Android 12L и Android 13
Источник: Esper Blog

Итог

Из-за этого изменения файловым менеджерам придется искать другой обходной способ доступа к файлам в каталоге /Android. Одним из решений может быть использование библиотеки Shizuku для запуска от через shell, поскольку shell-пользователь по-прежнему имеет доступ к /Android. Однако Shizuku не является идеальным решением, поскольку ее служба не сохраняется при перезагрузке, а на некоторых устройствах она завершается при переключении между WiFi и мобильными данными. Кроме того, полагаться на Shizuku немного рискованно, поскольку в будущем Google может ограничить эту возможность.

Пока разработчики файловых менеджеров ищут обходные пути, пользователи могут получить доступ к /Android одним из официально поддерживаемых способов: системное приложение AOSP Files (если вы не можете найти его, то вы можете скачать это приложение, оно действует как ярлык), MTP передача данных (т.е. с вашего ПК) или оболочка ADB (adb shell) (с ПК или без него).

Мишаал Рахман предполагает, что файловые менеджеры, которые уже получили доступ к подкаталогам под /Android с помощью лазейки SAF на Android 12L, сохранят этот доступ при обновлении до Android 13, поэтому одним из вариантов может быть настройка файлового менеджера перед обновлением на новую версию системы.

Источник: Esper Blog