Всем, кто, несмотря ни на что, сумел сделать правильный выбор.

Это перевод серии статей от Mark Murphy из CommonsWare, широко известного на stackoverflow, а так же автора книг “The Busy Coder’s Guide to Android Development”, “Android’s Architecture Components”. Некоторые термины оставлены не переведенными специально.

Существует много путаницы в отношении модели хранилища Android. Путаницы стало значительно больше с изменениями Android 4.4 в Storage Model, и с тех пор ситуация не улучшилась. Есть бесчисленное множество вопросов на Stack Overflow и тому подобных ресурсах, где люди явно не совсем разбираются в различных моделях хранилищ Android.

В зависимости от модели вашего устройства пользователи в конечном итоге придут в «Настройки» —> «Хранилище на этом устройстве» (Settings —> Storage on their device) или в эквивалентном месте, и могут видеть экран, который описывает «Внутреннее хранилище».

Пользователь думает, что вся встроенная флешка — это «внутреннее хранилище» (Internal Storage). К счастью, Google начал менять этот термин с Android 8.0, перейдя к «general storage» вместо «internal storage».

Тем не менее, пользователи могут по-прежнему видеть «внутреннее хранилище» в таких местах, как окно проводника в Windows, когда их устройство подключено через USB.

Увы, то, что видят пользователи это не то же самое, что Android SDK считает «внутренним хранилищем», что приводит к некоторой путанице. Если вы читали документацию на Android по внутреннему хранилищу, то это описание … как минимум туманно (прим. текст изменился со времени написания статьи):

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

По правде говоря, Android SDK определяет «внутреннее хранилище» как особый каталог, уникальный для вашего приложения, где ваше приложение может размещать файлы. Как было предложено в документации, эти файлы по умолчанию предназначены для чтения и записи для вашего приложения и запрещены для любого другого приложения (исключение: пользователи, работающие с файловыми менеджерами с привилегиями суперпользователя на rooted устройствах могут получить доступ ко всему).

В Context есть несколько базовых методов, которые предоставляют вам доступ к внутреннему хранилищу, в том числе:

  • getCacheDir()
  • getDir()
  • getDatabasePath()
  • getFilesDir()
  • openFileInput()
  • openFileOutput()

Другие методы будут опираться на них, такие как openOrCreateDatabase(). Другие классы также будут полагаться на них, такие как SQLiteOpenHelper и SharedPreferences.

Если вы просматриваете различные сообщения в блогах, ответы на StackOverflow и книги, выпущенные в 2012 году или ранее, вам сообщается, что «внутреннее хранилище» вашего приложения находится по адресу: /data/data/your.application.package.name.

Внутри будут некоторые каталоги, автоматически созданные Android, поскольку вы используете некоторые из методов Context. Например, getFilesDir() возвращает объект File, указывающий на каталог files/ во внутреннем хранилище вашего приложения.

Однако не всегда внутреннее хранилище вашего приложения находится в указанном месте. Для разработчиков есть одно правило, которое вы должны усвоить из этой серии сообщений в блоге, это:

NEVER HARDCODE PATHS.

Время от времени я вижу, что разработчики делают что-то вроде этого:

File f=new File("/data/data/their.app.package.name/files/foo.txt");

Это не преступление, это хуже, это — ошибка.

Правильный ход, да и писать меньше:

File f=new File(getFilesDir(), "foo.txt");

Что еще более важно, внутреннее хранилище не всегда находится в одном месте. Примечательно, что у нас есть понятие отдельных профилей пользователей (separate user profiles), начиная с Android 4.2 для планшетов и Android 5.0 для телефонов. Каждый пользователь получает свое собственное «внутреннее хранилище». Хотя вышеупомянутый каталог по-прежнему используется для основного пользователя, не гарантируется, что он же будет использоваться для вторичных учетных записей.

Device File Explorer tool в Android Studio 3.0+ может просматривать все внутренние хранилища на эмуляторе, а также внутреннее хранилище отлаживаемых приложений на продакшн устройствах.

В командной строке вы можете использовать adb с опцией run-as.

Например, чтобы загрузить базу данных из внутреннего хранилища основного пользователя на вашу девелоперскую машину, вы можете использовать:

adb shell 'run-as your.application.package.name cp /data/data/your.application.package.name/databases/dbname.db /sdcard'

Обратите внимание, что:

  • Вам нужно будет изменить пункт назначения туда, где на вашем устройстве монтируется внешнее хранилище (показано здесь как /sdcard/, которое не будет одинаковым на всех устройствах)
  • Возможно, вам придется использовать cat вместо cp на старых устройствах
  • После того, как файл будет находиться на внешнем хранилище, вы сможете использовать adb pull, чтобы загрузить его на свой компьютер, или получить доступ к нему другими обычными способами (например, путем монтирования устройства в качестве диска).

