Русские Блоги
Анализ фреймворка Android 8.0 RIL
Оригинальный адрес: https://blog.csdn.net/qq_27540925/article/details/79356799
Предисловие
Версия Android O изменила функцию связи в среде RIL. Вместо использования sockect для связи используйте HIDL для связи. Здесь мы объединяем исходный код 7.0 и 8.0 для анализа текущей среды RIL. Пожалуйста, не стесняйтесь исправлять меня в случае каких-либо ошибок.
Вход в RIL
- По сравнению с android N основное отличие состоит в том, что сокет заменен на сервис для связи. Продолжаем видеть его основные операции:
1. Включите цикл
2. Инициализация RIL_Init
3. Функция обратного вызова зарегистрированной ссылки
Вот сравнительный анализ этих начальных операций. Полный процесс RIL см. в RIL Framework Analysis 2.
Открытый цикл
Продолжить отслеживать RIL_startEventLoop
- Продолжайте анализировать функцию eventLoop
- 1.1 Продолжить отслеживать функцию event_init
- Инициализируйте дескриптор файла и два списка, timer_list и pending_list и watch_table.
Отслеживая его определенный тип, убедитесь, что две таблицы являются переменными ril_event, а watch_table — это массив указателей.
- Проанализируйте тип ril_event
- Вы можете видеть, что этот тип на самом деле является двусвязным списком, а timer_list, pending_list и watch_table являются связанными списками.
1.2 Затем следуйте конкретной реализации цикла eventLoop
- Подведите итог обработки событий
В системе управления событиями RIL есть три структуры связанных списков: watch_table, timer_list, pending_list
Наблюдайте (если он останется, он будет обрабатываться каждый раз) и таймер (если время истекло, он будет обработан) просто выделение, фактическое место окончательной обработки — pending_list,), а пул дескрипторов устройства readFDS используется для сохранения всех сокетов Дескриптор файла трубы сохранен.
Процесс управления можно обобщить в виде следующих 6 пунктов:
1. Вы можете добавить событие в watch_table или timer_list;
2. Если событие добавлено в watch_table, вам нужно добавить fd (дескриптор устройства события) текущего события в readFDS;
3. Если событие добавляется в список timer_list, нет необходимости добавлять fd (дескриптор устройства события) текущего события в readFDS, а значение fd текущего события недопустимо;
4. В процессе обнаружения цикла, если событие находится в watch_table, текущее событие будет добавлено в список pending_list. Если атрибут persist текущего события равен false, это означает, что текущий узел не нужно сохранять. Удалите текущее событие из watch_table, если значение persist равно true, это означает, что его нужно сохранить, и нет необходимости удалять текущий узел из watch_table. к
5. Если в процессе обнаружения цикла обнаружилось, что событие в списке timer_list установлено как превышенное по времени, переместите текущее событие в список pending_list и одновременно удалите узел из списка timer_list. к
6. В процессе обнаружения цикла после обработки watch_table и timer_list перейдите к pending_list и выполните функцию, на которую указывает Event внутри.
RIL_Init инициализация
Загрузите файл ссылки, загрузив библиотеку ссылок
- Посмотрите открытый поток обработки вызова mainLoop
- Как вы можете видеть выше, открыт не только канал АТ, но и установлен метод тайм-аута.
Продолжите с waitForClose и обнаружите, что когда s_closed = 0, он продолжит ждать, ищет изменение значения s_closed и обнаруживает, что значение будет изменено на 1 в двух местах, а именно onATTimeout и onATReaderClosed.
После того, как текущий поток открывает канал AT, он блокирует и ждет в waitForClose. Если канал AT обнаруживает тайм-аут, он будет активно закрывать текущий канал AT. В это время будет активирован заблокированный поток в waitForClose, а затем вернется waitForClose.
Как только функция waitForClose вернется, она снова войдет в цикл for и снова откроет канал AT.
Продолжать следить за открытием канала АТ
- Посмотрите вызов open thread readLoop processing
- Вы можете видеть, что метод s_unsolHandler или processLine в основном вызывается для обработки сообщения.
2.1 Продолжить анализировать s_unsolHandler (line1, line2);
Найдите инициализацию s_unsolHandler и инициализируйте ее в at_open, который включен вUnsolicited в reference-ril.c.
- Видно, что это обрабатывается отдельно в соответствии с разницей в начале, есть много случаев, здесь указан только первый случай
Можно видеть, что поток обработки сообщения URC в основном состоит в том, чтобы преобразовать его в разные индексы команд в соответствии с разными заголовками команд, а затем вызвать функцию RIL_onUnsolicitedResponse.
Поэтому мы продолжаем отслеживать метод RIL_onUnsolicitedResponse
И реализация RIL_onUnsolicitedResponse:
- Объясните, что эта функция вызывает метод OnUnsolicitedResponse переменной s_rilenv. Так где же инициализируется s_rilenv?
Поиск s_rilenv, вы можете найти его вИнициализируется при вызове метода RIL_Init
Это форма, когда мы инициализируем справочную библиотеку в главной функции в rild.c:
Вышеупомянутый процесс инициализации передает глобальную переменную s_rilEnv в ссылку, а затем передает это значение в s_rilenv в файле reference-ril.c, и каждая функция обработки s_rilEnv реализована в файле ril.cpp. к
После обхода вышеизложенного обработка сообщения была избавлена от динамической библиотеки (то есть файла reference-ril.c) обратно в файл ril.c. к
Это в точности концепция дизайна всей архитектуры RIL: структура и методы обработки управляются ril.c, а дифференцированные AT-команды реализуются посредством ссылки.
Так что продолжайте проверять конкретную реализацию в ril.c
Сосредоточьтесь на продолжении s_unsolResponses
Вы можете видеть, что s_unsolResponses [unsolResponseIndex] .responseFunction фактически вызывает метод radio :: callStateChangedInd.
Если вы сравните определение ril_unsol_commands для android N, то обнаружите, что метод обработки изменился. к
В исходном N-коде метод ответа в ril_unsol_commands фактически переопределен в ril.cpp, а ril_unsol_commands.h определяет только метод обработки.
Затем мы продолжаем отслеживать radio :: callStateChangedInd по коду O, и мы можем обнаружить, что он находится вРеализовано в ril_service.cpp
Продолжайте следить за методом radioService [slotId] -> mRadioIndication-> callStateChanged
Я обнаружил, что здесь фактически вызывается метод mRadioIndication, такой же, как в предыдущем процессе Android8.0 MT 1.
Отслеживать класс RadioIndication
Давайте продолжим смотреть на его унаследованный IRadioIndication.Stub, глобальный поиск RadioIndication может обнаружить, что он определяет этот интерфейс в IRadioIndication.hal.
Обратите внимание на класс RadioIndication и обнаружите, что он определяет большое количество методов, похожих на callStateChanged, а затем сравните метод processUnsolicited на 7.0,Было обнаружено, что основной ответ, который обрабатывался единообразно с помощью метода, теперь обрабатывается классом RadioIndication, Его callStateChanged соответствует элементу callStateChanged переключателя в предыдущем методе processUnsolicited и т. Д. Для остальных.
Разница между RIL-связью 7.0 и 8.0 относительно велика. После того, как уровень RIL получает базовое сообщение, он инициирует уведомление уведомления.
По сравнению со структурой N он сначала вызывает метод для упаковки данных ответа, а затем использует сокет для его отправки, тогда как в O метод вызывается напрямую для обработки данных ответа, и вызов HIDL выполняется через RadioIndication, и он напрямую направляется в RIL. Место.
2.2 Продолжить анализ обработки метода processLine
Сообщения, не относящиеся к URC, обычно имеют несколько строк. Когда обработка заканчивается, будет вызван handleFinalResponse для продолжения отслеживания.
Функция обратного вызова зарегистрированной ссылки
Продолжайте следить за RIL_register (funcs), отследите метод регистрации в RIL.C и обнаружите, что 8.0 был изменен, обмен данными осуществляется через службу регистрации, а обмен данными осуществлялся через сокет ранее.
Продолжайте следить
// Регистрация службы ril_service
Передача обратных вызовов при регистрации услуги,
Источник
Русские Блоги
Анализ ядра Android (18) —— RIL-Java телефонной системы Android
Android RIL-Java
RIL-Java по сути является прокси-сервером RIL, который играет роль пересылки и является отправной точкой телефонной системы в концептуальном пространстве Android Java. При анализе RIL-D мы знаем, что RILD установил прослушивающий сокет, ожидающий соединения RIL-Java. После подключения к RIL-JAVA может инициировать запрос, ожидать ответа и отправлять структуру целевому объекту обработки. В RIL-Java этот запрос называется RILRequest. Чтобы интуитивно видеть , я все же даю структуру RIL-Java, не скучая.
Платформа RIL-Java включает четыре аспекта:
Получатель, Отправитель, CommandInterface, механизм асинхронного уведомления
（1） Command Interface
В исходном коде ril.java мы видим, что объект RIL-JAVA предоставляет следующий командный интерфейс:
Почему эти интерфейсы определены? Этот функциональный интерфейс сделан не из ничего, это описание основных функций телефона и абстрактные абстракции команд модема AT. Большинство модемов предоставляют интерфейсы на основе протокола связи. Если мы не знакомы с протоколом связи, пожалуйста, обратитесь к соответствующим документам 3GPP и описанию SPEC используемого нами модема.
3GPP 07.07 AT Comamnds-General commands
3GPP 07.07 AT Comamnds-Call Control commans
3GPP 07.07 AT Comamnds-Network Service related commands
3GPP 07.07 AT Comamnds-MT control and status command
3GPP 07.07 AT Comamnds-GPRS Commands
3GPP 07.07 Mobile Termination Errors
3GPP 07.05 SMS AT Commands
（2）Receiver
Получатель Подключитесь к сервисному сокету RILD, получите и прочитайте посылку ответа из RILD. Ответ делится на два типа: один — URC, а другой — ответ команды. URC будет напрямую передан Обработчику в реестре уведомлений. Ответ на команду передается отправителю команды через механизм асинхронного уведомления получателя для соответствующей обработки.
（3）Sender
Отправитель должен быть разделен на две части,
Функция верхнего уровня вызывает командный интерфейс для отправки сообщения запроса в архитектуру отправителя.
После получения сообщения EVENT_SEND отправитель отправляет запрос в архитектуру RILD.
(4) Структура асинхронного ответа
Для асинхронного ответа инициатор команды возвращается без ожидания ответа. Ответ ответа является асинхронным, и результат обработки передается Сообщение возвращается. С точки зрения дизайнера, как спроектировать подходящую среду для выполнения функции асинхронной связи? Для асинхронных систем первое, что мы должны рассмотреть, — это как определить команду и результат, чтобы между командой и результатом было соответствие, а для команды не было ответа, как управлять временем ожидания команды? Давайте посмотрим, как дизайнеры Android делают это.
Разработчики Android используют объекты Result Message и RILRequest для завершения запроса и результата Для должно быть для отношений. Когда вызов выполняется на верхнем уровне, объект Result Message генерируется и передается в ril_java, и после того, как модем получил ответ, результат возвращается через объект сообщения Result . Как убедиться, что ответом является RILRequest? Разработчики Android также предлагают концепцию Token (токен). В исходном коде в качестве токена используется mSerail RILRequest. Токен используется для уникальной идентификации каждого отправленного запроса, и токен будет передан в RILD, RILD должен быть собран . Ответ заключается в написании токена и передаче обратно в ril-java. Java находит соответствующий объект запроса в соответствии с токеном.
(4.1) Режим передачи команд RIL
Реальная реализация протокола в rild. RIL-JAVA — это скорее абстракция и прокси. Когда мы изучим исходный код, мы поймем, что командные функции в RIL-JAVA имеют общую структуру.
SendXxxCmd (входящий параметр Data, исходящий параметр result) <
Объединить RILRequest (номер запроса, результат, mSerail)
запрос будет передан в RILD для идентификации команды, а запрос представляет определенную функцию. Например, набранный номер запроса: RIL_REQUEST_DIAL. Он определен в libs / telephony / ril_commands.h. [email protected] В соответствии с номером запроса команды, передайте сообщение результата параметра , mSerail создает RILRequest. Сообщение о результате вернет ответное сообщение обратно отправителю команды.
Android использует пул объектов RILRequest для управления Andoird RILRequest. mSerail — это инкрементная переменная, используемая для уникальной идентификации RILRequest. Эта переменная используется в качестве токена при отправке, а токен, видимый на уровне rild, — это mSerail.
2) Отправка шагов:
Сгенерируйте RILRequest, в это время будет сгенерирован m_Serial (запрошенный токен), а номер запроса, данные и объект сообщения результата будут заполнены в RILRequest.
Используйте команду send to package RILRequest в сообщение EVENT_SEND и отправьте его обработчику отправителей RIL,
RilSender получает сообщение EVENT_SEND, отправляет RILRequest в RILD через сокет и сохраняет RILRequest в mRequest, чтобы ответить на возврат сообщения.
(4.2) Режим приема
Первый шаг: проанализировать полученную посылку и обработать ее в соответствии с различными типами.
Второй шаг: согласно токену (mSerail) в данных, верните mRequest назад, чтобы найти соответствующую информацию запроса.
Шаг 3: преобразовать данные в данные результата.
Шаг 4: Поместите результат в RequestMessage и отправьте его обратно инициатору запроса.
Источник
