android история запуска приложений
Как посмотреть историю приложений на Андроид?
Как на Android посмотреть историю запуска приложений?
Нажмите Данные и персонализация. В разделе «Отслеживание действий» выберите История приложений и веб-поиска.
Как посмотреть историю приложений?
Как найти и посмотреть действия
Можно ли посмотреть историю в телефоне?
в правом верхнем углу экрана.
Как посмотреть статистику приложений на Андроид?
Android. На Android чтобы узнать время, проведённое в любом приложении, откройте Настройки. Здесь перейдите в раздел Приложения и уведомления, затем нажмите Время использования. В этом разделе можно посмотреть статистику по использованию всех приложений за любой период.
Как посмотреть историю действий в одноклассниках?
Пользователи официального мобильного приложения тоже могут быстро посмотреть, кто и когда заходил в их аккаунт. Для этого сначала нужно перейти в настройки, после чего выбрать пункт «История посещений». На следующей странице можно посмотреть местоположение, а также время подключения к аккаунту пользователя.
Как узнать на какие сайты заходил пользователь?
Chrome. Нажать простое сочетание кнопок Ctrl+H — должно автоматически открыться окно с историей (прим.: H — History). Достаточно скопировать адрес: chrome://history/ и вставить его в адресную строку браузера. Просто и легко!
Как посмотреть историю приложений на айфоне?
Для того чтобы просмотреть историю покупок на iPhone или iPad:
Как посмотреть последние приложения?
Как посмотреть историю местоположений?
Чтобы открыть хронологию, выполните следующие действия:
Как посмотреть время посещения сайтов на телефоне?
Чтобы в Chrome на Android посмотреть какие сайты вы посещали за последнее время, перейдите в «Недавние вкладки». Для этого щелкните на иконку меню в правом верхнем углу и выберите одноименный пункт. Там же отображаются страницы, открытые на других мобильных устройствах, синхронизированных с одним аккаунтом Google.
Можно ли посмотреть историю через роутер?
Но, историю посещенных сайтов через ваш роутер не посмотреть. Вам нужно смотреть в сторону каких-то сторонних программ, о работе которых, ваши дети даже не будут знать. Программы будут собирать необходимую статистику, и вы будут знать, какие сайты посещают ваши дети.
Как посмотреть историю?
Как посмотреть историю
Как узнать сколько времени работает телефон?
Перейдите в «Настройки» → «О телефоне» → «Состояние», прокрутите вниз, и вы сможете увидеть время включения.
Где посмотреть статистику приложений?
Статистику для каждого приложения можно посмотреть в мобильной и веб-версии Play Console.
…
Просмотр статистики
Как посмотреть частоту использования приложений?
Чтобы получить более общий общий вид Вашего дня, проведите пальцем по экрану «Today». Это приведет Вас к представлению «Сегодня» в представлении «Ежедневное использование», которое дает быстрый обзор того, какие приложения Вы запускали больше всего и сколько времени Вы потратили в каждом из них.
Android: 12 лет истории дизайна ОС
Android установлен примерно на 2,5 миллиардах активных устройств. С чего он начинался? Давайте проверим и разберёмся. Мы протестируем все версии Android, с 1.0 по 9.0, и посмотрим, как менялась система.
ОС Android имеет довольно долгую историю: о выпуске самого первого Android-телефона HTC Dream объявили в сентябре 2008 года. Найти этот телефон может оказаться сложно, но это нам и не нужно — компания Google создала для разработчиков эмулятор каждой из версий Android. SDK для версии 1.0 можно скачать со страницы https://developer.android.com/sdk/older_releases.html, и это единственная версия, не требующая установки. Достаточно просто запустить файл tools\emulator.exe. При первом запуске мы получаем ошибку:
Создание отсутствующей папки AppData\Local\Android\SDK-1.0 позволило решить проблему, после чего мы смогли запустить эмулятор:
Эмулятор Android 1.0
На главном экране мы видим все основные компоненты, которые существуют и сегодня — значки, список приложений внизу и список уведомлений наверху:
Непривычны два аспекта. Во-первых, на телефоне есть около десяти аппаратных кнопок (в том числе курсорных клавиш). Например, кнопка «Menu» обеспечивает доступ к некоторым функциям:
В целом, все операции можно выполнить, не касаясь экрана, при помощи только аппаратных кнопок.
Во-вторых, всё выглядит большим и контрастным, но не стоит забывать, что размер экрана был маленьким, что-то около 3,2 дюйма. Может показаться удивительным, но устройство не имело экранной клавиатуры — у первого Android-телефона была физическая клавиатура:
Android 1.0 работал на телефоне с 192 МБ ОЗУ, процессором на 528 МГц, аккумулятором на 1150 мАч и экраном с разрешением 320×480.
Давайте проверим компоненты системы.
Вызовы и SMS
Очевидно, что я не мог совершить телефонный звонок или отправить SMS через эмулятор, но, по крайней мере, мы видим UI:
Всё выглядит контрастным, думаю, сегодня подобный UI используется в «телефонах для пожилых».
Контакты
Карты
Google Maps работают на удивление хорошо. Поиск выполняется, режим отображения карты можно менять, и так далее.
Удивительно, что Google Maps API не изменился за более чем 12 лет.
Интернет
Google Maps работают хорошо, но ситуация сильно ухудшается, если протестировать Интернет-браузер. Поиск Google работает:
Но все остальные сервисы недоступны — например www.youtube.com показывает, что требуется версия не ниже Android 4.0.
Я попробовал открыть Medium.com, первая страница «Get started» работала (более-менее), но после нажатия на «Get Started» отобразилась ошибка:
На самом деле, веб-сайт www.google.com оказался единственным, который я смог открыть. Это неудивительно, ведь Android 1.0 был выпущен больше десяти лет назад, а веб-стандарты сильно изменились.
Android 4.0 (2011 год)
Было бы слишком скучно тестировать все версии Android, поэтому давайте перенесёмся на несколько лет вперёд, к Android 4.0. Типичным телефоном того времени был LG Optimum L5 или HTC Desire C: 4-дюймовый экран с разрешением 320×480, процессор на 600 МГц и аккумулятор на 1230 мАч.
Для тестирования этой версии нам понадобится AVD (Android Virtual Device), который является частью Android Studio. Эта версия предназначена для разработчиков, но для запуска эмулятора нам не нужно писать код. Компонент «AVD Manager» позволяет выбирать разные версии и устройства:
Как ни жаль, официального офлайн-установщика для Android Studio больше не существует — во время установки он автоматически скачивает множество файлов. Возможно, это и хорошо для разработки на современных платформах, но, насколько я понимаю, после отключения старых ссылок запустить его снова будет невозможно. По крайней мере, сейчас он работает, и после скачивания всех нужных компонентов Android 4.0 мы можем приступать к работе:
Как мы видим, UI и аппаратная раскладка изменились: больше нет отдельной кнопки «Menu» и клавиш курсора, только три аппаратные кнопки (Home, Back и Apps List), их можно увидеть и в современном Android.
Добавлена новая функция UI — Widgets:
Один из них — это большая панель, которая по умолчанию включена. Она позволяет быстро включать/отключать WiFi, Bluetooth и некоторые другие сервисы.
Settings по сравнению с современными версиями не сильно изменились, однако UI и шрифты, разумеется, другие:
Contacts теперь можно сохранять локально или синхронизировать с аккаунтом Google. Contacts и Dialer (набор номера) теперь стали двумя отдельными приложениями.
Отправка SMS не особо изменилась:
Web Browser работает, но большинство страниц (google play, youtube, даже Wikipedia) не открывается:
Medium.com по-прежнему открыть нельзя, но, по крайней мере, первая страница выглядит лучше, чем на Android 1.0:
Мне удалось открыть страницу MSN (с предупреждениями), страница BBC открылась без ошибок, но UI выглядел странно, а сайт NY Times вообще не открылся:
В картах добавлена новая функция: Google Maps Navigation:
Как ни удивительно, она по-прежнему работает, карты могут находить адреса и прокладывать маршрут.
Android 6.0 (2015 год)
Четыре года — долгий срок для мира технологий, и характеристики смартфонов значительно улучшились. Хорошим примером устройства с Android 6 может служить Samsung Galaxy S6: 5,1 дюймовый AMOLED-экран с разрешением 1440×2560, восьмиядерным процессором и аккумулятором на 2550 мАч:
Внизу мы видим те же три кнопки, экран определённо стал больше, и в целом такой форм-фактор популярен по сей день.
С точки зрения UI, мы видим почти такой же интерфейс, который используется сегодня:
Contacts и Dialer по-прежнему остаются двумя отдельными приложениями (и двумя значками на экране), но разница между ними не так очевидна:
Интерфейс Settings тоже не особо изменился:
Web browser работает гораздо лучше, даже видео воспроизводится корректно, однако medium.com снова не прошёл тест — отображается только белая страница:
На самом деле, www.medium.com — это единственный сайт, который мне не удалось открыть.
Теперь в Android добавлены Gmail и Google Photos:
Google Maps работают хорошо, но, на удивление, спустя пять лет навигация по-прежнему находится в бета-версии.
В целом, интерфейс Android 6.0 выглядит достаточно современно даже по нынешним меркам, а разница между 4.0 и 6.0 гораздо очевиднее, чем между Android 6.0 и 10.
Android 8.0 (2017 год)
Я не собирался тестировать Android 8.0, с точки зрения UI отличий было бы не так много. Но мне стало любопытно, в какой версии Android корректно откроется medium.com. Давайте проверим.
Первое забавное отличие — список приложений снова можно перетаскивать снизу вверх, точно так же, как в Android 1.0 (для сравнения см. изображение в начале статьи):
Как мы видим, как отдельные приложения были добавлены Youtube, Google Drive и Google Play Music.
Давайте снова протестируем браузер на medium.com. В целом, всё стало намного лучше — мне удалось добраться до первого этапа логина:
Но на этом этапе страница зависает, и постоянно появляется всплывающее окно «Sign in».
Android 9.0 (2018 год)
Очевидно, в каждой новой версии Android происходило множество «скрытых» изменений в безопасности, API и фоновых сервисах, но с точки зрения UI эта версия не сильно изменилась по сравнению с Android 6.0 2015 года. Как мы видим, добавилась левая панель Google. Приложения можно разделить на секции «популярные» и «все приложения»:
Напоследок давайте снова проверим страницу medium.com. Вуаля, теперь она работает:
Программирование
Эта статья не задумывалась как туториал по разработке для Android, но если уж мы установили Android Studio, то легко попробовать создать новое приложение для Android.
Для начала нам нужно создать новый проект и выбрать тип приложения.
На следующем этапе нужно указать имя приложения, его уникальный идентификатор, язык программирования (Java или Kotlin) и минимальный уровень версии Android.
После нажатия на «Finish» будут сгенерированы исходный код и ресурсы приложения.
Теперь мы можем запустить своё приложение в эмуляторе или в реальном устройстве:
Очевидно, что это приложение не делает ничего полезного, если вас интересуют последующие шаги, то изучите туториалы на веб-сайте https://developer.android.com.
Заключение
Исследование истории Android оказалось любопытным занятием. Как обычно, я призываю заинтересовавшихся читателей установить эмулятор и самостоятельно увидеть все различия. Один из способов — это Android Studio, но она выполняет образ x86 и не может запускать сторонние приложения для Android. Ещё один удобный эмулятор — это Genymotion, он основан на VirtualBox и обеспечивает полную эмуляцию ARM. Кроме того, он бесплатен для личного пользования. Я пользовался Genymotion несколько лет назад, но последняя версия по неизвестным причинам не работает. Возможно, кому-то из читателей повезёт. Однако существует множество других способов запуска Android на PC, так что можете выбрать подходящий для вас.
В конце я хочу сравнить основные отличия на одном изображении.
Дизайн UI
Совместимость веб-страниц
На правах рекламы
Воплощайте любые идеи и проекты с помощью наших впс» target=»_blank»>серверов с мгновенной активацией на Linux или Windows, на наших впс» target=»_blank»>серверах можно установить даже Android!
Как работает Android, часть 3
В этой статье я расскажу о компонентах, из которых состоят приложения под Android, и об идеях, которые стоят за этой архитектурой.
Web vs desktop
Если задуматься об отличиях современных веб-приложений от «обычных» десктопных приложений, можно — среди недостатков — выделить несколько преимуществ веба:
Кроме того, веб-приложения существуют в виде страниц, которые могут ссылаться друг на друга — как в рамках одного сайта, так и между сайтами. При этом страница на одном сайте не обязана ограничиваться ссылкой только на главную страницу другого, она может ссылаться на конкретную страницу внутри другого сайта (это называется deep linking). Ссылаясь друг на друга, отдельные сайты объединяются в общую сеть, веб.
Несколько копий одной страницы — например, несколько профилей в социальной сети — могут быть одновременно открыты в нескольких вкладках браузера. Интерфейс браузера рассчитан на переключение между одновременными сессиями (вкладками), а не между отдельными сайтами — в рамках одной вкладки вы можете перемещаться по ссылкам (и вперёд-назад по истории) между разными страницами разных сайтов.
Всё это противопоставляется «десктопу», где каждое приложение работает отдельно и часто независимо от других — и в этом плане то, как устроены приложения в Android, гораздо ближе к вебу, чем к «традиционным» приложениям.
Activities & intents
Основной вид компонентов приложений под Android — это activity. Activity — это один «экран» приложения. Activity можно сравнить со страницей в вебе и с окном приложения в традиционном оконном интерфейсе.
Собственно окна в Android тоже есть на более низком уровне — уровне window manager. Каждой activity обычно соответствует своё окно. Чаще всего окна activity развёрнуты на весь доступный экран, но:
Например, в приложении для электронной почты (email client) могут быть такие activity, как Inbox Activity (список входящих писем), Email Activity (чтение одного письма), Compose Activity (написание письма) и Settings Activity (настройки).
Как и страницы одного сайта, activity одного приложения могут запускаться как друг из друга, так и независимо друг от друга (другими приложениями). Если в вебе на другую страницу обращаются по URL (ссылке), то в Android activity запускаются через intent’ы.
Intent — это сообщение, которое указывает системе, что нужно «сделать» (например, открыть данный URL, написать письмо на данный адрес, позвонить на данный номер телефона или сделать фотографию).
Приложение может создать такой intent и передать его системе, а система решает, какая activity (или другой компонент) будет его выполнять (handle). Эта activity запускается системой (в существующем процессе приложения или в новом, если он ещё не запущен), ей передаётся этот intent, и она его выполняет.
Стандартный способ создавать intent’ы — через соответствующий класс в Android Framework. Для работы с activity и intent’ами из командной строки в Android есть команда am — обёртка над стандартным классом Activity Manager:
Intent’ы могут быть явными (explicit) и неявными (implicit). Явный intent указывает идентификатор конкретного компонента, который нужно запустить — чаще всего это используется, чтобы запустить из одной activity другую внутри одного приложения (при этом intent может даже не содержать другой полезной информации).
Неявный intent обязательно должен указывать действие, которое нужно сделать. Каждая activity (и другие компоненты) указывают в манифесте приложения, какие intent’ы они готовы обрабатывать (например, ACTION_VIEW для ссылок с доменом https://example.com ). Система выбирает подходящий компонент среди установленных и запускает его.
Если в системе есть несколько activity, которые готовы обработать intent, пользователю будет предоставлен выбор. Обычно это случается, когда установлено несколько аналогичных приложений, например несколько браузеров или фоторедакторов. Кроме того, приложение может явно попросить систему показать диалог выбора (на самом деле при этом переданный intent оборачивается в новый intent с ACTION_CHOOSER ) — это обычно используется для создания красивого диалога Share:
Кроме того, activity может вернуть результат в вызвавшую её activity. Например, activity в приложении-камере, которая умеет обрабатывать intent «сделать фотографию» ( ACTION_IMAGE_CAPTURE ) возвращает сделанную фотографию в ту activity, которая создала этот intent.
При этом приложению, содержащему исходную activity, не нужно разрешение на доступ к камере.
Таким образом, правильный способ приложению под Android сделать фотографию — это не потребовать разрешения на доступ к камере и использовать Camera API, а создать нужный intent и позволить системному приложению-камере сделать фото. Аналогично, вместо использования разрешения READ_EXTERNAL_STORAGE и прямого доступа к файлам пользователя стоит дать пользователю возможность выбрать файл в системном файловом менеджере (тогда исходному приложению будет разрешён доступ именно к этому файлу).
A unique aspect of the Android system design is that any app can start another app’s component. For example, if you want the user to capture a photo with the device camera, there’s probably another app that does that and your app can use it instead of developing an activity to capture a photo yourself. You don’t need to incorporate or even link to the code from the camera app. Instead, you can simply start the activity in the camera app that captures a photo. When complete, the photo is even returned to your app so you can use it. To the user, it seems as if the camera is actually a part of your app.
При этом «системное» приложение — не обязательно то, которое было предустановлено производителем (или автором сборки Android). Все установленные приложения, которые умеют обрабатывать данный intent, в этом смысле равны между собой. Пользователь может выбрать любое из них в качестве приложения по умолчанию для таких intent’ов, а может выбирать нужное каждый раз. Выбранное приложение становится «системным» в том смысле, что пользователь выбрал, чтобы именно оно выполняло все задачи (то есть intent’ы) такого типа, возникающие в системе.
Само разрешение на доступ к камере нужно только тем приложениям, которые реализуют свой интерфейс камеры — например, собственно приложения-камеры, приложения для видеозвонков или дополненной реальности. Наоборот, обыкновенному мессенджеру доступ к камере «чтобы можно было фото отправлять» не нужен, как не нужен и доступ к совершению звонков приложению крупного банка.
Этой логике подчиняются даже такие «части системы», как, например, домашний экран (лончер, launcher). Лончер — это специальное приложение со своими activity (которые используют специальные флаги вроде excludeFromRecents и launchMode=»singleTask» ).
Приложение может иметь несколько activity, которые поддерживают такой intent, и отображаться в лончере несколько раз (при этом может понадобиться указать им разную taskAffinity ). Или не иметь ни одной и не отображаться в лончере вообще (но по-прежнему отображаться в полном списке установленных приложений в настройках). «Обычные» приложения так делают довольно редко; самый известный пример такого поведения — Google Play Services.
Многие операционные системы делятся на собственно операционную систему и приложения, установленные поверх, ничего друг о друге не знающие и не умеющие взаимодействовать. Система компонентов и intent’ов Android позволяет приложениям, по-прежнему абсолютно ничего друг о друге не зная, составлять для пользователя один интегрированный системный user experience — установленные приложения реализуют части одной большой системы, они составляют из себя систему. И это, с одной стороны, происходит прозрачно для пользователя, с другой — представляет неограниченные возможности для кастомизации.
По-моему, это очень красиво.
Tasks & back stack
Как я уже говорил, в браузере пользователь может переключаться не между сайтами, а между вкладками, история каждой из которых может содержать много страниц разных сайтов. Аналогично, в Android пользователь может переключаться между задачами (tasks), которые отображаются в виде карточек на recents screen. Каждая задача представляет собой back stack — несколько activity, «наложенных» друг на друга.
Когда одна activity запускает другую, новая activity помещается в стек поверх старой. Когда верхняя activity в стеке завершается — например, когда пользователь нажимает системную кнопку «назад» — предыдущая activity в стеке снова отображается на экране.
Каждый стек может включать в себя activity из разных приложений, и несколько копий одной activity могут быть одновременно открыты в рамках разных задач или даже внутри одного стека.
App lifecycle
Одно из основных ограничений встраиваемых и мобильных устройств — небольшое количество оперативной памяти (RAM). Если современные флагманские устройства уже оснащаются несколькими гигабайтами оперативной памяти, то в первом смартфоне на Android, HTC Dream (он же T-Mobile G1), вышедшем в сентябре 2008 года, её было всего 192 мегабайта.
Проблема ограниченной памяти дополнительно осложняется тем, что в мобильных устройствах, в отличие от «обычных» компьютеров, не используются swap-разделы (и swap-файлы) — в том числе и из-за низкой (по сравнению с SSD и HDD) скорости доступа к SD-картам и встроенной флеш-памяти, где они могли бы размещаться. Начиная с версии 4.4 KitKat, Android использует zRAM swap, то есть эффективно сжимает малоиспользуемые участки памяти. Тем не менее, проблема ограниченной памяти остаётся.
Если все процессы представляют собой для системы чёрный ящик, лучшая из возможных стратегия поведения в случае нехватки свободной памяти — принудительно завершать («убивать») какие-то процессы, что и делает Linux Out Of Memory (OOM) Killer. Но Android знает, что происходит в системе, ему известно, какие приложения и какие их компоненты запущены, что позволяет реализовать гораздо более «умную» схему освобождения памяти.
Если пользователь возвращается в activity приложения, завершённого системой из-за нехватки памяти, эта activity запускается снова. При этом перезапуск происходит прозрачно для пользователя, поскольку activity сохраняет своё состояние при завершении ( onSaveInstanceState ) и восстанавливает его при последующем запуске. Реализованные в Android Framework виджеты используют этот механизм, чтобы автоматически сохранить состояние интерфейса (UI) при перезапуске — с точностью до введённого в EditText текста, положения курсора, позиции прокрутки (scroll) и т.д. Разработчик приложения может дополнительно реализовать сохранение и восстановление каких-то ещё данных, специфичных для этого приложения.
Подчеркну, что Android может перезапускать приложения не полностью, а покомпонентно, оставляя неиспользуемые части завершёнными — например, из двух копий одной activity одна может быть перезапущена, а другая остаться завершённой.
С точки зрения пользователя этот механизм похож на использование swap: в обоих случаях при возвращении в выгруженную часть приложения приходится немного подождать, пока она загружается снова — в одном случае, с диска, в другом — пересоздаётся по сохранённому состоянию.
Именно этот механизм автоматического перезапуска и восстановления состояния создаёт у пользователя ощущение, что приложения «запущены всегда», избавляя его от необходимости явно запускать и закрывать приложения и сохранять введённые в них данные.
Services
Приложениям может потребоваться выполнять действия, не связанные напрямую ни с какой activity, в том числе, продолжать делать их в фоне, когда все activity этого приложения завершены. Например, приложение может скачивать из сети большой файл, обрабатывать фотографии, воспроизводить музыку, синхронизировать данные или просто поддерживать TCP-соединение с впс» target=»_blank»>сервером для получения уведомлений.
Такую функциональность нельзя реализовывать, просто запуская отдельный поток — это было бы для системы чёрным ящиком; в том числе, процесс был бы завершён при завершении всех activity, независимо от состояния таких фоновых операций. Вместо этого Android предлагает использовать ещё один вид компонентов — сервис.
Сервис нужен, чтобы сообщить системе, что в процессе приложения выполняются действия, которые не являются частью activity этого приложения. Сам по себе сервис не означает создание отдельного потока или процесса — его точки входа (entry points) запускаются в основном потоке приложения. Обычно реализация сервиса запускает дополнительные потоки и управляет ими самостоятельно.
Сервисы во многом похожи на activity: они тоже запускаются с помощью intent’ов и могут быть завершены системой при нехватке памяти.
Запущенные сервисы могут быть в трёх состояниях:
Background service — сервис, выполняющий фоновое действие, состояние которого не интересует пользователя (чаще всего, синхронизацию). Такие сервисы могут быть завершены при нехватке памяти с гораздо большей вероятностью. В старых версиях Android большое количество одновременно запущенных фоновых сервисов часто становилось причиной «тормозов»; начиная с версии 8.0 Oreo, Android серьёзно ограничивает использование фоновых сервисов, принудительно завершая их через несколько минут после того, как пользователь выходит из приложения.
Bound service — сервис, обрабатывающий входящее Binder-подключение. Такие сервисы предоставляют какую-то функциональность для других приложений или системы (например, WallpaperService и Google Play Services). В этом случае система может автоматически запускать сервис при подключении к нему клиентов и останавливать его при их отключении.
Рекомендуемый способ выполнять фоновые действия — использование JobScheduler, системного механизма планирования фоновой работы. JobScheduler позволяет приложению указать критерии запуска сервиса, такие как:
JobScheduler планирует выполнение (реализованное как вызов через Binder) зарегистрированных в нём сервисов в соответствии с указанными критериями. Поскольку JobScheduler — общесистемный механизм, он учитывает при планировке критерии зарегистрированных сервисов всех установленных приложений. Например, он может запускать сервисы по очереди, а не одновременно, чтобы предотвратить резкую нагрузку на устройство во время использования, и планировать периодическое выполнение нескольких сервисов небольшими группами (batch), чтобы предотвратить постоянное энергозатратное включение-выключение радиооборудования.
Как можно заметить, использование JobScheduler не может заменить собой одного из вариантов использования фоновых сервисов — поддержания TCP-соединения с впс» target=»_blank»>сервером для получения push-уведомлений. Если бы Android предоставлял приложениям такую возможность, устройству пришлось бы держать все приложения, соединяющиеся со своими впс» target=»_blank»>серверами, запущенными всё время, а это, конечно, невозможно.
Решение этой проблемы — специальные push-сервисы, самый известный из которых — Firebase Cloud Messaging от Google (бывший Google Cloud Messaging).
Клиентская часть FCM реализована в приложении Google Play Services. Это приложение, которое специальным образом исключается из обычных ограничений на фоновые сервисы, поддерживает одно соединение с впс» target=»_blank»>серверами Google. Разработчик, желающий отправить своему приложению push-уведомление, пересылает его через впс» target=»_blank»>серверную часть FCM, после чего приложение Play Services, получив сообщение, передаёт его приложению, которому оно предназначено.
Такая схема позволяет, с одной стороны, мгновенно доставлять push-уведомления всем приложениям (не дожидаясь следующего периода синхронизации), с другой стороны, не держать множество приложений одновременно запущенными.
Broadcast receivers & content providers
Кроме activity и сервисов, у приложений под Android есть два других вида компонентов, менее интересных для обсуждения — это broadcast receiver’ы и content provider’ы.
Broadcast receiver — компонент, позволяющий приложению принимать broadcast’ы, специальный вид сообщений от системы или других приложений. Исходно broadcast’ы, как следует из названия, в основном использовались для рассылки широковещательных сообщений всем подписавшимся приложениям — например, система посылает сообщение AIRPLANE_MODE_CHANGED при включении или отключении самолётного режима.
Content provider — компонент, позволяющий приложению предоставлять другим приложениям доступ к данным, которыми оно управляет. Пример данных, доступ к которым можно получить таким образом — список контактов пользователя.
При этом приложение может хранить сами данные каким угодно образом, в том числе на устройстве в виде файлов, в настоящей базе данных (SQLite) или запрашивать их с впс» target=»_blank»>сервера по сети. В этом смысле content provider — это унифицированный интерфейс для доступа к данным, независимо от формы их хранения.
Именно поверх content provider’ов реализован Storage Access Framework, позволяющий приложениям, хранящим файлы в облаке (например, Dropbox и Google Photos) предоставлять доступ к ним остальным приложениям, не занимая место на устройстве полной копией всех хранящихся в облаке файлов.
В следующей статье я расскажу о процессе загрузки Android, о содержимом файловой системы, о том, как хранятся данные пользователя и приложений, и о root-доступе.