Recent apps android что это

Папки в Android-смартфоне и что они означают

Константин Иванов

Файловые менеджеры на Android могут быть удобным инструментом для организации хранения данных в вашем смартфоне, но сама структура Android (или ее кажущееся отсутствие) c непривычки может показаться несколько запутанной. Данные приложений, картинки, музыка – и доступ к этому всему из одной корневой папки – это несколько иной подход к иерархической структуре, чем то, к чему привыкли пользователи ПК и Mac, и подход этот дает пользователям намного больше возможностей, чем iOS.

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

Иерархия памяти устройства на Android

Поскольку Android – это операционная система на базе Linux, в вашем телефоне файловая система также организована по принципу Linux. В этой системе на каждом устройстве есть шесть основных разделов: boot, system, recovery, data, cache и misc. Карты памяти microSD также имеют собственную иерархию памяти. Устройства, несущие на борту Android 7.0 Nougat, получили возможность непрерывного обновления за счет того, что в пару к системному разделу создается второй и один из них в фоне обновляется, а при перезагрузке происходит переключение, позволяющее обновленной системе заработать.

Вот краткое описание того, что содержится в каждой папке.

• boot – Эта папка содержит ядро, виртуальный диск и др., то есть то, что требуется для загрузки телефона, когда вы его включаете.
• system – Папка system содержит файлы операционной системы (также известные как образ системы), которые включают в себя также графический интерфейс Android и предустановленные приложения.
• recovery – Альтернативная возможность загрузить ОС, программы из папки recovery позволяют пользователю делать бэкапы других папок и восстанавливать их.
• data – Папка data сохраняет информацию пользователя, от контактов и сообщений до приложений и музыки, и вот к этому разделу вы имеете доступ через файловый браузер. После сброса до заводских настроек этот раздел стирается.
• cache – Android хранит здесь часто используемые данные и компоненты приложений. Этот раздел может быть стерт для устранения определенных проблем и автоматически восстановлен и обновлен со временем.
• misc – Этот раздел содержит другую важную информацию о настройках системы, такую как конфигурация USB, настроек сети вашего оператора и другие аппаратные настройки, которые в графическом интерфейсе отображаются в виде переключателей вкл./выкл.

Без root–прав пользователи Android могут иметь доступ только к разделу с данными, который открывается вам, когда вы подключаете устройство к своему ПК или используете файловый браузер. Если память вашего телефона может быть расширена при помощи карты, память карты также включается в этот раздел с данными, доступными через ПК или просмотрщик файлов.

Обычно у вас есть доступ только данным приложений, которые хранятся в разделе пользовательских данных. Для доступа к остальной памяти вам потребуются root-права

Приложения и папки в разделе данных

Итак, бегло окинув взглядом основные папки, мы отметили, что у нас нет доступа к загрузочным файлам, файлам восстановления и или системным файлам Android, когда мы просто просматриваем файлы при помощи браузера. Из чего следует утешительный вывод: нельзя просто так взять и вызвать своими действиями крах системы. Совсем другая ситуация возникает, когда у вас есть root-права. Так или иначе, с тем, что хранится в данном разделе, надо быть поаккуратнее: определенные приложения могут задействовать данные, которые здесь сохранены, и перемещение или удаление их может повлечь за собой нестабильную работу системы.

Теперь давайте посмотрим, что находится в разделе данных на вашем устройстве. Для того, чтобы это было возможно, в телефонах с Android версий Marshmallow или Nougat есть свой файловый менеджер, который дает доступ ко всему разделу. Эту опцию можно найти в меню Настройки- Память-Накопитель-Другое. Ряд аппаратов на более старых версиях Android могут иметь, а могут не иметь собственный файловый менеджер, зависит от производителя.

В качестве альтернативы есть множество сторонних приложений, доступных в Play Store, которые выполняют ту же самую роль, например, FX File Explorer или Total Commander.

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

Получить доступ к памяти вашего устройства можно при помощи ПК или напрямую через файловый браузер

Если у вас есть ощущение, что память устройства выглядит переполненной и папок слишком много, приглядитесь к ним. Вы увидите многочисленные папки, связанные с приложениями, возможно, даже остатки от тех приложений, что вы уже удалили. Как правило, лучше не трогать никакие папки приложений, но если вы помните, что приложение было удалено, а папка от него осталась, ее удаление вреда не причинит. Скорее всего, она пустая или в ней остались какие-то бесполезные лог-файлы.

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

