Основы безопасности операционной системы Android. Native user space, ч.1

Основы™ безопасности операционной системы Android. Native™ user space, ч.2

Вступление

Сегодня я продолжу рассматривать безопасность на уровне™ немного выше ядра. Во второй™ части мы рассмотрим, откуда™ появляются system™.img, userdata.img и cache.img, а также как обеспечивается безопасность в Native™ user space.
Всем кому интересно, добро пожаловать!

Список™ статей™

Что подразумевается под Native™ user space

Под Native™ user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik™ Virtual Machine, и которые не являются частью™ Linux kernel™. Native™ user space — это исполняемые файлы, скомпилированные под определенную архитектуру. К ним относятся исполняемые файлы, которые запускаются из init скрипта автоматически или в случае™ наступления какого™-либо события, toolbox утилиты, а также некоторые исполняемые файлы, которые пользователь может запустить из-под shell.

Начало™

Как я уже рассказывал в первой™ части, в основе™ Android лежит Linux kernel™. Как и во всех Linux системах, в основе™ безопасности Android лежит access™ control. Т.е. каждый™ ресурс™ (например, файл) содержит мета-информацию о том, кто создал™ этот файл — owner (владелец) — и к какой основной группе™ (owner group) принадлежит owner (владелец). Каждый™ процесс запускается от имени какого™-то user (пользователя). У каждого пользователя есть основная группа™. Кроме того он может являться членом™ других™ групп. Таким образом, если к каждому ресурсу прикрепить информацию (в формате rwxrwxrwx) о том, кто может читать™/писать™/исполнять ресурс™ (например, файл), то можно контролировать доступ™ к этому файлу. Например, файлу можно назначить разрешения: что может делать™ с этим файлом™ owner (владелец) этого файла; что могут делать™ пользователи, которые входят™ в состав™ owner group; что могут творить все остальные. Здесь об этом можно почитать подробнее.

Но у Android есть некоторые отличия. Во-первых™, изначально Android — это операционная система для телефонов, которые, как известно, относятся к очень личным™ вещам и которые мы не любим давать™ в чужие руки. То есть она была задумана как операционная система, у которой только™ один пользователь. Поэтому было принято решение использовать различных Linux users для обеспечения безопасности (для каждого приложения — отдельный пользователь, как я уже рассказывал в первой™ статье™). Во-вторых™, в Android некоторые user (пользователи) и их UID (идентификаторы) были жестко™ запрограммированы в систему, что вызывает очень много нареканий людей связанных с безопасностью (хотя я, если честно™, не очень понимаю, почему™ критикуется такой подход™). Мы уже видели™ этих пользователей в файле system™/core/include/private/android_filesystem_config™.h Например, root имеет идентификатор , а system™ — 1000.

Как я уже отмечал, процесс запускается от имени того же пользователя (UID), что и процесс, который запускает этот новый процесс, т.е. UID(calling_process) == UID (called™_process). Первый™ процесс, который запускается в Android — init — запускается от имени root (UID == 0). Таким образом, по-идее, все процессы также должны™ быть запущены от имени того же пользователи. Так оно, наверное, бы и было. Но, во-первых™, процессы, запущенные от имени привилегированного пользователя (а так же те, кто обладает определенными capabilities), могут изменять свой UID на менее привилегированный. А во-вторых™, в Android при запуске демонов в init.rc скрипте так же можно указать, с привилегиями какого™ пользователя и каких групп запускать данный™ процесс.

Все процессы, которые будут запущены через этих демонов, уже не будут иметь root привилегии.

System™, data и cache

Я столько раз анонсировал эту тему, что можно было подумать, что она очень сложная и запутанная. На самом деле, это не так. System™.img, userdata.img и cache.img — то, что получается в результате компиляции операционной системы Android. То есть в результате сборки™ системы получаются эти три файла, которые мы и записываем на наше устройство.

Но самое важно здесь не это. Благодаря тому, что в Android системе user name и UID системных пользователей жестко™ запрограммированы, уже на этапе компиляции мы можем определить права доступа различных системных пользователей к различным директориям в данных™ образах. Эти права доступа указаны в файле system™/core/include/private/android_filesystem_config™.h, который мы уже рассматривали в первой™ статье™. Права доступа определяются отдельно для директорий (android_dirs[]) и отдельно для файлов™ (android_files[]) следующим образом:

