Com android shared storage

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

Источник

Scoped Storage in Android 10 & Android 11

A secure and advanced app storage system for Android.

A controversial storage access change, slated for Android 10, becomes mandatory for Android 11. This blog talks about scoped storage, How we can access it and what does it mean for our app?

Before Android 10, storage was divided into private storage and shared storage. Private storage’s(android/data/

) access and contribution was limited to owner app alone. Apart from private storage, rest of the storage was called shared storage which is where all the media and non-media files were being stored. Any app with storage permission would be able to access this part of storage.

What was the problem with earlier storage ?

Limited access: Most of the apps do not need the access of whole storage since their use case are limited to certain types of files or files they own. One such use case can be a grocery app or an e-commerce app which needs storage access only to ask user to upload their profile picture.

Security: With storage access, an app can access a document as vulnerable as your bank statement or personal files. How would you like that?

Data organisation: Data/Files related to an app was scattered at multiple places in Shared Storage. If you have to uninstall the app and you want to clear all the corresponding data, that would not come easy.

This is how it is solved now

With Android 10, Google started to restructure the storage and change the way app accesses the storage so that all the mentioned problems can be eliminated. This storage division is called scoped storage.

Idea behind scoped storage was to divide whole storage into multiple blocks. An app would be provided access to the storage blocks which has relevant data for the app. In addition, system will bind storage to owner apps so that it becomes easier for the system to locate relevant files, corresponding to an app. This would also help to remove app specific data once app is uninstalled unless user does not want to.

This is how storage is divided now:

This storage remains same as before. Its app’s own private directory (/app/data/

) where app has unlimited access to read and write.

This is further divided into Media and Download collection. Media collection stores Image, Audio and Video files. Download collection would take care of non-media files.

What all permissions app need to access the files from scoped storage?

Earlier there was one permission to read all the files and another to write. Now with scoped storage, access is allotted based upon storage type and the ownership of the content.

1. App will have unlimited access to their internal and external storage for both read & write operation.

2. App will have unrestricted access to contribute files ( Media & Non-Media) as long as the file is stored in organised collection.

3. Media collection contributed by other apps can be accessed using ‘READ_STORAGE_PERMISSION’ permission. ‘WRITE_STORAGE_PERMISSION’ permission will be deprecated from next version and if used, will work same as ‘READ_STORAGE_PERMISSION’.

4. Non Media files contributed by other apps can be accessed using Storage access framework API. No explicit permission is needed. This does not mean that App can get access to all the directories ( Root, android/Data , Download directory etc.). Once user grants access to it, it will be complete access. (Read, Modify, Delete).

This is how we can access non-media Files. Here i am trying to access PDF file.

If App wants to select a custom folder, intent ACTION_OPEN_DOCUMENT can be replaced with ACTION_OPEN_DOCUMENT_TREE. ACTION_OPEN_DOCUMENT_TREE is introduced in android 11. This access will be valid till user reboots device. If app wants to persist the access, while accessing URI using content resolver , content resolver has to call takePersistableUriPermission method.

If App wants to create a file such as an email app saving attachment, intent can be replaced with ACTION_CREATE_DOCUMENT.

Access media files from shared storage | Android Developers

To provide a more enriched user experience, many apps allow users to contribute and access media that’s available on an…

Access documents and other files from shared storage

On devices that run Android 4.4 (API level 19) and higher, your app can interact with a documents provider, including…

Note: Media location is considered sensitive data now and would not be available unless app has ACCESS_MEDIA_LOCATION permission. It’s not a run time permission and has to be included in manifest. However it would be good idea to check this if app highly depends upon metadata or is an enterprise application where admin can remove the permission. If you want exact bytes of stored media, ‘MediaStore.setRequireOriginal(photoUri)’ has to be called.

So now apps can get access to specific block of memory. But what if I am a back up app which needs to access everything?

In Android 10, users tried to access the directories using storage access framework. Storage access framework was not intended for this purpose. Also, User complained about confusing UX. For such apps, a special permission is introduced in android 11. To ask the permission, Apps have to submit a declaration form to Google play. Once user grants the permission to have a broad access then user will get an unfiltered view of MediaStore that include non-media file. However, your app will not have access to external app directories.

Unfiltered view of Mediastore…What if my app uses custom file picker which displays exact data directories?

There is nothing you can do about it. You might want to use system picker from now on.

Alright so till this point we understand the reason behind scoped storage and the permission/methods to access it. Now let’s talk about scoped storage API changes over android 10 & 11.

Scoped storage was introduced in Android 10 but there were some controversial decision which enforced google to make API changes in Android 11.

1. In Android 10 and 11, Scoped storage is default behaviour. However app can request legacy external storage in Android 10 which is not the case in 11. Additionally In Android 10, Apps which wanted broader access, tried to use Storage access framework to select the directories which was not the intended purpose of storage framework. In Android 11, special access permission is introduced. Once Google play white list the app, special permission can be asked to the user.

2. In Android 10, UI for scoped storage permission looked same as earlier android version. So it would be hard for user to know if they are giving access to scoped storage or whole storage. With Android 11, permission UI will be updated so that user can clearly differentiate between different permissions he is providing.

3. In Android 11, Media store has been updated. User can do bulk delete/edit of media files which was not the case in Android 10. Additionally, Copying and Editing of files is possible in 11 but recommended only for one-off edits and small sized files since copying files will clutter user’s disk storage.

4. Android 10 has lack of support for native libraries and file path. This is use-case for apps written in c, c++. This support has been added in Android 11, in-fact this is the only use case where developer is expected to write new code. Under the hood file path api is a proxy to media storage api. so if possible, call media store api directly.

What does it mean for you?

if your app has files stored in Shared storage or outside app directory, you need to move them to app directory if you plan to target android 10 and above. Starting with Android 10 you will lose access to it.

Scoped storage is here to solve long time privacy issue. Although there were lots of controversial decisions and negative feedback in Android 10, It is here to stay. Starting September 2020, apps must target android 10 or later so unless you are an app which does not use storage, it’s recommended to start using scoped storage.

Lastly, thank you for reading the article! Any questions and suggestions are most welcome. See you soon.

Microsoft Mobile Engineering

#Mobile development articles and news brought to you by #MobileDevs working at @Microsoft

Источник