Основы безопасности операционной системы 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 отсутствуют заголовочные файлы <sys/ipc.h>, <sys/sem.h>, <sys/shm.h>, <sys/msg.h>. В некоторых специфических случаях (например, для взаимодействия с демоном 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). Материал уже есть, но надо его перевести и подработать. Как всегда буду благодарен за интересные вопросы и пояснения в комментариях, возможно некоторые моменты я неправильно для себя понял.
Приложение Context Service остановлено на Samsung Galaxy: что это, как убрать?
Программы и продукты для полноценной работы устройства появляются день ото дня. Однако, наступает такой момент, когда внезапно перестает работать программа или, когда работа некорректна.
Оповещение «к сожалению, Context Service остановлено на Samsung Galaxy». О том, что это такое спрашивают пользователи сети. Причина возникновения — работа с приложениями, и, используемым софтом.
Как исправить ошибку
Для корректной работы используют:
Перезапуск. Применим, если проблема проявляется при работе с софтом, а не сторонними программами.
Нужно удалить софт, а потом — начать установку. после, следует удостовериться в том, что удалось ли избавиться от ошибки.
Очищение кэша. Файлы — источники ошибок и проблем, возникающих в ПО. Решаются проблемы, связанные с приложением. Для выполнения процесса, потребуется:
- Переход в «Настройки»;
- Раздел «Приложения»
- «Диспетчер задач»;
- Выбор «Все»;
- Поиск ПО, выдавшего ошибку;
- Выполнение очистки.
Чистка оперативной памяти
Профилактика возникновения ошибок. Работа программного софта — в фоновом режиме, применяется значительный объем памяти устройства. Из-за этого засоряется существенное количество оперативной памяти. Ввиду этого и возникает некорректная работа. Алгоритм решения проблемы: «Диспетчер задач» —«Очистка памяти».
Перед тем, как приступить к выполнению сброса аппаратных настроек до заводских и предпринимать попытки исправления ошибок и коррекции работы «ПО остановилось», не представляется возможным создать резервную копию. Для этого требуется переход «Настройки» следует найти опцию резервного копирования и интерфейса, в которой выполняется резервное создание копий текущих опций и сведений приложений для последующего восстановления.
Есть возможность переброса информации на ПК — на это уйдет минимум времени.
Context – контекст в android – что это, как получить и зачем использовать
Контекст (Context) – это базовый абстрактный класс, реализация которого обеспечивается системой Android. Этот класс имеет методы для доступа к специфичным для конкретного приложения ресурсам и классам и служит для выполнения операций на уровне приложения, таких, как запуск активностей, отправка широковещательных сообщений, получение намерений и прочее. От класса Context наследуются такие крупные и важные классы, как Application, Activity и Service, поэтому все его методы доступны из этих классов.
Получить контекст внутри кода можно одним из следующих методов:
- getBaseContext(получить ссылку на базовый контекст)
- getApplicationContext(получить ссылку на объект приложения)
- getContext (внутри активности или сервиса получить ссылку на этот объект)
- this(то же, что и getContext)
- MainActivity.this (внутри вложенного класса или метода получить ссылку на объект MainActivity)
- getActivity(внутри фрагмента получить ссылку на объект родительской активности)
Контекст (Context) – это базовый абстрактный класс, реализация которого обеспечивается системой Android. Этот класс имеет методы для доступа к специфичным для конкретного приложения ресурсам и классам и служит для выполнения операций на уровне приложения, таких, как запуск активностей, отправка широковещательных сообщений, получение намерений и прочее. От класса Context наследуются такие крупные и важные классы, как Application, Activity и Service, поэтому все его методы доступны из этих классов. Источник
Получить контекст внутри кода можно одним из следующих методов:
Context service что это за программа на Андроид
в программировании Android, что именно является Context класс и для чего он используется?
Я читал об этом на сайте разработчика, но я не могу это четко понимать.
автор: Nilesh Singh
30 ответов
как следует из названия, это контекст текущего состояния приложения / объекта. Он позволяет вновь созданным объектам понимать, что происходит. Обычно вы вызываете его, чтобы получить информацию о другой части вашей программы (активность и пакет/приложение).
вы можете получить контекст, вызывая getApplicationContext() , getContext() , getBaseContext() или this (когда в классе, который простирается от Context , как применение, деятельность, обслуживание и IntentService классы).
типичное использование контекста:
-
создание новых объектов: Создание новых представлений, адаптеров, прослушивателей:
TextView tv = new TextView(getContext()); ListAdapter adapter = new SimpleCursorAdapter(getApplicationContext(), . );
context.getSystemService(LAYOUT_INFLATER_SERVICE) getApplicationContext().getSharedPreferences(*name*, *mode*);
getApplicationContext().getContentResolver().query(uri, . );
автор: Sameer Segal
определение контекста ::
- контекст представляет данные среды
- он обеспечивает доступ к таким вещам, как базы данных
более простые термины::
- рассмотрим Person-X является генеральным директором начинающей компании программного обеспечения.
- в компании присутствует ведущий архитектор, этот ведущий архитектор делает всю работу в компании которая включает такие как база данных, UI так далее.
- теперь генеральный директор нанимает нового разработчика.
- это архитектор, который говорит ответственность вновь нанятых человек, основанный на навыках нового человека, что ли он будет работа над базой данных или UI и т. д.
более простые термины::
- это как доступ активности android к ресурсу приложения.
- это похоже на то, когда вы посетите отель, вы хотите завтрак, обед ужин быть ресурсами.
вещи, которые включают контекст:
Уроки Андроид программирования | #8 — Красивый дизайн приложения
- загрузки ресурса.
- запуск нового вида деятельности.
- создание представлений.
- получение системы обслуживания.
контекст является базовым классом для активность, сервис, приложение . и т. д.
другой способ описать это: рассмотрите контекст как удаленный от телевизора и канала в телевизоре-это ресурсы, услуги, использование намерений и т. д. — — — Здесь удаленный действует как доступ, чтобы получить доступ ко всем различным ресурсам на переднем плане.
- таким образом, Remote имеет доступ к каналам, таким как ресурсы, услуги, использование намерений и т. д.
- дополнительно . У кого есть доступ к удаленным, естественно, имеет доступ ко всем вещи, такие как ресурсы, сервисы, с помощью намерения и т. д.
разные методы, с помощью которых вы можете получить контекст
- getApplicationContext()
- getContext()
- getBaseContext()
- или this (когда в классе activity)
TextView TV=new TextView(this);
this -> относится к контексту текущая деятельность.
тема контекста в Android кажется запутанной для многих. Люди просто знают, что контекст необходим довольно часто, чтобы делать основные вещи в Android. Люди иногда паникуют, потому что они пытаются выполнить какую-то операцию, которая требует контекста, и они не знают, как «получить» правильный контекст. Я попытаюсь прояснить идею контекста в Android. Полное рассмотрение этого вопроса выходит за рамки этого поста, но я постараюсь дать общий обзор, чтобы у вас было представление о том, что такое контекст и как его использовать. Чтобы понять, что такое контекст, давайте посмотрим на исходный код:
что такое контекст?
Ну, сама документация дает довольно простое объяснение: класс контекста является » интерфейсом для глобальная информация о среде применения».
сам класс контекста объявляется как абстрактный класс, реализация которого обеспечивается ОС Android. В документации далее предусматривается, что контекст «. обеспечивает доступ к ресурсам и классам конкретных приложений, а также к вызовам для операций на уровне приложений, таких как запуск мероприятий, вещание и получение намерений и т. д.».
теперь вы можете очень хорошо понять, почему имя является контекстом. Потому что так оно и есть. Контекст предоставляет ссылку или крючок, если хотите, для действия, службы или любого другого компонента, тем самым связывая его с системой, обеспечивая доступ к глобальной среде приложений. Другими словами: контекст дает ответ на вопрос компонентов «где, черт возьми, я по отношению к приложению в целом и как я могу получить доступ/общаться с остальной частью приложения?»Если все это кажется немного запутанным, быстрый взгляд на методы, предоставляемые контексте класс дает некоторые дополнительные подсказки о его истинной природе.
вот случайная выборка этих методов:
- getAssets()
- getResources()
- getPackageManager()
- getString()
- getSharedPrefsFile()
что общего у всех этих методов? Все они позволяют любому, кто имеет доступ к контексту, иметь доступ к ресурсам всего приложения.
контекст, другими словами, крючки компонент, который имеет ссылку на него для остальной среды приложения. Активы (например, папка «/assets » в вашем проекте) доступны в приложении при условии, что действие, служба или что-либо еще знает, как получить доступ к этим ресурсам. То же самое касается getResources() , которая позволяет делать такие вещи, как getResources().getColor() который зацепит вас в colors.xml resource (неважно, что aapt обеспечивает доступ к ресурсам через java-код, это отдельная проблема).
результат это Context это то, что позволяет получить доступ к системным ресурсам и его, что подключает компоненты в «большее приложение». Давайте рассмотрим подклассы Context классы, которые обеспечивают реализацию абстрактного Context класса. Наиболее очевидным классом является Activity класса. Activity наследует от ContextThemeWrapper , который наследует от ContextWrapper , который наследует от . Эти классы полезны для изучения, чтобы понять вещи на более глубоком уровне, но на данный момент достаточно знай это ContextThemeWrapper и ContextWrapper в значительной степени то,что они звучат. Они реализуют абстрактные элементы Context сам класс путем «обертывания» контекста (фактического контекста) и делегирования этих функций этому контексту. Пример полезен — в ContextWrapper класс, абстрактный метод getAssets С Context класс реализован следующим образом:
mBase — это просто поле, заданное конструктором в определенном контексте. Таким образом, контекст обернут и ContextWrapper делегирует свою реализацию метода getAssets в этот контекст. Давайте вернемся к изучению Activity класс, который в конечном счете наследуется от Context чтобы увидеть, как это все работает.
вы, вероятно, знаете, что такое активность, но для обзора — это в основном » одна вещь, которую пользователь может сделать. Он заботится о предоставлении окна, в котором разместить пользовательский интерфейс, с которым пользователь взаимодействует». Разработчики, знакомые с другими API и даже не разработчики могут думать об этом vernacularly в качестве «экрана.- Технически это неточно, но для наших целей это не имеет значения. Так как Activity и Context взаимодействовать и что именно происходит в их отношениях наследования?
опять же, полезно посмотреть на конкретные примеры. Мы все знаем, как начать деятельность. Если у вас есть «контекст», из которого вы начинаете действие, вы просто вызываете startActivity(intent) , где намерение описывает контекст, из которого вы начинаете действие и деятельность, которую вы хотели бы начать. Это знакомый startActivity(this, SomeOtherActivity.class) .
и что такое this ? this это ваша деятельность, потому что Activity класс наследует от Context . Полный совок выглядит так: Когда вы звоните startActivity , в конечном счете Activity класс выполняет что-то вроде этого:
Instrumentation.ActivityResult ar = mInstrumentation.execStartActivity( this, mMainThread.getApplicationThread(), mToken, this, intent, requestCode);
таким образом, он использует execStartActivity С Instrumentation класс (на самом деле из внутреннего класса в Instrumentation под названием ActivityResult ).
на данный момент, мы начинаю заглядывать внутрь системы.
здесь OS фактически обрабатывает все. Итак, как именно инструментарий начинает работу? Ну, парам this на execStartActivity метод выше-это ваша деятельность, то есть контекст, и execStartActivity использует этот контекст.
обзор 30,000 таков: класс Instrumentation отслеживает список действий, которые он отслеживает, чтобы выполнить свою работу. Этот список используется для координации все действия и убедитесь, что все работает гладко в управлении потоком деятельности.
есть некоторые операции, которые я не полностью изучил, какие проблемы с координацией потока и процесса. В конечном счете, ActivityResult использует собственную операцию — ActivityManagerNative.getDefault().startActivity() использует Context что вы прошли, когда вы позвонили startActivity . Контекст, который вы передали, используется для помощи в «разрешении намерений», если это необходимо. Разрешение намерений-это процесс, с помощью которого система может определить цель намерения, если она не указана. (Проверьте здесь для более подробной информации).
и для того, чтобы Android сделать это, ему нужен доступ к информации, которая поставляется Context . В частности, система должна получить доступ к ContentResolver таким образом, он может «определить тип MIME данных намерения». Это все о том, как startActivity использование контекста было немного сложным, и я сам не полностью понимаю внутренние органы.
Моя главная мысль заключалась в том, чтобы проиллюстрировать, как для выполнения многих операций, необходимых для приложения, необходимо получить доступ к ресурсам всего приложения. Context это то, что обеспечивает доступ к этим ресурсам. Более простым примером могут быть представления.
Мы все знаем, что вы создаете пользовательский вид, расширяя RelativeLayout или какой-то другой View class, вы должны предоставить конструктор, который принимает Context в качестве аргумента. Когда вы создаете свой пользовательский вид, вы передаете его в контексте. Почему? Потому что представление должно иметь доступ к темы, ресурсы и другие сведения о конфигурации представления.
Конфигурация View — отличный пример. Каждый контекст имеет различные параметры (поля Context реализации), которые устанавливаются самой ОС для таких вещей, как размер или плотность дисплея. Легко понять, почему эта информация важна для настройки представлений и т. д.
последнее слово: По какой-то причине люди, новые для Android (и даже не такие новые), похоже, полностью забывают о объектно-ориентированное программирование, когда дело доходит до Android. По какой-то причине люди пытаются склонить свою разработку Android к заранее задуманным парадигмам или изученному поведению.
Android имеет свою собственную парадигму и определенный шаблон, который на самом деле довольно последователен, если отпустить ваши заранее задуманные понятия и просто прочитать документацию и руководство dev. Моя реальная точка зрения, однако, в то время как «получение правильного контекста» иногда может быть сложным, люди неоправданно паникуют, потому что они сталкиваются с ситуация, когда они нуждаются в контексте и думают, что у них его нет. Опять же, Java-это объектно-ориентированный язык с дизайном наследования.