А функция static™ inline™ void fs_config™(const char *path, int dir, unsigned *uid, unsigned *gid, unsigned *mode, uint64_t *capabilities), которая определена дальше™ в этом файле отвечает за выставление owner, owner group, capabilities и прав доступа. Эта функция вызывается во время сборки™ образа™.

В общем здесь всё должно™ быть более-менее понятно, за исключением установки флагов™ прав доступа (setuid™ и setgid™) для некоторых файлов™ (например, для «system™/xbin/su» права доступа определены как 06755, где первая™ 6 означает, что выставлен флаг установки ID пользователя (4) и флаг установки ID группы™ (2)). Установка этих флагов™ означает, что пользователь может повысить права запускаемого процесса до уровня™ owner (владельца) файла или owner group (группы™ владельца). В случае™ Android, каждое™ приложение — это пользователь со своими™ UID и GID. Таким образом, по умолчанию если вы из своего™ приложения запускаете какой-нибудь™ native™ executable, он исполняется с теми же UID и GID, как и приложение его вызвавшее. Установка данных™ флагов™ прав доступа позволяет выполнить native™ executable с правами владельца. В нашем случае™, владелец — AID_ROOT (root). Происходит это следующим обрзазом system™/extras™/su/su.c:

Т.е. вызываются функции setuid™ и setgid™. В этом случае™, если данные™ функции выполнились успешно, то процесс начинает работать от имени owner и owner group данного файла. В нашем примере, данный™ процесс получает права суперпользователя, т.е. он может делать™ всё, что ему пожелается 🙂 Подобная анархия не всегда™ оправдана, поэтому в Linux ввели понятие capabilities. Так приложению «run-as» не нужны всё права суперпользователя, ему достаточно иметь возможность только™ менять™ свой идентификатор, чтобы запускать приложения от имени различных пользователей. Кстати™, capabilities похоже™ появились недавно — в Android 2.3.x я их не встречал.

Безопасность

В случае™ привилегированных программ (типа, su) необходимо ограничивать круг приложений, которые могут вызывать эти программы. В противном случае™ любое приложение может получить права суперпользователя. Поэтому очень часто в такие программы встраивают проверку по UID:

Т.е. программа вначале проверяет, от чьего имени запущен вызывающий процесс, используя функцию getuid™(). А потом сравнивает эти значения со значениями, которые жестко™ запрограммированы в систему. В данном™ случае™, только™ процессы запущенные от имени пользователей «system™» и «root» имеют право использовать su.

Заключение

В данной™ статье™ мы закончили разбирать, как обеспечивается безопасность на уровне™ Native™ user space. В следующих статьях я планирую разобрать, как работают permission (разрешения), но в связи с большой текущей загрузкой не знаю, когда приступлю к их написанию. Как всегда™, буду очень рад дополнениям и исправлениям.

Основы™ безопасности операционной системы Android. Native™ user space, ч.2

Вступление

Список™ статей™

Что подразумевается под Native™ user space

Начало™

Все процессы, которые будут запущены через этих демонов, уже не будут иметь root привилегии.

System™, data и cache

Читать еще: Мобильный банк Росбанк: как подключается и какие плюсы и минусы имеет?

Безопасность

Заключение

Парсер Хабра

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

понедельник, 2 июня 2014 г.

Основы безопасности операционной системы Android. Безопасность на уровне Application Framework. Binder IPC

Вступление

После небольшого перерыва я продолжаю объяснять базовые принципы как обеспечивается безопасность в операционной системе Android. Сегодня я начну описывать безопасность на уровне Application Framework. Но чтобы понять данную тему, вначале необходимо рассмотреть как в Android реализован механизм межпроцессного взаимодействия (Inter-Process Communication (IPC)). Этот механизм называется Binder IPC, и сегодня мы будем рассматривать его особенности. Все, кому интересно, добро пожаловать!

Список статей

Ниже приведены ссылки на мои статьи из этой серии:

Зачем нужен Binder IPC?

