Android storage access framework 4pda

Хранение данных и файлов

В целом хранение файлов и данных можно условно разделить на две группы: во внутреннем или внешнем хранилище. Но разница между ними довольна тонка. В целом политика Гугла в отношение данных ужесточается с каждой версии системы.

Android поддерживает различные варианты хранения данных и файлов.

• Специфичные для приложения файлы. Доступ к файлам имеет только приложение, их создавшее. Файлы могут находиться во внутреннем и внешнем хранилище. У других приложений нет доступа (кроме случаев, когда файлы хранятся на внешнем хранилище). Методы getFilesDir(), getCacheDir(), getExternalFilesDir(), getExternalCacheDir(). Разрешений на доступ не требуется. Файлы удаляются, когда приложение удаляется пользователем.
• Разделяемое хранилище. Приложение может создавать файлы, которыми готово поделиться с другими приложениями — медиафайлы (картинки, видео, аудио), документы. Для медифайлов требуется разрешение READ_EXTERNAL_STORAGE или WRITE_EXTERNAL_STORAGE.
• Настройки. Хранение простых данных по принципу ключ-значение. Доступно внутри приложения. Реализовано через Jetpack Preferences. Настройки удаляются, когда приложение удаляется пользователем.
• Базы данных. Хранение данных в SQLite. На данный момент реализовано через библиотеку Room. Доступ только у родного приложения.

В зависимости от ваших потребностей, нужно выбрать нужный вариант хранения данных.

Следует быть осторожным при работе с внутренним и внешним хранилищем. Внутренне хранилище всегда есть в системе, но оно может быть не слишком большим по объёму. Вдобавок к внутреннему хранилищу, устройство может иметь внешнее хранилище. В старых моделях таким хранилищем выступала съёмная SD-карта. Сейчас чаще используют встроенную и недоступную для извлечения флеш-память. Если ваше приложение слишком большое, можно попросить систему устанавливать программу во внешнее хранилище, указав просьбу в манифесте.

В разных версиях Android требования к разрешению для работы с внешним хранилищем постоянно менялись. На данный момент (Android 10, API 29) требования выглядят следующим образом.

Приложение может иметь доступ к собственным файлам, которые находятся во внешнем хранилище. Также может получить доступ к определённым общим файлам на внешнем хранилище.

Доступ к общим файлам достигается через FileProvider API или контент-провайдеры.

Для просмотра файлов через студию используйте инструмент Device File Explorer.

Внешняя карта памяти

Когда появились первые устройства на Android, то практически у всех были внешние карточки памяти, которые вставлялись в телефон. Обычно там хранили фотки, видео и свои файлы. Всё было понятно — были различные методы для доступа к файловой системе. А потом началась чехарда. В телефонах также была и собственная «внешняя» память. Она вроде как и внешняя, но вставлена на заводе и вытащить её пользователь не мог, т.е. практически внутренняя. Затем пошла мода на телефоны, у которых была только такая внутреннее-внешняя карта. Пользователи поворчали, но привыкли. Сейчас встречаются оба варианта. Как правило, у телефонов с спрятанной картой больше памяти и выше степень водонепроницаемости.

Подобные фокусы с картой породили и другую проблему — Гугл озаботился безопасностью файлов и стала думать, как осложнить жизнь разработчику. С выходом каждой новой версии системы компания то давала добро на полный доступ к карточке, то ограничивала, то давала права с ограничениями, то откатывала свои решения назад. Короче, запутались сами и запутали всех.

Попробуем немного разобраться с этим зоопарком. Но помните, что процесс путаницы продолжается.

При подготовке материала я опирался на письма некоторых читателей сайта, которые присылали свои мысли по этому поводу. Спасибо им за структуризацию материала.

Вот что я (кажется) понял, попытавшись загрузить картинку с внешней SD карточки.

External это не External
«EXTERNAL_STORAGE» называется так не потому, что это внешняя память по отношению к устройству, а потому что она выглядит как внешняя память для компьютера, если устройство подключить кабелем к компьютеру. Причём именно выглядит, потому что обмен идёт по протоколу MTP – устройство только показывает компьютеру список папок и файлов, а при необходимости открыть или скопировать файл он специально загружается на компьютер, в отличие от настоящей флешки, файлы которой становятся файлами в файловой системе самого компьютера. Обмен по MTP позволяет устройству продолжать работать, когда оно подключено к компьютеру.