• Android – это место, куда по умолчанию сохраняются кэш приложений и данные. Эту папку не рекомендуется удалять, если вы не хотите потерять данные приложений. Удаление этой папки может привести к некорректной работе некоторых из них.
• Alarms, Ringtones, Notifications – как видно из названий, в этих папках хранятся аудиофайлы для будильников, рингтонов и уведомлений, которые могут быть использованы как дефолтными, так и сторонними приложениями.
• Cardboard – здесь хранятся данные для ряда приложений VR, а если таковых нет, она остается пустой.
• DCIM – здесь лежат фотографии, которые вы делали при помощи своего основного приложения камеры. Также вы можете увидеть такую папку и на карте microSD, если вы сохраняете фотографии и на нее.
• Downloads – здесь находится все, что скачано вами в веб-браузере, например, в Chrome или Firefox.
• Pictures, Music, Movies, Video – Это папки, которые по умолчанию используются вашими медиаприложениями. Некоторые приложения позволяют вам назначать другие папки, но большая часть медиаплееров по умолчанию будет использовать эти директории. Скриншоты чаще всего сохраняются в папке с картинками.
• Podcasts – Эта папка используется рядом приложений, чтобы отделять подкасты от остальных музыкальных файлов. Если вы не пользуетесь приложениями для прослушивания подкастов, она будет пустой.

Итак, какие папки мне можно (или нужно) удалять?

Не уверен – не удаляй. Это справедливо для всех папок приложений, и трогать их не стоит, за исключением тех случаев, когда вы точно знаете, что хотите сделать. Добавлять и удалять файлы из любых папок с медиа абсолютно безопасно, но постарайтесь в порыве наведения порядка не снести саму папку. Если вы видите, что папка пуста, например, ничего нет в папке Alarms, вы, можете подумать, что она и сама не нужна. Но, с другой стороны, папка не занимает много места. И возможно, она потребуется какому-либо приложению впоследствии, поэтому так ли вам необходимо ее удалять?

Со временем встроенная память вашего устройства будет содержать гораздо больше папок, чем было перечислено выше. Вы будете устанавливать и удалять все большее число приложений. Поэтому наводить порядок в своем устройстве никогда не повредит, ну, разве что вы вообще редко перемещаете файлы в своем телефоне, скачиваете и удаляете их. И еще, удаление пустой папки не освободит вам дополнительного места в памяти. Так что, если требуется выиграть место, лучше посмотрите, какие вы можете удалить ненужные приложения/фильмы, которые не станете пересматривать и т.п.

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

Источник

Наша Service и опасна и трудна или некоторые аспекты выживания служб в Android

Вместо введения

Во многих практических задачах требуется выполнение различных фоновых действий, будь то проигрывание музыки, обмен данными с сервером или просто слежение за действиями пользователя дабы похитить у него реквизиты кредитных карт. Ну а если не получится, то по крайней мере завалить его целевой рекламой, используя полученные сведения. Как уже давным-давно все знают, в Android такие вещи оформляются в виде службы (Service).

Официальная документация гласит, что ОС Android останавливает службу только в случае нехватки памяти. Тем не менее, существует и другие случаи. Пользователь может сам остановить службу, используя предоставляемые ему средства меню Settings/Apps, там же он может сделать и полную остановку приложения. Но для этого ему надо напрягаться и, в общем-то осознавать свои действия и их последствия. К сожалению, для уничтожения службы у него есть и другие возможности, которыми он может пользоваться бессознательно. В частности, если в нашем приложении ранее была запущена хоть одна Activity, видимая в истории, то пользователь буквально одним движением пальца сможет вынести соответствующую задачу. Как ни парадоксально, попутно Android вышибет и весь процесс вместе со службой.

Лично мне такое поведение Android логичным не кажется. Пользователь зачастую просто чистит Recent Apps от давно забытого хлама, совсем не обязательно он при этом желает отказаться от тех благ, которые ему предоставляла выполняющаяся служба. Однако разработчики Google мыслили немного по-другому. По-другому, так по-другому, их право, но в конце концов нам с вами тоже надо как-то жить.

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

Здесь все элементарно. SomeActivity при создании запускает службу KamikadzeService, которая, в свою очередь, стартует, как липкая или sticky. Для агентов враждебных платформ поясню, что служба при старте дает указание операционной системе в случае непредвиденного завершения сервиса перезапустить его при первой возможности. Делает она это, возвращая START_STICKY из метода onStartCommand. Если служба не липкая, то после удаления пользователем задачи шансов на возрождение после смерти у нее не будет.

Метод onTaskRemoved вызывается системой как раз при удалении пользователем задачи. Здесь совершенно необходимо упомянуть об атрибуте службы android:stopWithTask, который можно выставить в манифесте. Как можно догадаться по его названию (либо просто почитав документацию), если android:stopWithTask = ”true”, то волевое движение пальца пользователя по нужному квадратику в Recent Tasks List наряду с удалением задачи будет и останавливать службу. Поскольку в этом случае сервис будет считаться согласным на остановку, то и перезапускать автоматически никто ничего не будет — умерла, так умерла.

В самом начале моей борьбы за относительную устойчивость сервисов, обнаружив наличие этого флага, я имел наивность предположить, что проблема решится установкой android:stopWithTask = ”false” и сервис больше не будет умирать вместе с задачей. Увы, действительность и мечтания имели ряд существенных отличий. Действительно, в этом случае система не будет останавливать службу. Она ее просто прибьет без соответствующего предупреждения. Кстати, по умолчанию этот атрибут равен ”false”, из чего уже можно было догадаться, что явная его установка ни к чему не приведет

