Android папка data storage

Память Андроид: очистить кэш и данные приложений

Память мобильных устройств — вопрос, интересующий многих владельцев Android-смартфонов. Объём доступной к использованию свободной памяти, предоставляемый производителями телефонов, за последние годы существенно увеличился, но объём данных, которые хранит пользователь в носимых гаджетах, растёт ещё быстрее.

В данной статье мы поговорим об одном из способов, позволяющих освободить место в памяти Андроид смартфона . Ниже речь пойдёт о том, что такое очистка кэша и что происходит при нажатии на кнопку Очистить данные у приложений в Android OS.

Содержание статьи:

Накопитель заполнен на 75%. Перенести данные на SD-карту

Со временем, когда объём хранимой на смартфоне информации сильно увеличивается, пользователь может столкнуться с проблемой нехватки памяти на телефоне. Уведомление, оповещающее о том, что память заполнена , может выглядеть по-разному. Вот один из примеров:

О чём говорит это предупреждение? В данном случае система предупреждает, что на внутренней памяти устройства осталось меньше 25% свободного пространства. По большому счёту, это не критическая ошибка, доступная память ещё в наличии, но нужно иметь ввиду два момента:

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

В статье Память на Android. Все разделы памяти Андроид устройств мы подробно останавливались на разборе всех типов памяти Android OS. Там же приводилась следующая строчка:

Внутренняя память устройства (Internal phone storage) — та часть модуля памяти смартфона, которая не занята системными разделами и доступна пользователю для размещения приложений, медиа-контента и документов. Часть памяти, на которую устанавливается софт , определяется как раздел Data, а часть, занятая пользовательскими файлами — как User.
Зачастую реальной границы между этими областями нет, и тогда распределение памяти зависит только от нужд владельца устройства.

Если учесть это в рамках текущей публикации, то делаем вывод, что система может оповещать как о нехватке памяти на внутреннем накопителе в целом, так и конкретно о нехватке памяти в разделе Data . Разница в следующем:

• Если на смартфоне требуется освободить место в общем на внутреннем накопителе, то мы можем принести в жертву либо пользовательские данные (музыка, фотографии, видео, документы), либо приложения и файлы связанные с ними.
• Если на смартфоне необходимо освободить выделенный раздел Data , то удаление фотографий или музыки не приведёт ни к какому результату. В этом случае требуется оптимизация именно памяти, занятой программами и играми. Это важно понимать.

Если с удалением медиафайлов и документов всё более или менее понятно, то вопрос оптимизации памяти, занимаемой приложениями, рассмотрим подробнее.

Из чего состоят приложения на Андроид

В первую очередь, стоит указать, что каждое Андроид приложение условно можно разделить на три части по типу используемых файлов:

1. Программа. Это само приложение, apk-файл .
2. Данные приложения. Это пользовательская информация, которая сохраняется в процессе всего периода жизни той или иной программы на смартфоне. Данные вносятся в программу пользователем или по его прямому запросу.
3. Кэш приложения. Это временно хранимые файлы. Грубо говоря, это та же пользовательская информация, с той лишь разницей, что её утрата не влияет на работоспособность приложения. Программа способна заполнить кэш нужными данными самостоятельно в процессе работы.

Теперь определим, где хранится программа, её данные и кэш приложения на Андроид.
Если продолжить отсылку к упомянутой выше статье о памяти на Android и воспользоваться классификацией разделов из неё, то можно смело утверждать, что и сама программа, и данные пользовательских приложений, и их кэш хранятся в Энергонезависимой памяти -> в Перезаписываемом разделе EEPROM -> Internal phone storage (внутренний накопитель) -> Data (то есть, данные).
Мы в данном случае не рассматриваем системные приложения, так как они расположены в Прошиваемом разделе System, и, без наличия root-прав, недоступны для удаления.
То есть, из вышесказанного делаем вывод, что и программа, и её данные с кэшем занимают память в разделе Data , а это значит, что очистка любой из этих составляющих, освобождает пользовательское место и, собственно, частично решает проблему нехватки памяти на Андроид устройстве.
Взглянем на все составные части приложений Android детальнее.

Удаление приложения на Андроид

Сначала отметим, что сама программа в системе Андроид — это не только apk-файл . Кроме него могут быть задействованы дополнительные библиотеки и дополнительные технические* файлы программы.
Под техническими файлами мы понимаем те ресурсы, которые хранятся вне исполнительного файла , но служат для обеспечения выполнения приложением своей работы.
И исполнительный файл программы, и сопутствующие ему файлы чаще всего располагаются в следующем каталоге от корня файловой системы:

В папке app располагается каталог приложения, в корне которого находится сам apk-файл , и папка lib, в которую помещаются системные библиотеки, если таковые имеются. В зависимости от программы, рядом с apk-файлом могут быть и папки с другим названием.

Содержимое папки с программой в каталоге /data/app/ хранится там на протяжении всего времени работы от момента установки до момента деинсталляции приложения.

Очистить данные приложения Андроид

Теперь, что касается данных приложения. Данные — это, в первую очередь, пользовательская информация. В общем случае хранятся данные приложения в следующем каталоге:

В частном случае это может быть немного иной путь, что, в частности, соответствует общему каталогу, отличаясь только отображением иерархии каталогов:

Этой папкой возможные места хранения данных приложения на Андроид не ограничиваются. Часто программа при установке создаёт свой каталог в корне карты памяти: либо внутренней, либо внешней. Именно в этих папках программа сохраняет информацию, которую:

