Камеры в кастомных прошивках: как разработчики заставляют оборудование работать без исходного кода

Как разработчикам получить аппаратные компоненты, такие как камеры, работающие в пользовательских ПЗУ, без исходного кода? Ответ — BLOB, прокладка и много отладки.

С выпуском Android Oreo и многих устройств, таких как Сяоми Редми Примечание 3, Гугл Нексус 5 и другие неофициально получают его, вероятно, справедливо задаться вопросом, почему одни и те же функции (в основном камера) имеют тенденцию нарушаться, когда разработчики портируют ПЗУ на основе Android Open Source Project (AOSP). Вы, наверное, видели темы на форуме XDA, посвященные ПЗУ, с длинным списком неработающих функций вверху. «Что работает», за которым следует список рабочих функций, а затем внизу знаковое «Что не работает? Кому ты рассказываешь!" — это два популярных рефрена на наших форумах, которые практически стали мемами на таких сайтах, как Reddit и Twitter.

Почему так много функций нарушается всякий раз, когда разработчик пытается перенести ПЗУ AOSP на свое устройство? Основной ответ заключается в том, что, поскольку функции различаются в разных версиях Android, старые драйверы устройств, упакованные в виде BLOB-объектов, не будут работать с новыми версиями Android или даже со стандартным AOSP. Чтобы преодолеть это, разработчики используют так называемую «прокладку», но этот процесс сложен, требует много времени, а иногда его очень сложно отладить.

В этой статье мы расскажем, как работают прокладки, особенно в отношении правильной работы камеры на ПЗУ на основе AOSP. В качестве примера мы будем использовать OnePlus 3T. Обратите внимание, что трудности, связанные с работой этих функций, сильно зависят от устройства.

OnePlus 3T под управлением OxygenOS. Хотя телефоны OnePlus известны своей дружелюбностью к индивидуальной разработке, разработчики проделывают за кулисами большую работу по созданию стабильных портов AOSP.


Что такое прокладка или BLOB?

Чтобы хотя бы начать понимать часть того, что делают разработчики, нам сначала нужно объяснить несколько вещей. Хотя ОС Android имеет открытый исходный код (не зря ее называют Android Open Source Project), программное обеспечение (без ядра), поставляемое на тысячи устройств Android, таковым не является. Разработчики не имеют доступа к исходному коду Опыт Самсунга, ЭМУИ, КислородОС, или любой другой сторонний вариант Android.

Теперь разработчики, портирующие стандартный AOSP на устройства, не принадлежащие Google, вероятно, не заботятся об исходном коде этих скинов Android, поскольку они не будут модификация и сборка этих ПЗУ. Это было бы так, если бы не одна большая, большая причина: детали, необходимые для правильной работы камеры, в основном тот камера ХАЛ (уровень аппаратной абстракции), также с закрытым исходным кодом.

Проблема с закрытым исходным кодом не только HAL камеры, но и ПЗУ заключается в том, что разработчики, работающие над портированием AOSP на свое устройство, будут работа вслепую. ПЗУ OEM с закрытым исходным кодом может прекрасно взаимодействовать с HAL камеры, поскольку OEM имеет доступ к источнику HAL камеры. HAL камеры — это то, что позволяет ПЗУ «общаться» с аппаратным обеспечением камеры — без него камера была бы нефункциональной. Думайте о камере HAL как о рулевом колесе и педалях автомобиля. Рулевое колесо/педали позволяют управлять внутренними компонентами автомобиля, предоставляя водителю внешний интерфейс (ПЗУ) для использования внутренних компонентов.

Графика, показывающая архитектуру камеры. Источник: Google

Поскольку аппаратное обеспечение камеры становится все более и более сложным ( появление двойной камеры, например), наличие доступа к источнику HAL камеры значительно облегчит перенос ПЗУ AOSP с функциональной камерой.

Однако OEM-производители не предоставляют доступ к источнику HAL камеры по разным причинам. Во-первых, если у них нет всех прав собственности на камеру HAL (например, когда они включают интеллектуальную собственность других компаний), они не могут распространять исходный код. Во-вторых, публикация источника HAL камеры может поставить под угрозу их собственную интеллектуальную собственность. Наконец, компании не несут никаких юридических обязательств предоставлять этот исходный код (в отличие от исходного кода ядра, который они обязан выпускать под лицензией GPL), поэтому у них нет стимула выпускать его. Итак, без доступа к источнику HAL камеры, как именно разработчики могут заставить камеру работать на ПЗУ AOSP? Ответ — BLOB, прокладка и много-много отладки.