Как я уже писал в первой статье цикла, каждое приложение в Android выполняется в своей собственной «песочнице» (Application Sandbox). Механизм «песочницы» в Android основан на присвоении каждому приложению уникального user ID (UID) и group ID (GID), таким образом каждому приложению (application или app) в этой операционной системе соответсвует свой уникальный непривилегированный пользователь. Мы рассматривали эту тему в первой статье цикла. В тоже время владельцами всех критических ресурсов системы являются более привилегированные пользователи, имена и идентификаторы которых жестко зашиты в систему (см. system/core/include/private/android_filesystem_config.h ). Системные сервисы, которые запускаются от имени этих пользователей, имеют доступ к соответствующим критическим ресурсам системы (например, к GPS данным), в то время как процессы обычных приложений доступ к этим ресурсам получить не могут.

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

В Android обмен сигналами и данными между процессами организован с помощью фреймворка межпроцессного взаимодействия (Inter-Process Communication) Binder. Стандартный System V IPC фреймворк не поддерживается данной операционной системой, в частности, в Bionic libc отсутствуют заголовочные файлы , , , . В некоторых специфических случаях (например, для взаимодействия с демоном Zygote) используются Unix domain sockets. Все остальные способы взаимодействия между процессами, включая Intents, реализованы используя Binder IPC. Этот фреймворк позволяет синхронно и асинхронно вызывать методы удаленных объектов так, будто они локальные, обмениваться файловыми дескрипторами между процессами, link to death (автоматическое оповещение в случае если Binder определенного процесса был прерван), и т.д.

Как работает Binder IPC?

Взаимодействие между процессами организовано по синхронной клиент-серверной модели. Клиент инициирует соединение и ждет ответа со стороны сервера. Таким образом, взаимодействие между клиентом и сервером происходит последовательно. Такой дизайн позволяет разработчику вызывать удаленные методы словно они находятся в том же самом процессе. Стоит отметить, что это не рассходится с тем, что я писал выше по поводу асинхронного вызова методов: в случае асинхронного вызова, сервер сразу же возвращает пустой ответ клиенту. Схема взаимодействия процессов через Binder представлена на следующем рисунке: приложение (клиент), которое выполняется в процессе Process A, получает доступ к функцианальности, реализованной в сервисе, который выполняется в процессе Process B.

Все взаимодействия между клиентом и сервером в рамках Binder происходят через специальный Linux device driver (драйвер устройства) /dev/binder. В статье «Основы безопасности операционной системы Android. Native user space, ч.1» мы рассматривали процесс загрузки системы. Один из первых демонов, запускаемых процессом init, является ueventd — менеджер внешних устройств в Android. Этот сервис во время старта читает конфигурационный файл ueventd.rc и проигрывает события добавления внешних устройств. Эти события выставляют для устройств разрешения (permissions), а также владельца (owner) и группу (owning group). В следующем примере можно увидеть какие разрешения выставлены для /dev/binder.

Как можно заметить, разрешения для этого устройства выставлены в 0666. Это означает, что любой пользователь системы (а мы помним, что разные приложения в Android — это уникальные пользователи) имеет право писать в и читать из данного устройства. Для взаимодействия с этим драйвером была создана библиотека libbinder. Эта библиотека позволяет сделать процесс взаимодействия с драйвером прозрачным для разработчика приложений. В частности, взаимодействие между клиентом и сервером происходит через proxy (прокси) на стороне клиента и stub на стороне сервера (см. рисунок выше). Proxies и Stubs отвечают за маршалинг данных и комманд передаваемых через драйвер. Т.е. Proxy выстраивает (marshalling) данные и команды, полученные со стороны клиента таким образом, что они могут быть корректно прочитаны (unmarshalling) и однозначно поняты Stub’ом. Вообще, разработчики приложений даже не пишут Stub’ы и Proxy’и для своих приложений. Вместо этого они используют интерфейс, описанный с помощью языка AIDL. Во время компиляции приложения, на основании этого интерфейса генерируется код для Stub’ов и Proxy’и (можете поискать в своих проектах, чтобы увидеть как они выглядят).

На стороне сервера для каждого клиентского запроса создается отдельный Binder поток (см. рисунок выше). Обычно эти потоки называются как Binder Thread #n. Кстати, если мне не изменяет память, то максимальное количество Binder потоков равно 255, а максимальный размер данных, которые могут быть переданы через Binder в рамках одной транзакции составляет 1Mb. Это следует иметь ввиду, когда разрабатываете приложения, передающие или получающие данные от других процессов.