На старых устройствах Android 1.x и 2.x внутреннее хранилище обычно находилось в выделенном разделе файловой системы, и этот раздел обычно был довольно крошечным. HTC Dream (a.k.a., T-Mobile G1), оригинальное Android-устройство, обладал огромными 70 МБ встроенной памяти для использования всеми приложениями (это не опечатка, в то время мы измеряли память в мегабайтах).

К тому времени, когда вышли 2.3 устройства, внутреннее хранилище могло быть размером 1 ГБ.

Android 3.0 изменил модель хранилища, так как внутреннее хранилище стало больше объемом. У устройств, которые рекламируют как имеющее 4 ГБ, 8 ГБ, 16 ГБ и т.д. пространства для хранения, обычно имелось все это (минус существующее содержимое) доступное для внутреннего хранилища. Мы рассмотрим, что изменилось в Android 3.0 и его влияние на модель хранилища в следующих постах про внешнее хранилище.

Для Android 1.x и 2.x внутреннее хранилище было действительно только для небольших файлов, и вам нужно было использовать внешнее хранилище для всего остального. Android 3.0+ означает, что для большинства устройств и большинства пользователей внутреннее хранилище отлично подходит для файлов, которые не предназначены для обычного использования другими приложениями или доступны пользователю независимо от вашего приложения. Однако некоторые опытные пользователи обнаруживают, что даже on-board flash недостаточна для того, что они хотят хранить, поэтому они переходят на съемные хранилища… которые представляют собой банку с червями (прим. имеются в виду ἕλμινς) — источник многих непредсказуемых и сложных проблем.

Должен ли я делать файлы во внутреннем хранилище World-Readable или World-Writeable?

О, $БОГИ, нет. Используйте FileProvider и обслуживайте этот контент с помощью реализации ContentProvider. После этого вы, по крайней мере, имеете возможность использовать систему разрешений Android для управления доступом к этим файлам, в отличие от вашего варианта, когда любое приложение в системе может испортить эти файлы.

Не советую.

android: sharedUserId — это атрибут, который вы можете поместить в манифест, который указывает логический идентификатор пользователя, который будет использоваться для вашего приложения. Любое другое приложение, которое установлено, которое подписывается одним и тем же ключом подписи и запрашивает тот же android:sharedUserId будет использовать одного и того же пользователя Linux с точки зрения безопасности. Эффект заключается в том, что эти два приложения смогут безнаказанно работать с файлами друг друга, так как эти файлы принадлежат одному и тому же пользователю Linux.

Этот атрибут реально предназначен для предварительно установленных приложений, таких как software suite предварительно загруженный производителем устройства, мобильным оператором или разработчиком модифицированной ROM прошивки. В частности, как только вы единожды установите свое приложение, вы не сможете затем безболезненно изменить свое значение android:sharedUserId не заблокировав при этом доступ пользователю к любым существующим файлам… поскольку Android не изменяет права владельца на существующие файлы при изменении учетной записи пользователя Linux, под которой запускается приложение.

Существуют различные риски при одновременном доступе нескольких процессов к файлам. Некоторые подсистемы, такие как SQLite, имеют встроенную логику для решения этой проблемы. Но если вы сами организуете свой собственный доступ к файлу (например, через File и Java I/O), вам нужно что-то делать с одновременным доступом, а это сложно.

Вам также нужно обрабатывать ситуацию, когда одно приложение деинсталлируется, удаляя файлы, которые использовало другое приложение. В модели hub-and-spoke, например, с приложением и набором плагинов, возможно, это не так рискованно. В других моделях, где приложения более равноправны, вы не можете позволить себе потерять данные своего приложения только потому, что пользователь решил удалить какое-то отдельное приложение.

Наконец, вы не знаете, что может принести будущее. Прямо сейчас вы можете рассматривать свой набор приложений в виде набора с тесной связью. Кто-то, кто приобретает эти приложения или приобретает вашу фирму, может пожелать пойти другим путем. Использование возможностей совместного доступа к данным, которые более слабо связаны, например ContentProvider, дает вам большую гибкость. В идеальном мире ваше приложение должно относиться к другим приложениям как к достаточно надежному, но не всегда доступному ресурсу, так же, как к вашему собственному веб-сервису.

Как запретить пользователям rooted устройств доступ к моим файлам во внутреннем хранилище?