Устройство BLOB-объект (Binary Large OBject) содержит предварительно упакованные двоичные файлы, которые представляют собой скомпилированную форму программного обеспечения. В этом случае исходный код HAL камеры компилируется OEM-производителем и поставляется на устройства в виде двоичных файлов. Когда разработчики говорят о BLOB-объектах, они имеют в виду те двоичные файлы, которые поставляются на работающих устройствах и которые они могут извлечь. Теперь тема «BLOB-объектов камеры» давно мучаемый OnePlus в течение многих месяцев, но правда в том, что разработчики всегда имели доступ к BLOB-объектам камеры. Исходный код HAL камеры — золотой билет для разработчиков здесь, но это будет никогда, никогда не будет выпущен из-за юридической опасности это поставит под угрозу такие компании, как OnePlus.

Таким образом, разработчикам, желающим внедрить AOSP в устройство, остаются только BLOB-объекты HAL камеры, к исходному коду которых у них нет доступа. Редко, если вообще когда-либо, разработчик может связать свой код AOSP ROM с HAL BLOB камеры и ожидать, что он будет работать, поэтому, чтобы преодолеть разрыв между ними, разработчики создают то, что называется «прокладка.”

«Проложить» — значит «вклинить (что-то) или заполнить пространство». По сути, это то, что делает разработчик, когда написание прокладки — они добавляют код, позволяющий BLOB взаимодействовать с исходным кодом AOSP, над которым они работают. с. Прокладки используются для того, чтобы BLOB-объекты всех типов работали с AOSP, но обычно именно BLOB-объект камеры требует наибольшей регулировки. Как мы уже упоминали ранее, шиммирование требуется не только при портировании на устройство новых версий Android (таких как все эти неофициальные прошивки Android Oreo), но также необходимы при портировании на него AOSP той же версии Android. устройство.

Рекомендуемое чтение: От магазина до полки: подробное объяснение того, почему устройства MSM8974 исключены из Nougat

OnePlus 2, например, получил свой последнее официальное крупное обновление ОС в виде Android 6.0 Marshmallow. Однако на самом деле устройство имеет полностью рабочие кастомные ПЗУ на базе AOSP на базе Android Nougat, и это благодаря упорной работе разработчиков и их прошивок. Мы разберем несколько примеров прокладок, но сначала нам нужно поговорить о том, как именно они работают.


Как работает шиммирование?

Поскольку у разработчиков нет доступа к HAL камеры или источнику OEM-ROM (и только к предварительно скомпилированным двоичным файлам), они не могут знать, какие функции ожидает HAL камеры. Из-за этого часто возникает несоответствие имени функции, которую ищет HAL камеры, и фактического имени функции в коде AOSP, с которым работает разработчик.

Чтобы решить эту проблему, разработчик просто создает новую функцию, которая использует то же имя, что и функция. функция, которую ожидает камера HAL BLOB, но эта новая функция просто выполняет то, что хочет разработчик это чтобы. Эта новая функция, выступающая в роли посредника между BLOB и AOSP, называется прокладкой. Этот конкретный сценарий, в котором BLOB не может найти искомую функцию, является одним из наиболее распространенных случаев, когда требуется прокладка.

Очень простая схема MS Paint, показывающая, где нужна прокладка.

Возможно, ситуация станет более понятной на гипотетическом примере с OnePlus 3T. Мы создадим пример, используя OxygenOS и камеру OnePlus. Если мы будем использовать BLOB-объекты камеры, взятые из OxygenOS Nougat для OnePlus 3T, для создания ПЗУ Nougat на основе AOSP, мы можем столкнуться с проблемами. Это связано с тем, что BLOB-объекты камеры (которые изначально были скомпилированы OEM) смогут ссылаться на все необходимые функции в OxygenOS, но поскольку скомпилированное ПЗУ AOSP может не иметь этих функций или они могут быть скомпилированы под другим именем (что приводит к несоответствию между символами функций), возникнет ошибка ошибка. Это можно исправить, создав в ПЗУ AOSP новую функцию с именем, ожидаемым для BLOB, — нашей прокладкой.

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

Просмотр таблицы символов с помощью Hopper. Источник: Априорит

Объяснение, которое мы предложили до сих пор, звучит так, будто создавать прокладки легко. Изменение нескольких названий функций здесь и там не кажется слишком сложным, не так ли? Если бы все было так просто. Реальность использования прокладок включает в себя нечто большее, чем просто переименование функций. Мы поговорили с признанным разработчиком XDA Султанксдой, который смог предоставить нам пример одной из самых сложных прокладок, над которыми он работал.


Шимпинг – не так просто, как кажется