Service Manager

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

Для этого клиент обращается к Binder context manager, который в случае Android называется Service Manager (servicemanager). Service Manager — специальный сервис, Binder токен которого известен всем заранее. Не удивительно, что значение токена для этого сервиса равно 0. Binder драйвер разрешает регистрацию только одного сервиса с таким токеном, поэтому servicemanager — один из первых сервисов, запускаемых в системе. Service Manager можно представить в виде справочника. Вы говорите, что хотите найти сервис с таким-то именем, а вам в ответ возвращают его уникальный токен-номер, который вы можете использовать после для взаимодействия с искомым сервисом. Естественно, сервис сперва должен зарегистрироваться в этом «справочнике».

Безопасность

Сам по себе Binder фреймворк не отвечает за безопасность в системе, но он предоставляет механизмы для её обеспечения. Во-первых, Binder драйвер в каждую транзакцию записывает PID и UID процесса, который инициирует транзакцию. Вызываемый сервис может использовать эту информацию чтобы решить, стоит ли выполнять запрос или нет. Вы можете получить эту информацию используя методы android.os.Binder.getCallingUid(), android.os.Binder.getCallingPid(). Во-вторых, так как Binder токен уникален в рамках системы и его значение не известно априори, то он сам может использоваться как маркер безопасности (смотрите, например, вот эту статью).

Заключение

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

Путеводитель по системным утилитам для ОС Android, часть 1

В данном путеводителе мы рассмотрим утилиты для Android, которые выполняют функции диагностики и оптимизации системы и позволяют лучше понять, как используются доступные ресурсы.

Можно с понятным скепсисом относиться ко всякого рода оптимизаторам, знакомым еще со времен «твикеров» для настольных ОС. Однако неоспоримо, что подобные приложения всегда должны быть под рукой, поскольку доступный инструментарий ОС Android не позволяет в полной мере, комплексно получить информацию о процессах, выполнить ряд пакетных операций и т. д.

Основные участники обзора:

Assistant for Android
System Info for Android
Elixir 2

Также будут упомянуты:

DU Battery Saver (Power Doctor)
DiskUsage
Clean Master
ES Task Manager (Task Killer)
Advanced Task Manager — Boost

Assistant for Android

Assistant for Android — подборка инструментов для оптимизации Android. Инструментарий этот включает в себя 18 основных функций оптимизации системы. Среди них — мониторинг, управление процессами и задачами, очистка от ненужных файлов, менеджер автозагрузки, диспетчер приложений и другие компоненты.

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

В разделе «Мониторинг» пользователь может выгрузить приложения из RAM (диспетчер задач) или очистить систему от ненужных данных — кэш временных файлов системы и установленных приложений, файлов журнала, пустых файлов / папок и прочего «мусора», удаление которого безвредно сказывается на системе. Кроме того, Assistant предоставляет список временных файлов на карте памяти, выборки пользовательских файлов по размеру, типу информации и т. п.

Следующий раздел приложения — управление процессами. Здесь можно получить сведения о типах процессов (отмечены соответствующей маркировкой), занимаемой ими памяти и нагрузке на CPU, отследить поведение определенных процессов — в том случае, если есть вопросы проблемы с производительностью системы. В соответствии с чем ненужные процессы можно выгрузить из памяти.

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

Резюме. Assistant for Android — вполне себе традиционный оптимизатор для Android с комплексным набором функций. Он не вносит ничего принципиально нового и является лишь удобной оболочкой для тюнинга системы. Из основных достоинств — несложный интерфейс и отсутствие бесполезных маркетинговых дополнений, пакетные операции с приложениями.

System Info for Android

Приложение System Info for Android предоставляет различного рода служебную информацию по работе ОС Android, которая может быть полезна для последующей оптимизации системы. Рассмотрим основные функции этой программы.

На системной панели доступна сводная информация по занятому пространству на картах и памяти, ОЗУ, время работы и сетевая информация (IP-адрес, тип подключения к сети и пр.). При этом весьма странно, что нет никаких данных по процессору и его загруженности.

Во вкладке System вся информация представлена в текстовом виде. Она никак не применима к оптимизации и, вместе с тем, дает исчерпывающую информацию по системе Android, аппаратной составляющей в целом: ОС, конфигурация, память, батарея и прочие аспекты, влияющие на производительность.