Emulated это не Emulated
Сначала я пытался прочесть файл с карточки на эмуляторе (из этого так ничего и не вышло). Функция getExternalStorageDirectory() давала мне /storage/emulated/0, и я думал, что «emulated» – это потому что на эмуляторе. Но когда я подцепил реальный планшет, слово «emulated» никуда не исчезло. Я стал рыться в интернете и обнаружил, что «Emulated storage is provided by exposing a portion of internal storage through an emulation layer and has been available since Android 3.0.» – то есть это просто кусок внутренней памяти, которая путём какой-то эмуляции делается доступной для пользователя, в отличие от собственно внутренней памяти.

При этом с точки зрения системы доступная для пользователя папка называется /storage/emulated/0, а при подключении к компьютеру по USB это просто одна из двух главных папок устройства – у меня в Windows Explorer она называется Tablet. Вторая папка у меня называется Card, и это и есть настоящая внешняя карточка.

Нет стандартных средств добраться из приложения до файлов на внешней карточке. Все попытки добраться до настоящей внешней карточки делаются с помощью неких трюков. Самое интересное, что я нашел, это статья на http://futurewithdreams.blogspot.com/2014/01/get-external-sdcard-location-in-android.html — парень читает таблицу смонтированных устройств /proc/mounts, таблицу volume daemons /system/etc/vold.fstab, сравнивает их и выбирает те тома, которые оказываются съёмными (с помощью Environment.isExternalStorageRemovable()).

Оказалось, что несистемным приложениям в принципе запрещено напрямую обращаться к съёмной карточке! Похоже, что это было так всегда, но вот начиная с версии Android 6 Marshmallow написано: внешняя карточка может быть определена как Portable либо Adoptable. Adoptable – это как бы «усыновляемая» память которая может быть «adopted», то есть взята в систему (примерно как кот с улицы в дом – это тоже называется to adopt) и использована как внутренняя. Для этого ее надо особым образом отформатировать и не вынимать, иначе не факт, что система продолжит нормально работать.

Portable – это нормальная съёмная карточка, но несистемным приложениям запрещено обращаться из программ к файлам на ней! Вот что написано в https://source.android.com/devices/storage/traditional.html:

Android 6.0 supports portable storage devices which are only connected to the device for a short period of time, like USB flash drives. When a user inserts a new portable device, the platform shows a notification to let them copy or manage the contents of that device. In Android 6.0, any device that is not adopted is considered portable. Because portable storage is connected for only a short time, the platform avoids heavy operations such as media scanning. Third-party apps must go through the Storage Access Framework to interact with files on portable storage; direct access is explicitly blocked for privacy and security reasons.

Если я правильно понял, этот самый Storage Access Framework позволяет работать с документом на карточке через диалог (открыть файл/сохранить файл), а вот прочитать или записать файл на карточке непосредственно из программы невозможно.

Общий вывод – реально из программы можно работать только с файлами на предоставляемой пользователю части встроенной памяти устройства, а на съёмной карточке – нет.

Это напоминает войну Microsoft с пользователями и разработчиками по поводу диска C:, компания уговаривала не устраивать беспорядок в корне этого диска, а ещё лучше — перенести свои файлы на другой диск. Но явных запретов не было.

Состояние на текущий момент

Гугл утверждает, что с версии Android 10 Q стандартный доступ к файлам будет прекращён. Ещё в Android 4.4 появился Storage Access Framework, который и должен стать заменой для работы с файлами.

Методы Environment.getExternalStorageDirectory() и Environment.getExternalStoragePublicDirectory() признаны устаревшими и будут недоступны. Даже если они будут возвращать корректные значения, ими вы не сможете воспользоваться.

В Android 7.0 добавили исключение FileUriExposedException, чтобы разработчики перестали использовать схему file://Uri.

Можно создавать файлы в корневой папке карточки при помощи Environment.getExternalStorageDirectory(), а также папки с вложенными файлами. Если папка уже существует, то у вас не будет доступа на запись (если это не ваша папка).

Если вы что-то записали, то сможете и прочитать. Чужое читать нельзя.

Кстати, разрешения на чтение и запись файлов не требуются, а READ_EXTERNAL_STORAGE и WRITE_EXTERNAL_STORAGE объявлены устаревшими.

