Хабрахабр

Android Storage: Internal, External, Removable. Часть 1/3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Что еще более важно, внутреннее хранилище не всегда находится в одном месте. 0 для телефонов. 2 для планшетов и Android 5. Хотя вышеупомянутый каталог по-прежнему используется для основного пользователя, не гарантируется, что он же будет использоваться для вторичных учетных записей. Каждый пользователь получает свое собственное «внутреннее хранилище».

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

В командной строке вы можете использовать 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, чтобы загрузить его на свой компьютер, или получить доступ к нему другими обычными способами (например, путем монтирования устройства в качестве диска).

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

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

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

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

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

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

Ну, а как насчет android:sharedUserId ?

Не советую.

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Проверьте также

Закрыть
Кнопка «Наверх»
Закрыть