Читать еще: Как сделать вай фай сеть невидимой и подключиться к ней

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

В разделе Apps собраны все установленные и системные приложения. Здесь можно управлять каждой программой индивидуально, но пакетные операции (например, установка и удаление) отсутствуют как таковые.

Наконец, раздел Logs может быть полезен не только пользователям, но и разработчикам, которые тестируют приложение и хотят извлечь отладочную информацию. Журналы обновляются в реальном времени, можно сохранить историю в файл.

В качестве опции, на домашний экран можно добавить виджет. Возможности его более чем скромны: он выводит информацию о заряде батареи, свободной памяти RAM и занятом пространстве на SD-карте.

Резюме. Таким образом, приложение System Info for Android будет полезно рядовым пользователям ОС, отчасти — разработчикам. Это, скорее, инструмент с информационным уклоном, который позволяет в реальном времени отследить процессы, события в журнале. Полезных опций оптимизацией, связанных именно с настройкой, здесь считанное количество.

Elixir 2

Elixir 2 — утилита для получения системной информации, диагностики устройства и добавления соответствующих виджетов на домашний экран.

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

Также следует отметить дополнительные функции, доступные через контекстное меню. Elixir 2 предлагает функции, связанные с каждым выбранным компонентом. Скажем, выбрав в меню процессор, можно посмотреть данные о его модели, использовании батареи, изменить регулятор ЦП. Для карты памяти доступно монтирование, управление приложениями. Таким образом, Elixir предлагает достаточно удобную и логичную компоновку связанных системных функций.

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

Одна из наиболее интересных функциональных особенностей Elixir — раздел «Датчики». Соответственно, здесь можно ознакомиться с системными данными и потреблением доступных датчиков устройства на Android. Кроме этого, можно вручную запустить тесты для проверки их минимальной и пиковой мощности.

В «Журналах» выводится содержание файлов logcat и dmesg, и можно отфильтровать сообщения (ошибки / предупреждения / информация). Сгенерированные отчеты Elixir с системной информацией несложно отправить по e-mail.

Напоследок, следует отметить многообразие виджетов. Для их активации и настройки нужно установить дополнение. Это и другие дополнения (личные, системные, администраторские и др.) устанавливаются опционально, через Google Play.

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

DU Battery Saver (Power Doctor)

DU Battery Saver — приложение для базовой оптимизации системы и экономии заряда батареи. Каких-либо тонких настроек здесь нет, оно очень простое и вряд ли будет интересно опытным пользователям.

На главной странице («Батарея») доступна информация о текущем состоянии батареи. Если устройство заряжается, можно узнать время, необходимое для полной зарядки. Кроме того, отсюда можно извлечь некоторые технические характеристики: температуру, напряжение и емкость батареи. На графике, в нижней части экрана, пользователь может отследить, как расходовался заряд батареи на протяжении дня, по уровню АКБ. Из этой шкалы все понятно, однако особого практического смысла в ней меньше, чем хотелось бы получить.

В разделе «Сохранение» — управление режимами потребления. Профили имеют описания, так что можно понять, за счет чего планируется оптимизировать телефон: звонки, смс, интернет и прочее. Можно создать собственный профиль из десятка параметров. Пользователям платной версии Battery Saver доступен т. н. «интеллектуальный» режим: отключение уведомлений, управление приложениями, автовыгрузка, изменение профилей энергопотребления на протяжении суток.

Во вкладке «Монитор» отслеживается потребление энергии приложениями и оборудованием. Здесь достаточно отчетливо видно, что больше всего разряжает батарею, «виновника» можно отключить.

Есть у приложения Battery Saver и другие функции, но они менее интересны, плюс, как и другие приложения этого разработчика, некоторые функции — сугубо рекламные.

DiskUsage

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

Данные отображаются на диаграмме в виде цветных блоков, пропорционально занимаемому им пространству. Нажав на определенный блок, можно ознакомиться с файлами внутри этой директории. Таким образом, становится понятно, где искать «похитителей» дискового пространства.

Из дополнительных особенностей приложения — DiskUsage интегрируется с популярными файловыми менеджерами, такими как OI FileManager и Astro.

Clean Master

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