Для тех, кто не знаком с OnePlus 3T, фронтальная камера изначально была сломана. Пользовательские ПЗУ на основе AOSP. Начнем с того, что попытка сделать любой снимок с разрешением более 8 МП приведет к сбой. Пытаясь решить эту проблему, Султанхда сделал несколько прокладки чтобы фронтальная камера OnePlus 3T работала правильно.

Прокладка №1 — изменение имени пакета камеры

Чтобы предотвратить сбой фронтальной камеры всякий раз, когда пользователь делал снимок с разрешением более 8 МП, Султанксда заставил камеру HAL идентифицировать все камеры как камеру OnePlus. Это сделано потому, что OnePlus решил выделить вспомогательную функцию для определенных приложений (isOnePlusCamera, isFacebookCameraи т. д.) по какой-то причине. Султанксда исправил это, изменив HAL камеры так, чтобы он указывал на новую функцию, которая всегда возвращает «истину», как если бы пользователь использовал камеру OnePlus, даже если это не так.

Прокладка №2 — отключить QuadraCfa

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

Он заметил, что QuadraCfa каким-то образом включается, но не был уверен, почему и как это происходит. Решение этой проблемы потребовало с его стороны довольно нетрадиционной модификации. В обычной оболочке функция shim при компиляции предоставляет недостающий символ, который ищет BLOB. В данном случае BLOB уже имел необходимые символы — те, которые предположительно представляли функции, запускавшие QuadraCfa.

Благослови Hex-редактор. Использовала программу Султанксда.

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

Шестнадцатеричное редактирование функции существенно сложнее, чем шестнадцатеричное редактирование строки, но, к счастью, Султанксде удалось избежать шестнадцатеричного редактирования функций, лежащих в основе QuadraCfa, вместо этого шестнадцатеричное редактирование имен символов, чтобы аннулировать эти символы.

Прокладка №3 — исправление сбоя при ярком свете

Далее Султанхда обнаружил, что съемка с помощью фронтальной камеры в условиях яркого освещения может привести к сбою камеры. Чтобы воспроизвести этот баг на своем устройстве, Султанxda на самом деле включил функцию фонарика на своем OnePlus One и посветил светом перед фронтальной камерой OnePlus 3T. чтобы привести его к сбою и создать пригодные для использования журналы! Как только он обнаружил, какая функция вызывает сбой, он создал прокладку, заставляющую устройство постоянно использовать режим низкой освещенности для фронтальной камеры.

Прокладка №4 – снимки фронтальной камеры с низким разрешением

Исправив сбой при ярком свете с помощью предыдущей прокладки, Султанксда обнаружил еще одну ошибку, которая на самом деле возникла как прямой результат этой прокладки: снимки с фронтальной камеры с низким разрешением. Вместо того, чтобы фотографировать с разрешением, запрошенным пользователем (например. 16 МП), результирующий снимок будет сделан с разрешением 4 МП.

Решение этой проблемы потребовало, чтобы он подстроил функции handleSuperResolution и isSuperResolution чтобы всегда возвращать true, но ТОЛЬКО когда активна фронтальная камера (потому что в противном случае камера выйдет из строя при съемке с заднего датчика).


Извлеченный урок: шиммирование может быть трудным

Султанксда признает, что прокладки, которые ему пришлось создать, чтобы заставить работать фронтальную камеру OnePlus 3T, не представляют собой типичный пример прокладки. Он очень гордится своей прошивкой, учитывая ее сложность и редкую необходимость шестнадцатеричного редактирования самого BLOB. Но этот пример просто показывает, насколько сложно заставить аппаратное обеспечение камеры работать на определенных устройствах.

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

Журналы, журналы и еще раз журналы. Без единого способа воспроизведения сбоя и журналов у разработчиков мало надежды найти источник проблемы. Даже если они найдут причину проблемы, ее не всегда можно легко исправить. Весь процесс поиска и устранения этих ошибок может занять дни или недели, и именно поэтому исправление камеры на ПЗУ AOSP является одной из наиболее сложных задач.

Если на вашем устройстве портировано ПЗУ AOSP с полностью функционирующим оборудованием, мы надеемся, что вы можете начать оцените борьбу, через которую, возможно, пришлось пройти этим разработчикам, чтобы предоставить вам эти функции. Цените их за труд, ведь это непросто. Это большая работа, которую подавляющее большинство пользователей даже не заметит, поскольку талантливые разработчики на наших форумах заботятся о многих невидимых частях Android.

Мы хотели бы выразить особую благодарность Султанксде за большой вклад, который он внес в создание этой статьи.