Для столь же простодушных разработчиков подытожу: значение атрибута службы android:stopWithTask никак не влияет на ее шансы остаться в живых после удаления задачи пользователем, служба в любом случае обречена. Этот атрибут всего лишь определяет, какой метод сервис будет вызван перед уничтожением. Если он равен ”true”, то у службы будет вызван метод onDestroy (не во всех, мягко говоря, случаях, но об этом чуть позже). А если атрибут равен ”false”, то последним вздохом сервиса, заметным разработчику, будет запуск метода onTaskRemoved.

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

KitKat. No rest for the wicked

Еще в СССР в конце 80-х в рамках цикла передач “Сколько-то там вечеров с Thames Television” показывали рекламу шоколада KitKat. Ни про какой KitKat никто в то время не слыхивал, но реклама была в новинку и просматривали ее с интересом. И я отлично запомнил слоган, который сейчас и воткнул в название раздела. Ибо отражает.

В качестве предисловия. Выше упоминалось, что при android:stopWithTask=”true” сервис именно останавливается, то есть перед смертью получает свой успокоительный onDestroy. Так было до появления Android KitKat, с приходом которого все неуловимо изменилось. При удалении пользователем задачи в этой и более поздних версиях Android служба перейдет в иной мир … бесследно. В подавляющем большинстве случаев. Если конечно, не считать возможный вызов onDestroy у Activity, попавшему пользователю под палец. Очевидно, что все это делает android:stopWithTask совершенно бесполезным для наших целей.

Но выпуск Android KitKat хорошо запомнился разработчикам фоновых служб совсем не поэтому. Дело в том, что в первоначальных вариантах этой версии крылась одна занимательная деталь, которая в свое время лично меня вогнала в состояние глубокой депрессии. KitKat никогда не перезапускал sticky-сервисы.

А дальше были крики душ программистов на stackoverflow, ворох тикетов в Google, исправления, обновления и т.д. Сколько таких прошивок до сих пор живы на устройствах, никто не знает. Но то, что они еще попадаются, это точно. Решение в лоб с попыткой перезапустить службу

не дает ничего, поскольку Android сначала отработает старт, а лишь потом со спокойной совестью уничтожит службу. Здесь придется добавить костыль в виде AlarmManager:

То есть планируем перезапуск службы вручную через три секунды после удаления задачи. Время взято с потолка.

Передний край нащупала разведка

Тот, кто читал эту статью сначала, помнит мое утверждение о неотвратимости смерти background service при удалении задачи. Признаюсь, я здесь немного манипулировал терминами. На самом деле у службы существует способ остаться целой и невредимой, но уже в виде foreground service. Например, так:

При создании служба создает уведомление, в нашем случае это всего лишь иконка приложения. Созданное уведомление передается в метод startForeground и — вуаля — служба становится почти бессмертной. Удаление задачи на нее никак не повлияет, да и при нехватке памяти она будет останавливаться только в самом крайнем случае. Практически единственный способ ее остановить — нажимание соответствующих кнопок в Settings/Apps, что, в общем-то и требовалось. Так зачем же я городил огород до этого? А дело в этом самом уведомлении, которое Google с давних пор требует для перевода службы на передний план. Оно заметно для пользователя, заметно даже если его создать с прозрачной иконкой. А для ряда приложений это не всегда хорошо. Я сейчас говорю не о троянах и прочих вредоносных программах, их создатели вряд ли озабочены описываемой проблемой вообще, поскольку по определению не должны показывать пользователю что-то, за что он может потянуть. Просто показ уведомлений, не обусловленных реальной необходимостью, выглядит, на мой взгляд, глуповато. Пользователь это также чувствует и зачастую это его даже раздражает, как видно из комментариев к некоторым приложениям в Google Play.

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

А onCreate в KamikadzeService перепишем так:

Суть подхода в том, что служба HideNotificationService, выйдя не передний план с тем же идентификатором 777, уходит опять на задний с удалением своего уведомления. Заодно уничтожается и уведомление KamikadzeService, но последняя остается на переднем плане, причем уже «на первый взгляд, как будто, не видна». После этого служба HideNotificationService прекращает работу. Следует уточнить, что порядок запуска служб, как и их выхода на передний план здесь не имеет значения, главное обеспечить, чтобы stopForeground второй (HideNotificationService) был вызван позже, чем startForeground первой (KamikadzeService). И обязательно равенство идентификаторов, передаваемых в startForeground.

И здесь опять возникает резонный вопрос — если все это прекрасно работает, зачем я ранее долго и нудно разжевывал про повадки ”чисто” фоновых служб? Да потому что описанный прием — хак и хак достаточно грязный, чтобы им еще долго можно было пользоваться. Хотя в эмуляторе с прилетевшим на днях Android 6.0 это пока работает. Надеяться или не надеяться — решать читателю.

Источник