Хранение данных и файлов
В целом хранение файлов и данных можно условно разделить на две группы: во внутреннем или внешнем хранилище. Но разница между ними довольна тонка. В целом политика Гугла в отношение данных ужесточается с каждой версии системы.
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» (см. выше).
Источник
.UTSystemConfig — что это за папка на Андроиде и можно ли ее удалить?
Приветствую друзья!
.UTSystemConfig — скрытая папка, которая появляется после заражения вирусами Android.Packed.19213 и Android.DownLoader.2186 (возможно и другими). Однако пользователи также пишут, что появляется после установки некоторых программ, например:
- KingoRoot (получение root-прав).
- Dolphin Browser или UC Browser (браузеры).
- AliExpress (фирменное приложение через которое можно покупать, есть инфа о скидках, акциях).
У некоторых папка появляется после запуска/установки приложений связанных с Taobao. Либо просто китайские приложения, которые часто ведут себя странно.
Внутри также может быть папка Global с файлом Alvin2.xml, содержимое которого такое:
Один юзер написал что файл относится к приложению Cloudscan. Вроде бы xml это конфигурационные файлы.
.UTSystemConfig — инфа от Dr.WEB
Внимание! На офф сайте Dr.WEB найдена информация, что папку .UTSystemConfig создают вирусы Android.Packed.19213 и Android.DownLoader.2186. Информация обнаружена в базе Dr.WEB (пруфы: #1, #2) что автоматом означает, что антивирус Dr.WEB уже в курсе об этой угрозе. Вывод — немедленно сканировать телефон данным антивирусом (Dr.WEB качайте с офф сайта). Также может создаваться .SystemConfig этими вирусами.
Позже выяснил что Android.Packed.18753 также создает папку .UTSystemConfig. Все больше информации о том, что создается именно вирусами.
Вообще читал что эти вирусы нацелены на кражу инфы Facebook и Twitter, скорее всего имеется ввиду логины и пароли..
Даже Adware.Batmobi.6 создает .UTSystemConfig, прям популярна данная папка среди вирусов.
В принципе ситуация странная. Ибо с одной стороны — вирус, а с другой, много нахожу сообщений, что папка .UTSystemConfig появляется после установки той или иной программы. Такое чувство что многие проги заражены вирусом, при этом не все антивирусы находят угрозу (сейчас ситуация возможно уже изменилась).
Можно ли удалить .UTSystemConfig?
Пользователи пишут что удаляли эту папку. Но она потом опять появлялась.
Короче скорее всего удалить ее можно, одно лучше заняться другим делом, а именно — просканировать смартфон на наличие угроз. Скачайте из маркета Google Play годные антивирусы, в первую очередь Доктора Веба и просканируйте им телефон. Это сделать нужно обязательно!
Также на всякий случай можете просканировать телефон Касперским, Авастом.
Заключение
- .UTSystemConfig — создает вирус. Не факт что опасный, типа трояна, думаю что скорее рекламный.
- Удалить можно, но смысл? Нужно искать причину появления.
- Обязательно просканировать телефон на наличие вирусов, в первую очередь антивирусом Доктором Вебом.
Надеюсь информация пригодилась. Удачи, добра, до новых встреч!
Источник
Получаем разрешение MANAGE_EXTERNAL_STORAGE для приложения
Безопасность данных в операционной системе является очень важной задачей, и Android здесь не является исключением. Так, Google в Android 10 добавили новый способ обеспечения безопасности, называемый хранилищем с ограниченной областью видимости (Scoped storage).
До Android 10 всё работало достаточно просто: приложение запрашивало доступ к хранилищу, используя одно из разрешений (WRITE_EXTERNAL_STORAGE либо READ_EXTERNAL_STORAGE), и, после того как пользователь предоставлял разрешение, приложение получало возможность прочесть и изменить практически любой файл, хранящийся на устройстве, за исключением системных файлов и папок, а также папок других приложений. Иначе говоря, приложение просто получало доступ ко всей файловой системе. Scoped storage же изменил этот подход. Теперь приложение по умолчанию имеет доступ только к некоторым участкам памяти, где хранятся общедоступные файлы, такие как медиа, загруженные файлы, некоторые документы. При этом полный доступ приложение имеет только к тем файлам, которые находятся непосредственно в папке приложения, расположенной в Android/data/ . Если приложению нужно изменить или удалить файл, находящийся вне этой папки, то приложение должно запросить у пользователя разрешение на конкретную операцию с помощью MediaStore API (для медиа-файлов) или через Storage Access Framework (для всех остальных файлов). Однако этот способ очень неудобен, если мы разрабатываем файловый менеджер или приложение, которое должно работать не с медиа-файлами.
Scoped storage был добавлен в Android 10 как опциональная функция, которую легко можно было отключить, добавив в AndroidManifest.xml приложения строчку android:requestLegacyExternalStorage=»true» внутри элемента . Таким образом, можно было вернуть работу с файлами так, как было раньше. Однако, начиная с Android 11, использование Scoped storage стало обязательным. Безусловно, это улучшило безопасность и сохранность файлов в операционной системе, но и прибавило проблем разработчикам, заставив их пересмотреть принципы работы своих приложений с файловой системой.
Поскольку часть приложений всё же требует для своей работы полный доступ к хранилищу, а не ограниченный, Google добавили новое разрешение MANAGE_EXTERNAL_STORAGE для таких случаев. Это разрешение, как и раньше, позволяет получить доступ ко всей файловой системе, однако для его использования в приложении требуется подтверждение со стороны Google. В этой статье мы разберём, как использовать разрешение в приложении, а также рассмотрим процесс заполнения заявки в консоли Google Play.
Для начала создадим новый проект с пустой активностью. Для начала нам нужно определить в манифесте, что приложению нужны следующие разрешения для работы. Добавим их в файле AndroidManifest.xml.
Поскольку MANAGE_EXTERNAL_STORAGE используется в обязательном порядке только начиная с API 30, то нам всё ещё нужно обрабатывать запрос разрешений на предыдущих версиях так, как мы это делали раньше. Для этого мы добавляем также WRITE_EXTERNAL_STORAGE, но ограничиваем его использование API 29. Таким образом, мы будем каждый раз проверять уровень API устройства и, в зависимости от этого, использовать либо старое разрешение, либо новое.
Как уже упоминалось выше, в случае с Android 10 для работы с файловой системой нам также нужно в манифесте добавить следующий флаг в элемент .
В файле разметки activity_main.xml добавим несколько элементов для тестирования:
Перейдём к написанию кода. Создадим класс PermissionUtils, в котором будет находиться проверка разрешений и их запрос.
Затем в классе активности MainActivity.java определим элементы из разметки.
Текстовое поле будет отображать, если у приложения необходимые разрешения. Для этого после объявления переменных добавим проверку.
Если запустить приложение сейчас, то у нас всегда будет выводиться сообщение о том, что разрешений нет, поскольку мы их пока что не запрашивали.
Добавим обработчик для кнопки, который будет отправлять запрос на предоставление разрешения.
Нам также необходимо задать код запроса, чтобы мы могли после определить, что ответ пришёл именно для этого запроса.
Когда пользователь нажмёт на кнопку, у него откроется новая активность с настройками приложения, в которой будет предложено дать полный доступ данному приложению. Пользователь может как согласиться, так и отклонить запрос.
Поскольку это также работает и для старых версий Android, то в случае с ними пользователю вместо активности будет предложен старый диалог с запросом на предоставление разрешений.
Любой результат действий пользователя в итоге возвращается в нашу активность. Поскольку для API 30 мы запускаем отдельную активность, то результат работы мы должны отслеживать в методе onActivityResult(). Переопределим его и добавим следующий код.
Здесь мы снова проверяем, дал ли пользователь разрешение или нет, и обновляем текстовое поле в соответствии с результатом.
Аналогичным образом проверяем результат операции для старых уровней API, но здесь уже переопределяем метод onRequestPermissionResult().
Теперь у нашего приложения есть полный доступ к файловой системе, и технически этого уже достаточно. Однако если попытаться опубликовать такое приложение в Google Play, то публикацию запретят по причине отсутствия заявки на получение доступа ко всем файлам. Поэтому, после того, как в консоли будет создан выпуск и загружена туда новая версия приложения, нам нужно перейти в раздел Контент приложения и выбрать там появившийся пункт Важные разрешения и API.
В появившейся форме требуется описать подробно, зачем приложению требуется доступ ко всем файлам, относится ли это к основному функционалу приложения, а также объяснить с технической точки зрения почему невозможно использовать в приложении альтернативные способы.
Также, в случае если показать работу приложения проще, чем объяснить, можно также записать демо-ролик работы приложения, загрузить его на Youtube и прикрепить в данной форме ссылку на видео. В некоторых случаях это может ускорить получение доступа.
Итак, заполнив форму и сохранив её, можно вернуться обратно в настройку выпуска и проверить его. Предупреждение об отсутствии заявки должно пропасть и мы может отправить выпуск на публикацию. В процессе публикации Google тщательно проверит приложении, чтобы убедиться, что доступ ко всем файлам действительно необходим приложению. Как показывает практика, для приложений, представляющих собой файловые менеджеры, заявку одобрят достаточно быстро.
Когда Google одобрил доступ для приложения, новая версия успешно публикуется, а в разделе Контент приложения указано разрешение, которое было одобрено.
Однако, Google также могут и не одобрить заявку, если посчитают, что это не является обязательной функцией или если можно ограничиться MediaStore\Storage Access Framework. Здесь может помочь изменение в работе приложения либо переоформление заявки, это нужно учитывать.
Таким образом, с помощью пары строк кода можно обновить своё приложения для работы с файловой системой на новых версиях Android.
Источник