Просто не помещайте файлы во внутреннее хранилище. Пользователи rooted устройств могут получить доступ к тому, что им нужно на устройстве, поэтому единственный способ предотвратить их доступ к вашим данным — не иметь их на устройстве.

Некоторые разработчики попытаются зашифровать свои файлы с помощью жестко запрограммированного пароля, чтобы пользователи rooted устройств не могли использовать эти файлы. Это создаст эффект «лежачего полицейского» на короткое время. Все, что требуется, — это один заинтересованный в реверс-инжиниринге вашего приложения человек, определивший, как расшифровать эти файлы, а затем написавший сообщение в блоге или форуме о том, как это сделать.

В целом, относительно мало людей с rooted устройствами — я оцениваю их на уровне менее 1%. ИМХО, вы преуспеете больше, сосредоточив свою инженерную работу на написании лучшего приложения, вместо того, чтобы тратить время на защиту от рутованных устройств.

73 6.4k 73

Краткий обзор Android External Storage

  1. Primary External Storage. Встроенное общее хранилище будет доступно пользователю, если он подключит USB кабель и вмонтирует его в виде диска на компьютере.
  2. Secondary External Storage. Съемное хранилище данных, например SD- карта

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

Пример работы с Android External Storage

Сегодня мы напишем простое приложение, которое будет работать с внешней памятью Android устройства. Структура проекта ничем не отличается простого приложения Hello World, которое мы писали в первых уроках по Android. Создайте простой проект в Android Studio и приступим к программированию.

Прежде всего мы должны получить разрешение на чтение и запись данных, расположенных на внешней памяти. Для этого в AndroidManifest.xml добавьте следующие разрешения:

Ниже представлен макет файла activity_main.xml:

Как видно из макета, мы вынесли текст на кнопках и в виджете EditText в файл strings.xml (всегда так делайте):

Листинг класса MainActivity представлен ниже:

Обратите внимание:

Метод Environment.getExternalStorageState() возвращает путь к внутреннему хранилищу по адресу /mnt/sdcard.

Метод getExternalFilesDir() возвращает путь к файлам папки android/data/data/application_package/ на SD-карте. Он используется для хранения необходимых вашему приложения файлов, например, скачанных из интернета изображений или кэш приложения). Следует отметить, что с удалением приложения все файлы, хранящиеся в этой папке, также будут удалены.

Ниже представлен результат работы с External Storage на реальном устройстве Android.

Сначала вводим в поле какие-то данные, потом нажимаем «Сохранить данные», далее очищаем поле и нажимаем «Считать данные»:

Многие пользователи приложений интересуются — где хранятся создаваемые файлы? Как их посмотреть? Очищается ли информация после удаления программы? Чтобы разобраться в таких вопросах, обратимся к терминам «Internal Storage» и «External Storage».

Для начала приведем переводы терминов. Storage — место хранения, Internal — внутреннее, External — внешнее. Простыми словами, Storage в широком смысле слова — это память смартфона, в которой хранятся данные.

Что такое Internal Storage?

Internal Storage представляет собой внутреннее хранилище информации, которое есть на каждом телефоне независимо от поддержки карт памяти. Эта область памяти располагается в системном разделе /data и является защищенной. Основное предназначение внутреннего хранилища — обеспечение безопасности пользовательской информации. Таким образом, владелец телефона не может случайно удалить важные файлы, тем самым нарушив функциональность устройства.

После удаления приложения информация автоматически очищается системой. Такая возможность предусмотрена разработчиками операционной системы Android в целях предотвращения засорения памяти. Файлы, хранящиеся в каталоге Internal Storage, просто становятся ненужными, поэтому удаляются вместе с программами и играми.

Что такое External Storage?

Раньше операционная система Android присваивала картам памяти название External Storage (внешнее хранилище). Сейчас его предназначение — хранение доступной пользователю информации. Здесь могут располагаться фотографии, видеозаписи, музыка и другие разновидности информации.

Управлять содержимым хранилища External Storage можно встроенными средствами телефона или любым менеджером файлов. Владелец смартфона может перемешать, переименовывать, копировать, передавать и удалять файлы. Следует заметить, что удаление некоторой информации способно повлиять на работоспособность приложений, поэтому перед каждым действием нужно проверять предназначение файла.

Итоги

Internal Storage — внутреннее хранилище информации для временных файлов приложений. External Storage выполняет аналогичную задачу, позволяя хранить постоянные и временные файлы. Разница между разделами заключается в защищенности.

The Android Developer Challenge is back! Submit your idea before December 2.