• вводит пользователь;
• скачивает само приложение по запросу юзера.

Кроме вышеперечисленных путей есть ещё один каталог, о котором нужно упомянуть отдельно. Речь пойдёт о папке obb, которая расположена по пути:

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

Игровая индустрия развивается достаточно быстро. Вместе с этим растут и требования к аппаратной части, в том числе и к дисковому пространству. Всё это актуально и для Android OS. Серьёзные игры с красивой прорисовкой графики и серьёзным геймплеем требуют хранения большего объёма системной информации. Всё это привело к тому, что у многих игр появился ярко выраженный кэш. Но, как и в разных способах установки программ, есть несколько путей и в том, как поместить кэш игры в папку /Android/obb/:

1. Если объём кэша не очень велик , то разработчик может заархивировать данные, поместить их непосредственно в apk-файл или просто привязать загрузку кэша к загрузке самой игры. При установке такой игры кэш самостоятельно распакуется в нужную папку. Эту возможность разработчики иногда используют как дополнительную защиту от взлома, так как в случае, если вы скачали игру не из магазина Google Play, а из альтернативного источника, игра при запуске не найдёт кэш и откажется запускаться.
2. Если в apk-файле всех файлов игры не размещено, то, по умолчанию, кэш игры скачивается через интернет автоматически самим приложением при его первом запуске.
   Нужно отметить ещё одну причину, по которой кэш игр не очень удобно упаковывать изначально в apk-файл. Дело в том, что, зачастую, кэш для разных телефонов будет отличаться в зависимости от разрешения экрана, типа видеочипа и процессора, а иногда и от модели смартфона. А если скачивать кэш при первом запуске игры, то не придётся передавать на смартфон пользователя те данные, которые не подходят для его устройства.
3. Всё*, что скачивается конкретным приложением, можно скачать вручную. То есть, кэш игры можно качать не через саму игру, а отдельно . Это возможно в том случае, если кто-нибудь скачает подходящий вам кэш (по разрешению экрана, типу видеоускорителя и так далее) и выложит его в сеть. Тогда нам останется скачать архив с кэшем и поместить его в нужный каталог: obb или data, в зависимости от игры (в частных случаях путь хранения кэша может отличаться и указывается дополнительно).

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

Теперь кому-то может показаться странным, почему информацию о папке с кэшем мы поместили в главу о данных Android, а не о самом кэше. И вот в чём дело. По сути, кэш игры так называют потому, что он скачивается ею при установке. Эти данные являются кэшем только для самого приложения и с точки зрения пользователя. Для операционной системы Андроид файлы кэша игры являются данными приложения и при очистке кэша не затираются (ниже повторим об этом). А когда же затираются?

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

Очистить кэш приложения Андроид

Для начала определим, что такое кэш приложения :

Слово «кэш» позаимствовано от английского слова «cache«, которое, в свою очередь, произошло от французского «cacher«, что значит «скрывать«, «прятать«.
Теперь о том, для чего нужен кэш . В кэше не хранится действительно важная информация, сюда записываются файлы, обращение к которым возможно особенно часто. Сделано это для увеличения скорости доступа. Приведём пример, описывающий работу кэша браузера:

Мы заходим на определённую статью на сайте, которая содержит, допустим, 5 картинок. Для того, чтобы отобразить эти картинки пользователю, браузер скачивает их превьюшки и сохраняет на жёсткий диск или в память телефона. Теперь, когда мы зайдём на эту же статью в следующий раз, браузеру не придётся повторно качать те же изображения, он выдаст их нам из кэша , что позволяет увеличить общую скорость загрузки страницы.

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

Давайте рассмотрим пример, который объясняет смысл понятий программа, данные приложения и кэш приложения простыми словами.

Предположим у нас, как у пользователя , в офисе сидит секретарша офис-менеджер Татьяна. Татьяна — это, в нашем случае, приложение . На рабочем столе Татьяны стоит компьютер, которым офис-менеджер постоянно пользуется — это данные приложения . Кроме компьютера на рабочем столе всегда находятся ручка, блокнот, степлер, дырокол и калькулятор — это кэш нашего приложения .

В какой-то момент времени мы переезжаем в другой офис (прошивка или смена устройства), он больше и просторнее, но в нём пока нет ничего. В первую очередь, приходит офис-менеджер (установка программы). Однако, она пока не может работать, у неё нет данных, поэтому мы устанавливаем ей компьютер (подгрузка данных приложения). Работа закипела. Но пока стол пуст (кэш очищен), скорость работы офис-менеджера ниже прежней: каждый раз, чтобы скрепить документы или посчитать большие суммы, ей приходится отвлекаться на поиски нужных инструментов. Поэтому, постепенно на столе у Татьяны вновь появляется степлер и кулькулятор (заполнение кэша). А вот блокнот, оказывается, нужен не так часто, поэтому он может лежать в выдвижном шкафу, а на освободившееся на столе место мы поместим календарь, обращение к которому происходит чаще. Благодаря этому Татьяна теперь справляется со своими задачами ещё быстрее.

Это грубый пример того, как очистка кэша благотворно влияет на работу приложения .

Кэш приложения также может размещать по разным папкам. Чаще всего это одноимённый каталог cache, который расположен, например, в папке приложения из /Android/data/

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

Соответственно, отвечая на вопрос: «Удалится ли кэш игры при очистке кэша приложения?» — можно сказать, что нет, содержимое папки /Android/obb/ в общих случаях не затрагивается, если иное не предусмотрено разработчиком системы или приложения.

Источник

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

Источник