Итак, «Мусор»: в этом разделе можно очистить кэш и различные временные файлы, которые оставляют за собой приложения. Кроме того, интересен расширенный режим очистки — он позволяет выявить дубликаты и файлы, которые занимают больше всего пространства на диске.

Раздел «Ускорение» позволяет освободить память телефона, выгрузив приложения в фоне. В «Ускорении» также можно перейти к разделу автозагрузки, где отображается соответствующий список приложений, активных и отключенных из автозапуска.

Еще один полезный модуль Clean Master — менеджер приложений. Здесь представлены приложения в виде выборок: последние установленные, редко используемые, по размеру, категориям и прочее. Можно отметить несколько элементов и удалить их в пакетном режиме, что очень удобно. Помимо этого, есть возможность создания резервной копии и удаления apk-установщиков приложений.

Clean Master радует информативностью по части оптимизации и позволяет быть осведомленным: информация о занятых/освобожденных мегабайтах постоянно отображается в верхней части приложения. Правда, визуальные красоты, анимация несколько замедляют приложение, и, как ни парадоксально, скорость системы временно ухудшается именно из-за Clean Master. Кроме того, программа изобилует дополнительными модулями (антивирус, CM Family и др.), которые интересны далеко не всем пользователям.

В целом, твикер Clean Master производит странное впечатление. Хотя в нем содержится ряд полезных функций, интерфейс тяжеловат. А при нехватке ресурсов, логично, не хотелось бы лишний раз перегружать Android.

ES Task Manager (Task Killer)

Приложение от разработчиков популярного файлового менеджера ES Explorer. Если вдаваться в описание, перед нами — более универсальное приложение, чем простой менеджер задач. ES Task Manager позволяет сэкономить заряд батареи, очистить память устройства, выгрузить, заблокировать или деинсталлировать ненужные приложения.

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

Вторая секция менеджера — собственно «Диспетчер задач». Сверху отображается объем доступной памяти и состояние батареи, далее следует список запущенных приложений. Через контекстное меню можно занести приложение в исключения или добавить в список для автозавершения.

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

Некоторые модули, такие как «Анализатор SD-карты» и «Приложения», доступны только после установки файлового менеджера ES Explorer.

Advanced Task Manager – Boost

Advanced Task Manager — вполне предсказуемый по функциональности менеджер задач, но чуть более удобный, чем стандартный.

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

Ряд полезных опций обнаруживается в настройках Advanced Task Manager. В первую очередь, это автовыгрузка приложений по выбору: сразу после отключения экрана, при запуске приложения, с заданным интервалом.

Из недостатков данного менеджера — нет сортировки и детальной информации по загруженности процессора для каждого приложения. Также, управление сервисами реализовано через системный интерфейс, что неудобно.

Основы™ безопасности операционной системы Android. Native™ user space, ч.2

Вступление

Список™ статей™

Что подразумевается под Native™ user space

Начало™

Все процессы, которые будут запущены через этих демонов, уже не будут иметь root привилегии.

System™, data и cache

Читать еще: Каким образом подключить наушники Xiaomi Mi sports bluetooth headset к смартфону?

Безопасность

Заключение

ПРОграммирование под Android

Страницы

21 февраля 2014 г.

Архитектура операционной системы Андроид

Классический рисунок представляющий архитектуру ОС Android:

Если кому-то сложно с английским, то на всякий случай то же самое по на русском:

Сразу приведу оригинальное видео с канала Android Developers на Youtube, где все авторитетно рассказывается и показывается, правда на враждебном нам буржуйском языке. Я использовал это видео, чтобы описать некоторые пункты архитектуры, описания которых не нашел в сети на русском языке.

Если представить компонентную модель Android в виде некоторой иерархии, то в самом низу, как самая фундаментальная и базовая составляющая, будет располагаться ядро операционной системы (Linux Kernel).
Часто компонентную модель ещё называют программным стеком. Действительно, это определение тут уместно, потому что речь идет о наборе программных продуктов, которые работают вместе для получения итогового результата. Действия в этой модели выполняются последовательно, и уровни иерархии также последовательно взаимодействуют между собой.