Android uses a file system that's similar to disk-based file systems on other platforms. The system provides several options for you to save your app data:

  • App-specific storage: Store files that are meant for your app's use only, either in dedicated directories within an internal storage volume or different dedicated directories within external storage. Use the directories within internal storage to save sensitive information that other apps shouldn't access.
  • Shared storage: Store files that your app intends to share with other apps, including media, documents, and other files.
  • Preferences: Store private, primitive data in key-value pairs.
  • Databases: Store structured data in a private database using the Room persistence library.

The characteristics of these options are summarized in the following table:

Type of content Access method Permissions needed Can other apps access? Files removed on app uninstall?
App-specific files Files meant for your app’s use only From internal storage, getFilesDir() or getCacheDir()From external storage, getExternalFilesDir() or getExternalCacheDir() Yes
Media Shareable media files (images, audio files, videos) MediaStore API READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE when accessing other apps’ files on Android 10 (API level 29) or higher Permissions are required for all files on Android 9 (API level 28) or lower Yes, though the other app needs the READ_EXTERNAL_STORAGE permission No
Documents and other files Other types of shareable content, including downloaded files Storage Access Framework None Yes, through the system file picker No
App preferences Key-value pairs Jetpack Preferences library None No Yes
Database Structured data Room persistence library None No Yes

The solution you choose depends on your specific needs:

How much space does your data require?
Internal storage has limited space for app-specific data. Use other types of storage if you need to save a substantial amount of data.
How reliable does data access need to be?
If your app's basic functionality requires certain data, such as when your app is starting up, place the data within internal storage directory or a database. App-specific files that are stored in external storage aren't always accessible because some devices allow users to remove a physical device that corresponds to external storage.
What kind of data do you need to store?
If you have data that's only meaningful for your app, use app-specific storage. For shareable media content, use shared storage so that other apps can access the content. For structured data, use either preferences (for key-value data) or a database (for data that contains more than 2 columns).
Should the data be private to your app?
When storing sensitive data—data that shouldn't be accessible from any other app—use internal storage, preferences, or a database. Internal storage has the added benefit of the data being hidden from users.

Categories of storage locations

Android provides two types of physical storage locations: internal storage and external storage. On most devices, internal storage is smaller than external storage. However, internal storage is always available on all devices, making it a more reliable place to put data on which your app depends.

Removable volumes, such as an SD card, appear in the file system as part of external storage. Android represents these devices using a path, such as /sdcard.

Apps themselves are stored within internal storage by default. If your APK size is very large, however, you can indicate a preference within your app's manifest file to install your app on external storage instead:

Permissions and access to external storage

Android defines the following permissions for read-and-write access to external storage: READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE.

On earlier versions of Android, apps needed to declare these permissions to access any file outside the app-specific directories on external storage. More recent versions of Android rely more on a file's purpose than its location for determining an app's ability to access that file. This purpose-based storage model improves user privacy because apps are given access only to the areas of the device's file system that they actually use.

Scoped storage

To give users more control over their files and to limit file clutter, apps that target Android 10 (API level 29) and higher are given scoped access into external storage, or scoped storage, by default. Such apps have access only to the app-specific directory on external storage, as well as specific types of media that the app has created.

Use scoped storage unless your app needs access to a file that's stored outside of an app-specific directory and outside of a directory that the MediaStore APIs can access. If you store app-specific files on external storage, you can make it easier to adopt scoped storage by placing these files in an app-specific directory on external storage. That way, your app maintains access to these files when scoped storage is enabled.

If your app has another use case that isn't covered by scoped storage, file a feature request and use the app compatibility feature that the platform provides.

Best practices for operating on files

This section presents a few general best practices for opening and sharing files from your app.

Don't open and close files repeatedly

To help maintain your app's performance, don't open and close the same file multiple times. It's expensive for the system to open a file and to read a file for the first time.

If you want to share individual files or app data with other apps, Android provides the following APIs:

  • If you want to share specific files with other apps, use the FileProvider API.
  • If you want to expose data to other apps, you can use a content provider. Content providers give you full control of what read-and-write access is available to other apps. Although you can use content providers with any storage medium, they're most commonly used with databases.

View files on a device

To view the files stored on a device, use Android Studio's Device File Explorer.

Additional resources

For more information about data storage, consult the following resources.

Используемые источники:

  • https://m.habr.com/post/429338/
  • https://javadevblog.com/android-external-storage-primer-raboty-s-vneshnej-pamyat-yu.html
  • https://androidlime.ru/storage-in-a-smartphone-what-is-it
  • https://developer.android.com/training/data-storage

СХОЖИЕ СТАТЬИБОЛЬШЕ ОТ АВТОРА

ОСТАВЬТЕ ОТВЕТ

Please enter your name here
Please enter your comment!