App specific external storage android

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

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

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

Internal Storage

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

То, что пользователи считают Internal Storage

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

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

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

Что Google считает Internal Storage

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

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

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

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

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

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

Где хранится Internal Storage … Иногда

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

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

Где хранится Internal Storage … Остальное время

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

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

Исследуем Internal Storage

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 недостаточна для того, что они хотят хранить, поэтому они переходят на съемные хранилища… которые представляют собой банку с червями (прим. имеются в виду ἕλμινς) — источник многих непредсказуемых и сложных проблем.

F.A.Q. по Internal Storage

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

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

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

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%. ИМХО, вы преуспеете больше, сосредоточив свою инженерную работу на написании лучшего приложения, вместо того, чтобы тратить время на защиту от рутованных устройств.

Источник

Android: Read and write to app-specific external storage #39414

Comments

shafy commented Jun 9, 2020

Godot version:
3.2.1.rc1

OS/device including version:
Oculus Quest

Issue description:
Per Android documentation, app can store data in external storage without requesting additional permissions as long as it’s in the app-specific folder. On the Oculus Quest, this folder is /sdcard/Android/data/com.yourpackage.name/ .

Now, this works if that folder already exists (e.g., created manually with adb). However, I can’t create that folder through Godot using make_dir() or `make_dir_recursive(). It returns Error 20 (ERR_CANT_CREATE).

I would expect that either I can create the folder at that the folder is created automatically once read and write external storage permissions are grated in the Android Manifest.

I’m not sure if this is related to issue #38913 ?

Steps to reproduce:

• Enable read and write external storage in your Android export settings.
• Make sure your Android device (preferrable Oculus Quest) is attached to your computer
• Run this in a script’s ready function:

• You’ll get an error.
• Create that folder manually in adb:

The text was updated successfully, but these errors were encountered:

Constannnnnt commented Jul 22, 2020

I met this issue several days before and it seemed that I walked around it. I had to say I did not know what actually solved the issue but it could possibly be the cause, mentioned by @volzhs at #23004. So, let me repeat what I did.

First Shot

Godot version:
3.2.1.stable (the version I used at that moment)

OS/device including version:
Oculus Quest

Results:
I followed the steps you said and was able to reproduce the issue. And the weird thing to me was that although I enabled the read and write external storage at Android export settings, when I check the permissions at the runtime,

the outputs were that not only did it fail to have those two expected permissions, but also it still did not have the permissions even I requested them successfully («successfully» here means the output returned OK, but when I checked granted_permissions again, permissions not exist).

Second Shot

I thought maybe it was just the version, and the latest version might solve this issue.

Godot version:
3.2.2.stable

OS/device including version:
Oculus Quest

Results:
Repeat those steps. The same issues exist.

Third Shot: Issue Solved

I looked around the issues and pulls (e.g. #32600) at the repo regarding read&write permission issues and it came to me that if I did not have those permissions even I enabled them at the android export setting, can I see and edit the AndroidManifest.xml directly to ensure that I do have these permissions? Basically, by following this tutorial, I used the default android build and I only need to click the little android button at the top-right corner to compile, build and run on the Quest. Therefore, I then followed the custom android build.

Godot version:
3.2.2.stable

OS/device including version:
Oculus Quest

Results:
Issues resolved. I was able to create a directory and write a CSV file and save it on the Quest. I just and only followed the custom build and even did not modify the AndroidManifest.xml at all. I checked the granted_permissions and this time, it returned that the project had the read&write permissions.

Forth Shot

So then, I was wondering this walkaround could work on 3.2.1.stable

Godot version:
3.2.1.stable

OS/device including version:
Oculus Quest

Results:
Unfortunately, it failed and returned that read&write permissions were not granted.

In a word, check my third shot and sorry that I did not have enough time to explore what was really happening there with the issue, and what I could help is just a walkaround. If you had enough time, probably check all four shots to reproduce my experiments.

shafy commented Jul 23, 2020

Thanks @Constannnnnt — I’ll have a look.

Railwanderer commented Oct 3, 2020

Hey I ran into this problem in Godot 3.2.1 stable version.
I am unable to read/write to any path on Android.
I tried adding permissions in the Manifest and I used the export settings in the export GUI.
I also tried to use a FileDialog, which would always stay empty.

shafy commented Oct 6, 2020

Yeah @Railwanderer it’s still not fixed. You can try @Constannnnnt ‘s workaround if you need it.

eternaldensity commented Oct 19, 2020

Yeah I was having this problem: even using adb to give the permission to read external files (and confirming in my game that it had that permission) didn’t help and it still would not open files (though it would confirm that they existed, since it would report the ‘can’t open’ error code rather than ‘not found’). I’d been using Godot 3.2 and updgrading to 3.2.3 didn’t alter anything.

So I followed Constannnnnt’s solution of enabling the custom android build checkbox. That told me that my Android SDK path was wrong (so I fixed that) and I was missing the JDK (so I fixed that too) and then it built and now loading files from the Download directory just works. So that’s good.

viindicater commented Dec 22, 2020 •

I’ve figured out the cause, there just needs to be a call to getExternalFilesDir (which creates such directories automatically without storage permissions) ( https://developer.android.com/reference/android/content/Context#getExternalFilesDir(java.lang.String) )

EXOMODE commented Dec 27, 2020

To implement a mechanism for loading content from the server side and saving game settings, I ran into the same problems on the Android platform. I managed to solve the read/write access rights issue, but this solution is relevant for older versions of the system. When trying to write on the Android 11 emulator (API 30), Directory.make_dir_recursive() returns an error even after granting access rights. I suspect that it may be really in the new security requirements of the platform, but unfortunately I do not have time for a deeper study of the issue now.

EXOMODE commented Dec 27, 2020

I found a very useful comment on stackoverflow. As expected, the fact is that starting with Android 10, there is no longer access to the device’s file system outside of the application context. But for now, it is possible to return to the old scheme by adding in AndroidManifest.xml custom build the following attribute in the application tag:

viindicater commented Jan 1, 2021 •

I found a very useful comment on stackoverflow. As expected, the fact is that starting with Android 10, there is no longer access to the device’s file system outside of the application context. But for now, it is possible to return to the old scheme by adding in AndroidManifest.xml custom build the following attribute in the application tag:

Godot already has that in android builds by default afaik, and also

To implement a mechanism for loading content from the server side and saving game settings, I ran into the same problems on the Android platform. I managed to solve the read/write access rights issue, but this solution is relevant for older versions of the system. When trying to write on the Android 11 emulator (API 30), Directory.make_dir_recursive() returns an error even after granting access rights. I suspect that it may be really in the new security requirements of the platform, but unfortunately I do not have time for a deeper study of the issue now.

I’ve tested it (with android studio making apps), and the only way to be able to make that directory is by https://developer.android.com/reference/android/content/Context#getExternalFilesDir(java.lang.String) . I’ve been trying to make a plugin to make this API call but for some reason my plugin doesn’t work (Engine.has_singleton(myPluginName) returns false idk why). Guess I’m stuck with needlessly asking for storage perms til someone makes a plugin and/or Godot gets this API call built in.

EXOMODE commented Jan 1, 2021

Я нашел очень полезный комментарий к stackoverflow. Как и ожидалось, дело в том, что начиная с Android 10, больше нет доступа к файловой системе устройства вне контекста приложения. Но пока можно вернуться к старой схеме, добавив в нее AndroidManifest.xml пользовательское построение следующего атрибута в теге приложения:

Годо уже имеет то, что в android строит по умолчанию afaik, а также

Чтобы реализовать механизм загрузки контента со стороны сервера и сохранения настроек игры, я столкнулся с теми же проблемами на платформе Android. Мне удалось решить проблему прав доступа на чтение и запись, но это решение актуально для более старых версий системы. При попытке записи на эмулятор Android 11 (API 30) Directory.make_dir_recursive() возвращается ошибка даже после предоставления прав доступа. Я подозреваю, что это действительно может быть связано с новыми требованиями безопасности платформы, но, к сожалению, у меня сейчас нет времени для более глубокого изучения этого вопроса.

Я протестировал его (с помощью приложений для создания android studio), и единственный способ сделать этот каталог-это https://developer.android.com/reference/android/content/Context#getExternalFilesDir (java. lang.Строка). Я пытался сделать плагин, чтобы сделать этот вызов API, но по какой-то причине мой плагин не работает (Engine.has_singleton(myPluginName) возвращает false idk why). Наверное, я застрял с бесполезным запросом завивки хранилища, пока кто-то не сделает плагин и/или Godot не получит встроенный вызов API.

In other words, Android 11 and higher need a platform unification patch. Well, we are waiting 🙂 fortunately, this is not relevant yet, because the transition to a new version of Android is just beginning and the current capabilities of the engine are enough to work correctly with the file system on all previous versions

Источник