LINUX KERNEL (ЯДРО ЛИНУКС)
Как известно, Андроид основан на несколько урезанном ядре ОС Linux и поэтому на этом уровне мы можем видеть именно его (версии 2.6.x). Оно обеспечивает функционирование системы и отвечает за безопасность, управление памятью, энергосистемой и процессами, а также предоставляет сетевой стек и модель драйверов. Ядро также действует как уровень абстракции между аппаратным обеспечением и программным стеком.

LIBRARIES (БИБЛИОТЕКИ)
«Выше» ядра, как программное обеспечение промежуточного слоя, лежит набор библиотек (Libraries), предназначенный для обеспечения важнейшего базового функционала для приложений. То есть именно этот уровень отвечает за предоставление реализованных алгоритмов для вышележащих уровней, поддержку файловых форматов, осуществление кодирования и декодирования информации (в пример можно привести мультимедийные кодеки), отрисовку графики и многое другое. Библиотеки реализованы на C/C++ и скомпилированы под конкретное аппаратное обеспечение устройства, вместе с которым они и поставляются производителем в предустановленном виде.
Краткое описание некоторых из них:

Surface Manager – в ОС Android используется композитный менеджер окон, наподобие Compiz (Linux), но более упрощенный. Вместо того чтобы производить отрисовку графики напрямую в буфер дисплея, система посылает поступающие команды отрисовки в закадровый буфер, где они накапливаются вместе с другими, составляя некую композицию, а потом выводятся пользователю на экран. Это позволяет системе создавать интересные бесшовные эффекты, прозрачность окон и плавные переходы.
Media Framework – библиотеки, реализованные на базе PacketVideo OpenCORE. С их помощью система может осуществлять запись и воспроизведение аудио и видео контента, а также вывод статических изображений. Поддерживаются многие популярные форматы, включая MPEG4, H.264, MP3, AAC, AMR, JPG и PNG.
SQLite – легковесная и производительная реляционная СУБД, используемая в Android в качестве основного движка для работы с базами данных, используемыми приложениями для хранения информации.
OpenGL | ES –

3D библиотеки — используются для высокооптимизированной отрисовки 3D-графики, при возможности используют аппаратное ускорение. Их реализации строятся на основе API OpenGL ES 1.0.

На этом же уровне располагается Android Runtime – среда выполнения. Ключевыми её составляющими являются набор библиотек ядра и виртуальная машина Dalvik. Библиотеки обеспечивают большую часть низкоуровневой функциональности, доступной библиотекам ядра языка Java.

ANDROID RUNTIME (СРЕДА ВЫПОЛНЕНИЯ АНДРОИД)
На этом же уровне располагается Android Runtime – среда выполнения. Ключевыми её составляющими являются набор библиотек ядра (Core Libraries) и виртуальная машина Dalvik. Библиотеки обеспечивают большую часть низкоуровневой функциональности, доступной библиотекам ядра языка Java.
Каждое приложение в ОС Android запускается в собственном экземпляре виртуальной машины Dalvik. Таким образом, все работающие процессы изолированы от операционной системы и друг от друга. И вообще, архитектура Android Runtime такова, что работа программ осуществляется строго в рамках окружения виртуальной машины. Благодаря этому осуществляется защита ядра операционной системы от возможного вреда со стороны других её составляющих. Поэтому код с ошибками или вредоносное ПО не смогут испортить Android и устройство на его базе, когда сработают. Такая защитная функция, наряду с выполнением программного кода, является одной из ключевых для надстройки Android Runtime.
Dalvik полагается на ядро Linux для выполнения основных системных низкоуровневых функций, таких как, безопасность, потоки, управление процессами и памятью. Вы можете также писать приложения на C/C++, которые будут работать непосредственно на базовом уровне ОС Linux. Хотя такая возможность и существует, необходимости в этом нет никакой.
Если для приложения важны присущие C/C++ скорость и эффективность работы, Android предоставляет доступ к нативной среде разработки (NDK – Native Development Kit). Она позволяет разрабатывать приложения на C/C++ с использованием библиотек libc и libm, а также обеспечивает нативный доступ к OpenGL.
Доступ к устройствам и системным службам Android осуществляется через виртуальную машину Dalvik, которая считается промежуточным слоем. Благодаря использованию Dalvik для выполнения кода программы разработчики получают в свое распоряжение уровень абстракции, который позволяет им не беспокоиться об особенностях конструкции того или иного устройства.
Виртуальная машина Dalvik может выполнять программы в исполняемом формате DEX (Dalvik Executable). Данный формат оптимизирован для использования минимального объема памяти. Исполняемый файл с расширением .dex создается путем компиляции классов Java с помощью инструмента dx, входящего в состав Android SDK. При использовании IDE Eclipse и плагина ADT (Android Development Tools) компиляция классов Java в формат .dex происходит автоматически.
Как было сказано выше, инструмент dx из Android SDK компилирует приложения, написанные на Java, в исполняемый формат (dex) виртуальной машины Dalvik. Помимо непосредственно исполняемых файлов, в состав приложения Android входят прочие вспомогательные компоненты (такие, например, как файлы с данными и файлы ресурсов). SDK упаковывает все необходимое для установки приложения в файл с расширением .apk (Android package). Весь код в одном файле .apk считается одним приложением и этот файлиспользуется для установки данного приложения на устройствах с ОС Android.