Другие приложения не могут получить доступ к файлам вашего приложения. Файлы, которые вы создали через getExternalFilesDir(), доступны через Storage Access Framework, кроме файлов, созданных в корне карточки (что-то я совсем запутался). Ещё можно дать доступ через FileProvider.

При подключении USB-кабеля через getExternalFilesDir(), вы можете увидеть свои файлы и папки, а также файлы и папки пользователя. При этом файлы и папки пользователя на корневой папке вы не увидите. Вам не поможет даже adb или Device File Explorer студии.

Что делать?

Пользуйтесь методами класса Context, типа getExternalFilesDir(), getExternalCacheDir(), getExternalMediaDirs(), getObbDir() и им подобными, чтобы найти место для записи.

Используйте Storage Access Framework.

Используйте MediaStore для мультимедийных файлов.

Используйте FileProvider, чтобы файлы были видимы другим приложениям через ACTION_VIEW/ACTION_SEND.

Android 10: Появился новый флаг android:allowExternalStorageSandbox=»false» и метод Environment.isExternalStorageSandboxed() для работы с песочницей. Флаг android:requestLegacyExternalStorage=»true» для приложений, которые ещё используют старую модель доступа к файлам.

Как временное решение можно добавить в блок манифеста application атрибут android:requestLegacyExternalStorage=»true», чтобы доступ к файлам был как раньше в Android 4.4-9.0.

Android 11

Если вы создаёте файловый менеджер, то ему нужны возможности для просмотра файлов. Для этого следует установить разрешение MANAGE_EXTERNAL_STORAGE или использовать атрибут android:requestLegacyExternalStorage=»true» (см. выше).

Источник

Как смонтировать на Andorid файловую систему внешнего USB-накопителя

Что делать, если ваш планшет на Android не распознаёт подключенный к нему USB-носитель? Вероятно, файловая система внешнего накопителя не поддерживается устройством и вам нужно установить программу Microsoft exFAT/NTFS for USB.

Microsoft exFAT/NTFS for USB позволяет мгновенно предоставить доступ к данным на USB-накопителях, отформатированных в Microsoft exFAT, NTFS, FAT32, HFS+, с любого Android-устройства: смартфона, планшетного компьютера или Android TV.

Файловые системы, доступные как для покупки внутри приложения, так и для пробного периода:

• NTFS: 253 руб.
• exFAT: 281 руб. (*не поддерживается на ТВ устройствах)
• HFS+: 253 руб.
• FAT32: 253 руб.
• Пакет поддержки всех файловых систем: 649 руб.

Последняя версия Microsoft exFAT/NTFS for USB поддерживает технологию Android Storage Access Framework (SAF) и работает со встроенным файловым менеджером Android, что позволяет управлять файлами на USB-накопителе без установки дополнительных приложений.

КАК РАБОТАТЬ C ПРИЛОЖЕНИЕМ

2. Подключите к Android-устройству USB-накопитель и смонтируйте нужный раздел.

3. Нажмите на кнопку «Browse» и выберите:

• Open files — позволяет открывать и просматривать документы и медиафайлы на USB-накопителе;
• Manage files — позволяет копировать, перемещать, удалять файлы с помощью встроенного файлового менеджера Android.

Источник

Android 11 storage FAQ

First introduced in Android 10, scoped storage is designed to protect app and user data and reduce file clutter. Since then, you’ve provided a lot of valuable feedback, which has helped us evolve the feature — thank you. Android 11 includes several notable enhancements that are based on your feedback. For example, we’ve enabled direct file path access to media files to improve compatibility of existing code and libraries. We understand that many apps, especially complex ones like Viber, require thoughtful planning to adopt scoped storage in order to continue supporting existing users, ensure adherence to current storage best practices, and maintain backward compatibility. Based on conversations with developers and lively discussions on public forums, we’ve prepared an FAQ to help you better understand various capabilities, behavior changes, and restrictions in scoped storage.

Does Scoped Storage allow apps to access files with file paths, using File API, for example?

• We recognize that some apps rely on code or libraries that access media file paths directly. Therefore on Android 11, apps with the read external storage permission are able to access files with file paths in the scoped storage environment. On Android 10 devices, this is not available to apps in the scoped storage environment unless they have opted-out by setting the android:requestLegacyExternalStorage manifest attribute. To ensure continuity across Android versions, if your app targets Android 10 or above, you should also opt-out. See scoped storage best practices for details.

