Для того чтобы собрать ядро под телефон нужны такие ингредиенты: компилятор, исходники ядра, конфигурация ядра.
Если с первым и последним все достаточно просто, то с последним как повезет.
Или если по порядку:
Скачать компилятор можно с AOSP, где лежит стандартный компилятор уже "оптимизированный" под сборку Android,
что дает нам большой процент вероятности, что у нас все же что-то соберется. Хотя тут тоже могут быть скрытые проблемы модифицированный компилятор использованный при сборке, но такой случай маловероятен иначе на устройстве не будут работать приложения собранный стандартным компилятором из NDK.
Получение конфигурации ядра тоже достаточно простая операция можно получить установив эмулятор терминала на устройство
или запустив adb и сделав копию /proc/config.gz. С конфигурацией тоже могут быть проблемы: отсутствие этой конфигурации по указанному пути,
так как производитель решил сэкономить таким образом место, заблокированный доступ к системным каталогам,
заблокированный запуск стандартный утилит, заблокированный доступ к системным областям, не стандартные устройства или
их не канонические названия, производитель модифицировал стандартное устройство по своему усмотрению -
в общем проблемы могут быть даже здесь. Но в основном все же доступ к конфигурации есть, заблокирован только доступ к dmesg,
записи или чтению системных устройств - чтобы нельзя было получить прошивку или заменить ее.
С исходными кодами ядра для устройств - все немного грустнее - андроид использует "стабильное" ядро с дополнениями от разработчиков как самого андроид так и дополнениями от создателей устройства. Это приводит к тому, что используются не канонические способы работы с памятью,
энергосбережением и аппаратурой. И в основную ветку изменения не возвращают - так как если для самих разработчиков андроид это имеет смысл
для сокращения различий в ядрах и упрощения обновления, но все же они используют свои решения которые не прошли по причинам различия взглядов
с менеджерами подсистем или не проработанных полностью в каких-то областях близких, но не критичных для разработчиков устройств, но очень важных для
стандартного универсального ядра, что позволяет их с утерей некой универсальности быстро применить свое решение и выпустить продукт
не дожидаясь полного цикла одобрения и завершения обсуждения внесённых новшеств.
Для разработчиков конечного устройства вопрос
универсальности или использования одобренных или обсуждённых с сообществом решений вообще теряет смысл, у них несколько иная цель -
выпуск продукта в ограниченные сроки, c ограниченной поддержкой вида "работает - не трогай", что приводит к неочень хорошим результатам
на всех уровнях. Как пример, это может быть такая ситуация: в прошивке используется как MARCH значение платформы описание, которой отстутстует в
исходниках ядер для других устройств стандартного ядра которое дается производителем SOC, врезультате у нас есть описание чипа из
спецификации устройства, но описания как иммено оно сконфигурировано нет. И нужно дожидатся открытия исходникой ядра иммено под это конечное
устройство, что может произходить достаточно не быстро или вообще не произойти никогда. Следущая проблема качество этих исходных кодов,
так как эти исходники собирались только для одного устойства с четко определенным списком функций, никто не обновляет эти ядра из общего
хранилища кодов и не возвращает наработки обратно. Как следствие в коде отстутвуют проверки присутствия каких-то опций или наоброт отсутствия
их, зависимости между элементами не проверяются и код можно собирать только в том виде как он есть, без изменений и
только одим жестко определенным способом.
И разработки выглядят со стороны, как берется исходный код андроид, модифицируется разработчиком базовых чипов, распространяется с поддержкой этого чипа установленного в стандартной платформы разработки используемой для отладки решения. И как следствие, код с большой вероятностью имеет куски кода от других платформ, но без поддержки сборки на этих платформах или проверки сборки на этих платформах. Затем этот код модифицируется производителем устройства под свои потребности - с изменением аппаратуры и программной части под свои нужды, опять-таки без обращения внимания на совместимость с чем-либо кроме самого устройства. В результате появляются проблемы
описанные Линусом, когда отсутствует стандартные интерфейсы определения
конфигурации системы во время исполнения системы, так как реализация стандартного механизма усложнит аппаратную часть, а значит, приведет
к удорожанию разработки устройства в данный момент.
Такая же ситуация происходит и с другими частями системы, берется какая-то версия
программного обеспечения и модифицируется под какой-то конечный продукт и не обновляется из основного для продукта репозитория, и как результат, все части проверены как рабочие только в ограниченной экосистеме без взаимного обмена новшествами между
различными копиями изначально одного продукта.
Что имеет некоторую положительную сторону как проверенный годами стабильный продукт, с коллекцией ошибок уже давным давно исправленных в родственных продуктах или отсутствием каких-то приятных свойств, вида большая
производительность, новые виды поддерживаемых форматов или отображений. Сложность изменения или переноса каких то частей на другие
платформы, в любом из возможных смыслов, как другую аппаратную платформу, другой список оборудования, другое предназначение устройства
или использование программной части в другом окружение или с другим списком оборудования.
И сборка ядра сводится к поиску похожих устройств или упоминания нужного устройства в исходниках для других моделей на сайтах AOSP, Cyanogwwnmod, Aurora и попытках собрать ядро которое загрузится после сборки на устройстве если повезет.
Для сборки можно использовать такую последовательность команд:
- make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm menuconfig
- make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4
- fastboot boot bzImage