APPLICATION FRAMEWORK (КАРКАС ПРИЛОЖЕНИЙ)
Уровнем выше располагается Application Framework, иногда называемый уровнем каркаса приложений. Именно через каркасы приложений разработчики получают доступ к API, предоставляемым компонентами системы, лежащими ниже уровнем. Кроме того, благодаря архитектуре фреймворка, любому приложению предоставляются уже реализованные возможности других приложений, к которым разрешено получать доступ.
В базовый набор сервисов и систем, лежащих в основе каждого приложения и являющихся частями фреймворка, входят:

Activity Manager – менеджер Активностей, который управляет жизненными циклами приложений, сохраняет данные об истории работы с Активностями, а также предоставляет систему навигации по ним.
Package Manager – менеджер пакетов, управляет установленными пакетами на вашем устройстве, отвечает за установку новых и удаление существующих.
Window Manager – менеджер окон, управляет окнами, и предоставляет для приложений более высокий уровень абстракции библиотеки Surface Manager.
Telephony Manager – менеджер телефонии, содержит API для взаимодействия с возможностями телефонии (звонки, смс и т.п.)
Content Providers – контент-провайдеры, управляют данными, которые одни приложения открывают для других, чтобы те могли их использовать для своей работы.
Resource Manager – менеджер ресурсов, обеспечивает доступ к ресурсам без функциональности (не несущими кода), например, к строковым данным, графике, файлам и другим.
View System – богатый и расширяемый набор представлений (Views), который может быть использован для создания визуальных компонентов приложений, например, списков, текстовых полей, таблиц, кнопок или даже встроенного web-браузера.
Location Manager – менеджер местоположения, позволяет приложениям периодически получать обновленные данные о текущем географическом положении устройства.
Notification Manager – менеджер оповещений, благодаря которому все приложения могут отображать собственные уведомления для пользователя в строке состояния.

Таким образом, благодаря Application Framework, приложения в ОС Android могут получать в своё распоряжение вспомогательный функционал, благодаря чему реализуется принцип многократного использования компонентов приложений и операционной системы. Естественно, в рамках политики безопасности.
Стоит отметить, просто на понятийном уровне, что фреймворк лишь выполняет код, написанный для него, в отличие от библиотек, которые исполняются сами. Ещё одно отличие заключается в том, что фреймворк содержит в себе большое количество библиотек с разной функциональностью и назначением, в то время как библиотеки объединяют в себе наборы функций, близких по логике.

APPLICATIONS (ПРИЛОЖЕНИЯ)
На вершине программного стека Android лежит уровень приложений (Applications). Сюда относится набор базовых приложений, который предустановлен на ОС Android. Например, в него входят браузер, почтовый клиент, программа для отправки SMS, карты, календарь, менеджер контактов и многие другие. Список интегрированных приложений может меняться в зависимости от модели устройства и версии Android. И помимо этого базового набора к уровню приложений относятся в принципе все приложения под платформу Android, в том числе и установленные пользователем.
Считается, что приложения под Android пишутся на языке Java, но нужно отметить, что существует возможность разрабатывать программы и на C/C++ (с помощью Native Development Kit), и на Basic (с помощью Simple) и с использованием других языков. Также можно создавать собственные программы с помощью конструкторов приложений, таких как App Inventor. Словом, возможностей тут много.

голоса

Рейтинг статьи