How does the performance of file path access compare to Media Store APIs?

• The performance really depends on the exact use case. For sequential reads like in the case of playback of videos, file path access offers comparable performance to Media Store. However for random reads and writes, using file path can be up to twice as slow. For the fastest and most consistent read and writes we recommend Media Store APIs.

My app needs broad access to shared storage. Is Storage Access Framework the only option available?

• Storage Access Framework (SAF) is indeed one option that allows the user to grant access to directories and files. However, note that there are access restrictions to certain directories, such as the root and Android/data directories. While the majority of apps that need storage access can use best practices such as SAF or Media Store API, there could be cases where apps need broad access to shared storage or can’t do so efficiently with these best practices. For these cases, we have added the MANAGE_EXTERNAL_STORAGE permission to give access to all files on external storage, except the Android/data and Android/obb directories. To learn more about related Google Play guidelines, read the updated policy from the Policy Help Center.

What categories of apps should request the MANAGE_EXTERNAL_STORAGE permission?

• The MANAGE_EXTERNAL_STORAGE permission is intended for apps that have a core use case that requires broad access of files on a device, but cannot do so efficiently using scoped storage best practices. While it isn’t practical to enumerate all possible use cases, some use cases include file managers, backup and restore, anti-virus apps or productivity file editing apps.

Does using Storage Access Framework require Google Play policy approval?

• The Storage Access Framework has been in the platform since Android 4.4. Accessing files via Storage Access Framework gives users better control because the user is involved in picking files and it doesn’t require any user permissions. There’s no Google Play policy related to its usage.

Are there any further restrictions to using Storage Access Framework in Android 11 as compared to Android 10?

• Apps that target Android 11 (API level 30) and use Storage Access Framework will no longer be able to grant access to directories, such as the root directory of the SD card and the Download directory. Regardless of target SDK, Storage Access Framework on Android 11 cannot be used to gain access to Android/data and Android/obb directories. Learn more about these restrictions and ways to test the behaviors.

How can apps test out Scoped Storage changes?

• Apps can test out scoped storage behavior related to direct file path access or Media Store APIs via these compatibility flags. There’s also another compatibility flag to test the restrictions to access certain paths with Storage Access Framework.

Are apps in scoped storage limited to writing files into their app-specific data directories?

• In scoped storage, apps can contribute media files to Media Store collections. Media Store will put the files into well organized folders like DCIM, Movies, Download, and so on based on file type. For all such files, apps can also continue to have access via File APIs as well. The OS maintains a system to attribute an app to each media store file, so apps can read/write files that they originally contributed to the Media Store without needing storage permissions.

What is the guidance around using the Media Store DATA column since it’s been deprecated?

• On Android 10, apps in the scoped storage environment cannot access files using the file path. To be consistent with this design, we deprecated the DATA column then. Based on your feedback on the needs to work with existing native code or libraries, Android 11 now supports file path access for apps in scoped storage. Accordingly, the DATA column could actually be useful for some scenarios. For inserts and updates into the Media Store, apps in Scoped Storage should use DISPLAY_NAME and RELATIVE_PATH columns. They can no longer use the DATA column for this. When reading Media Store entries for files that exist on disk, the DATA column will have a valid file path, which can be used with the File API or NDK file libraries. Apps should however be prepared to handle any file I/O errors from these operations and should not assume the file is always available.

For apps that have opted out of Scoped Storage, when will they have to be compatible with Scoped Storage?

• On devices running Android 11 or higher, apps will be put into Scoped Storage as soon as they target Android 11 or higher.

What is the recommended way to migrate data that we currently store outside of Scoped Storage?

• preserveLegacyExternalStorage flag allows an app to retain legacy storage access on upgrades even while targeting Android 11. However beware that on new installs on Android 11, this flag has no effect. Please make code changes to adapt to Scoped Storage before targeting Android 11. Learn more about data migration best practices.

Are there any exceptions for Android/obb directories given that some package installers, like app stores, need access to it?

• Apps that hold the REQUEST_INSTALL_PACKAGES permission can access other apps’ Android/obb directories.

We hope you find this FAQ useful in planning your adoption of scoped storage. Please visit our best practice documentation for more information.

Источник