Тачскрин драйвер для андроид

Тачскрин драйвер для андроид

Универсальный тачскрин для ГУ на Android
Автомагнитола и устройство на Android
Обсуждение »

ГУ : Тачскрин для ГУ на Android

— Поиск оригинального или совместимого тачскрина для своего ГУ на Android не увенчалось успехом, поэтому пришлось начать поиски решения даной задачи.
— В результате поиска было обнаружено несколько вариантов универсальных тачскринов, которые могут работать с ГУ по USB.
На этом ресурсе (4pda) не нашлось информации о подобных устройствах, поэтому решил создать тему с описанием универсальных тачскринов для тех пользователей, которые не могут найти для своих ГУ на Android оригинальные тачскрины.

[Полезное в этой теме]

Сообщение отредактировал ES. — 29.08.20, 12:54

Минусы:
— для Андроид драйвера имеются на сайте, но их можно встроить только в ядро (перекомпилировать ядро), что проблематично для большинства пользователей
— если встроить контроллер с тачскрином в ГУ под Андроид, то при сбое калибровки тачскрина будет необходимость разборки ГУ для подключения ноутбука с Windows, для проведения калибровки.

Вариант подключения этого тачскрина под Андроид от ABCh смотреть там: Подключение к Андроид
но у меня на 2-х девайсах такой вариант не запустился.

Сообщение отредактировал PauS — 24.01.18, 12:27

Плюсы:
— малогабаритная плата контроллера тачскрина с разъемом для 4-х проводного резистивного тачскрина
— в Android работа тачскрина в режиме мыши или дигитайзера
— нормальный софт для калибровки тачскрина под Windows по 4-м, 9-ти и 25-ти точкам касания
— плавная отработка касаний контроллером
— документацию и софт можно посмотреть там: http://www.microchip.com/wwwproducts/en/AR1100

Минусы:
— если встроить контроллер с тачскрином в ГУ под Андроид, то при сбое калибровки тачскрина будет необходимость разборки ГУ для подключения ноутбука с Windows, для проведения калибровки.

Сообщение отредактировал PauS — 13.11.17, 20:39

Плюсы:
— На данный контроллер тачскрина имеются исходники для контроллера
— тема по данному контроллеру находится там: http://pccar.ru/showthread.php?t=18943

Минусы для прошивки с сайта pccar.ru:
— происходит подергивание точки касания тачскрина из-за не совсем корректного алгоритма вычисления точки касания
— калибровка тачскрина проходит из под Windows и соединение с контроллером для калибровки происходит не всегда корректно
— при подключении к винде требует драйвер

Моя модификация прошивки для этого контроллера исправляющая некоторые минусы оригинальной прошивки:
Из-за этих минусов решил модифицировать прошивку:
— на светодиод «1» (см.фото) выведена индикация касания тача (есть касание — горит)
— удалил из прошивки весь код связанный с виртуальным портом, который нужен был для
калибровки из под винды, теперь винда драйвер не просит
— дописал код калибровки в прошивку. Вначале сделал калибровку по нажатию кнопки
на плате контроллера, но потом подумал и пришел к выводу, что это будет не очень
удобно, т.к. будет необходимость разбирать ГУ, чтобы нажимать кнопку для калиброки.
поэтому сделал без дополнительной кнопки.

Прошивки на Pro Micro только на 16 МГц :
Прошивка для Android: HID_Resistive_A_TouchController.zip ( 439.06 КБ )

Прошивка для Windows: TouchController_HID_Resistive_Windows.rar ( 400.79 КБ )

вот выкладываю получившуюся прошивку и кое что сопутствующее.
в архиве:
— TouchController_HID_Resistive_A.hex — моя прошивка контроллера для работы под Android
— 800_480.jpg — файл с расположением точек калибровки
— TC_REZ_01.jpg — внешний вид на чем проводилось тестирование
— Boot32u4.zip — архив с программатором для платы контроллера

Калибровка получилась может и не очень, но по мне нормально.

Калибровка тачскрина осуществляется по двум точкам расположенным в левом верхнем
и в правом нижнем углах смотри 800_480.jpg. Точки калибровки располагаются на
расстоянии 10% от длины и высоты (соответственно) дисплея. Сдвинуть точки
калибровки на 10% пришлось из-за конструкции тачскрина. мой в углах не работает.

Для первой калибровки, мне кажется, лучше сделать шаблон в размер вашего дисплея
из прозрачной пленки (кальки) с нарисованными двумя точками для калибровки.

Калибровка:
1. Наложить шаблон калибровки на экран дисплея (вывести на весь экран в Андроиде
картинку калибровки например 800_480.jpg).
2. Нажать и удерживать стилусом или другим предметом в любую точку экрана с
тачскрином. Светодиод 1 на плате контроллера (TC_REZ_01.jpg) будет постоянно светится.
3. Контролировать светодиод 2 на плате контроллера, примерно через 13 сек. светодиод 2
мигнет 1 раз, после этого отпустить стилус.
4. Нажать стилусом в точку 1 (левый верхний угол) и удерживать пару сек. пока не мигнет
светодиод 2, после этого отпустить стилус.
5. Нажать стилусом в точку 2 (правый нижний угол) и удерживать пару сек. пока не мигнет
светодиод 2, после этого отпустить стилус.
6. Нажать стилусом в любую точку экрана на пару сек.

Калибровка закончена, проверяйте работу тачскрина.

Контроль светодиодов в принципе требуется для определения правильности работы калибровки
и определения времени удержания стилуса во время калибровки, чтобы в последствии проводить
калибровку просто по времени.

Сообщение отредактировал PauS — 11.09.18, 09:37

4. Емкостной тачскрин. Коммерческий проект: Контроллер YAM_TOUCH_I2C_SIMPLE

предназначен для подключения по USB емкостных тачей со встроенным I2C контроллером от:
— FocalTech FT5206/FT5302/FT5306/FT5406/FT5606
— GOODIX GT801/GT811/GT911/GT927x/GT928
— Synaptics S7300B
— VTL CT363
— Atmel MXT1386

Источник

Замена драйвера сенсорного экрана в Android-ядре

Я адаптирую ядро ​​Gingerbread для своей пользовательской платы. Я пытаюсь заменить резистивный сенсорный экран, который использует встроенный контроллер ADC (процессор S5PV210 от Samsung). В моем дизайне мне нужен емкостный контроллер, поддерживаемый драйвером eGalaxyTouch. Он подключен к USB. Драйвер можно легко включить из меню «Сделать xconfig». Это работает, так как я добавил некоторые следы на последовательной консоли, и я вижу, как он устанавливается во время загрузки ядра, и я вижу, что он устанавливает и удаляет себя при подключении / отключении USB-кабеля. Но он ничего не делает в пользовательском интерфейсе Android. Это устройство типа HID. Проблема в том, что он не подключается к соответствующему слою программного обеспечения для сенсорного экрана Android. Должно быть, я что-то упустил. Должно быть что-то еще, чтобы вызвать, чтобы этот HID был подключен к другому программному уровню, управляющему сенсорным экраном.

Драйверы сенсорного экрана расположены в ядре / драйверах / вводе / сенсорном экране. Существует также некоторый код прямо в kernel / drivers / input.

Любые подсказки о том, как связать это HID-устройство с слоем сенсорного экрана Android? Я смотрю, как они сделали старый резистивный, и это не делается с помощью HID, потому что это «изготовленное на заказ» устройство с интегрированными в CPU АЦП, и это не происходит через USB.

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

Сначала удалите исходный драйвер сенсорного экрана, чтобы предотвратить конфликт (make xconfig)

Первоначально у меня был водитель, который не работает, хотя он был предоставлен производителем сенсорного экрана. Я решил попробовать драйвер сенсорного экрана eGalax уже в дереве ядра. Это драйвер модуля. Недостаточно включить «драйверы устройства модуля» в make xconfig. Да, это позволит скомпилировать файлы .ko. Но он не скажет сценарию здания, что делать с файлом.ko, и они не будут в конечном итоге работать с ядром в целевой системе. Таким образом, вам нужно принять меры, добавив материал в скрипт сборки или вручную скопируйте файл .ko в правильном расположении корней / модулей и добавьте загрузку модуля с помощью команды «insmod /modules/file.ko» в init. Rc-файл. Не забудьте установить правильную привилегию / modules и modules / file.ko с помощью команды chmod.

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

Источник

Как запихнуть свой сенсор в Android OS

Как-то раз программисты сидели и писали очередной температурный сенсор и программы с кнопочками. И вдруг оказалось, что этот сенсор хочет себе один небольшой производитель телефонов в будущей модели. Так образовалась задача поддержать I2C/GPIO сенсор на уровне Android OS, так как сенсор обещает быть неотъемлимой частью самого телефона.

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

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

Смотрим по порядку что тут есть:

1. Введение
2. Как железно подключиться к реальному девайсу типа планшет
3. Как подрубиться к дебажному UART в аудио выходе и обнаружить, что он не работает
4. Как написать несложный драйвер ядра с I2C, GPIO, прерываниями и фоновыми задачами
5. Как сделать абстракцию своей железки в Android middleware или использовать существующую
6. Как дописать свой системный сервис и куда чего добавить, чтобы он включился и нашёлся
7. Как прорваться через SEAndroid/SELinux дописав свои правила
8. Как проверить — напишем простой апп
9. Как это всё собрать
10. Как понять, что в предыдущих пунктах что-то не так

Введение

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

В поисках планшета выбор остановился на Nexus 7 по ряду произаческих причин: он был у знакомого и был ему не нужен, так как был достаточно сильно побит молью (моль разбила сенсорный экран и приходилось пользоваться мышью), но всё же это Nexus, а значит, по нему было больше информации и исходников на гугловских сайтах. Так как браться сразу за планшет было боязно, первым под замес попал Raspberry Pi3. Большая часть отладки произошла на нём. Далее рассказ не будет поминать Raspberry Pi 3, но в уме можно держать, что бOльшая часть программных проблем порешалась именно на нём.

Как железно подключиться к реальному девайсу типа планшет

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

По идее, в планшете должно быть достаточно много шин I2C и на порядки больше всяких GPIO, надо только найти нужные, припаяться и притянуться к нужному уровню. К нашему счастью, в планшетах Nexus 7 отсутствует задняя камера, которая как раз использует I2C для управления и два пина (питание и ресет). А нам и надо I2C и 2 GPIO (один для вкл/выкл спящего режима, а второй для прерывания на счёт нового измерения температуры).

Соотнесение реальных внутренностей и схемы показало, что всё не так просто, как в названии планшета. А именно, Существует минимум три версии Nexus 7:

1. Версия 2013 года не подходит к найденной нами схеме, так как имеет в себе другие процессоры и кучу отличающихся мелких деталей
2. Версии 2012 года .1 имеет распаянное посадочное место для задней камеры и всё в ней хорошо
3. Версии 2012 года .2 не имеет распаянного места и припаяться туда значительно сложнее.

У нас был планшет 2012 года, где не было готового разъема, и вдобавок разбитый touch и мышь в комплекте, что порою сильно доставляло. В итоге, после некоторых плясок с бубном вокруг да около, было решено купить другой такой же с распаянным разъемом. Новых Nexus 7 давно нет, поэтому искали на «базарах», что позволило заглянуть под крышку и выбрать нужный с распаянным местом под камеру.

Номер правильной шины I2C мы нашли простым перебором с помощью простецкой программы с использованием NDK. Для этого пришлось поставить рутованный Android и chmod колдовством через adb отпустить на волю все I2C шины. В процессе перебора пришлось немного поиграть с адресами на шине, так как некоторые из них были уже зарезервированы и мы получали отлуп при попытке коммуникации. В итоге, оказалось, что на целевой шине больше никого не было.

На первой же странице нашей схемы в общем обозрении видно, что есть камера под названием «Rear camera module OV5650».

Там же написовано, что она напрямую подключена к tegra T30L (т.е. главный SoC). Рядом есть линии I2C_CAM_… Поищем…

На странице 9 находится то, что нам нужно. Почти вся страница посвящена фронтальной и задней камерам. Там же есть упоминание, что у камеры есть два пина CAM_RST_5M и PWDN_5M, которые уходят в SoC на GPIO_PBB0 и GPIO_PBB5 соответственно. Кажется — это то, что нам надо. Только найти как туда припаяться, поэтому продолжаем искать…

Ну вот и всё. На этой странице описание FFC разъёма, куда включается камера, в том числе и искомые пины. На нашем изначальном планшете разъём не распаян. Но впоследствии мы найдем другой планшет с разъемом, дабы не мучаться.

Далее след найденных пинов возобновится уже в коде платформы и про это написано в части про драйвер…

Как подрубиться к дебажному UART в аудио выходе и обнаружить, что он не работает

Когда пишешь драйвера и всякое низкоуровневое ПO под линукс (крайне) желательно видеть лог загрузки ядра/системы, так как там загружается в том числе и наш драйвер. И как только что-то идет не так, всё прекращается и почему неизвестно.

Поэтому, покурив интернеты, мы разузнали, что Nexus устройства имеют дебажный UART выведенным через аудио разъём. И работает оно типа само безо всяких программных настроек таким образом:

• В аудиоразъеме по каналу MIC установлен компаратор, который реагирует на уровень более 3В.
• В обычном режиме, напряжение на MIC составляет 1.8В-2.9В.
• Как только уровень превышен, состояние передается на пин, который прерыванием говорит ядру, что на аудио разъеме теперь рулит дебаг.
• После этого левый и правый каналы становятся RX и TX соответственно, хотя и остаются на уровне 1.8В — потребуется преобразователь.

На радостях был сделан переходник USB-UART -> Audio. Мы его воткнули, включили в консоли Ubuntu minicom, загрузили планшет и… ничего. Вообще. То есть, совсем. Дальнейшие натурные поиски показали только то, что так или иначе, debug uart не включился, так как линии левого и правого каналов не вышли на нулевой уровень напряжения RX/TX. Также пробовали множество команд из fastboot, но ничего не помогло. Единственное, что успокоило нас в конце этой затеи — только информация, что еще один человек пробовал разные Nexus`ы, и на всех, кроме точно такого же планшета UART завёлся, а на нашем — нет. Но было интересно.

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

В итоге, нашим спасением стало предварительное использование Raspberry Pi для вместилища Android. Там дебажный порт работал, это позволило отловить все ошибки и дальше на Nexus было понятно что менять, если ядро не грузится. Статистика показала, что больше всего затяжек по времени было из-за непропаянных пинов GPIO, а также недокументированных особенностей tegra3 в плане разрешения работы с GPIO.

Кстати, для отладки интересно видеть полный лог загрузки, его можно получить c помощью adb bugreport.

Как написать несложный драйвер ядра с I2C, GPIO, прерываниями и фоновыми задачами

Итак, нужно было написать драйвер ядра, который будет рулить устройством через I2C и GPIO, а также отсвечивать в папке /dev каким-нибудь оригинальным именем, так что потом Android middleware сможет обратиться к этому файлу/драйверу и что-нибудь прочитать или записать.

Немного общих особенностей при написании драйвера:

• Драйвера загружаются в ядро цепочкой — устройства верхнего уровня (платформа, шины) загружают другие устройства (конкретные устройства и алгоритмы работы с ними).
• Цепочка и порядок загрузки определяются device tree или Си кодом загрузки, если device tree отключено при сборке ядра или не поддерживается ввиду старой версии ядра. Наш случай с tegra3 — второй.
• Для того чтобы подхватить структуру i2c клиента, через которую будет идти работа с I2C коммуникацией, нужно написать функцию probe, которая будет вызвана, если будет установлено соответствие устройства, описанного в коде начальной загрузки платформы и списке зарегистрированных драйверов, добавление которого мы вызовем с помощью функции i2c_add_driver.

Но сначала о предпосылках для загрузки драйвера. т.е. о коде инициализации платформы.

Nexus 7 2012 построен на процессоре Tegra3. Ядро на нем использовано не новое (3.1.ч.ч) и без device tree. А это значит, что всё железо описано Си кодом и находится оно в /kernel/tegra/arch/arm/mach-tegra/

Файл board-grouper-pinmux.c описывает железные конфигурации всех пинов SoC, а также содержит общие функции для их инициализации в закрытой части ядра от nVidia (все функции, начинающиеся словом «tegra» являются реализованы в закрытой части ядра, которая поставляется в бинарном виде). Посмотрим, что нам нужно там поменять

Файл board-grouper-sensors.c содержит регистрацию всяких разных устройств и наиболее общего уровня функции для них (например, управление питанием). Здесь же нам нужно добавить структуру для регистрации нашего устройства драйвером, который будет загружен как часть ядра. Как-то так:

Отдельно надо упомянуть файлы для сборки: KConfig и Makefile.

В KConfig допишем вот такой абзац, который по имени TRICKY_SENSOR (без префикса CONFIG_), созданному в Makefile, учтёт его при сборке. Также, наш драйвер станет виден при использовании make menuconfig.

В итоге, мы получаем следующие файлы для ядра:

Как сделать абстракцию своей железки в Android middleware или использовать существующую

Теперь переходим на уровень выше. Драйвер написан и теперь мы перемещается в user space часть Android, где надо как-то привязаться к драйверу.

Для того чтобы работать со многими реализациями однотипной периферии в Android есть слой middleware (написанный на С/С++), который содержит различные интерфейсы железных абстракций (Hardware Abstraction Level — HAL). И для всяких температурных магнитных и т.п. сенсоров там есть место. Но ограничением этого HAL является то, что его API подразумевает только чтение — что разумно ввиду множества пользовательских программ, которые могут одновременно доступаться к этим устройствам. И если одна поменяет настройки под себя, то для другой это будет подставой. Всё это очень хорошо описано здесь.

И конкретно в части read-only режима работы с сенсорами вот эта цитата из ссылки выше:

Besides sampling frequency and maximum reporting latency, applications cannot configure sensor parameters. For example, imagine a physical sensor that can function both in “high accuracy” and “low power” modes. Only one of those two modes can be used on an Android device, because otherwise, an application could request the high accuracy mode, and another one a low power mode; there would be no way for the framework to satisfy both applications. The framework must always be able to satisfy all its clients, so this is not an option.

There is no mechanism to send data down from the applications to the sensors or their drivers. This ensures one application cannot modify the behavior of the sensors, breaking other applications.

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

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

Для сборки модуля понадобится Android.mk файл, где написано такое:

И еще один Android.mk файл уровнем выше, чтобы включить собранную библиотеку в libhardware. Добавляем по имени ID модуля.

На выходе HAL имеем следующие файлы

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

Дальше надо чтобы наш HAL кто-то вызывал. В других частях OC такие вещи делаются с помощью системных сервисов и их менеджеров, которые написаны на Java. Дабы не выбиваться из ряда, напишем еще один. Сервис наш будет учавствовать в следующих файлах:

Как видно из исходников, мы еще не разобрались с уровнем native и подключаться к HAL модулю нужно через JNI. Заодно запилим свой ссылочный тип, который надо будет определить через AIDL, а потом прокинуть из C++ в Java.

Далее в onload.cpp загружаются все JNI части тех сервисов, которым это надо. В том числе, и наш.

Традиционный Android.mk содержит информацию для сборки всех частей, и наш JNI кусок тоже там.

Наш ссылочный тип должен быть создан при помощи AIDL, так как этот язык является средством межпроцессной пересылки данных в Android, да и не только в нем. Так же, для того чтобы его пересылать он должен быть Parcelable, что и показано в листинге дальше:

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

Теперь нужно добавить константу с именем сервиса, с помощью его сервис можно будет найти через context.getSytemService. Замечу, что в комментарии должна стоять пометка hide, иначе сборка не пройдёт, выйдя с сообщением, что такие имена нужно либо зарегистрировать официально в API, либо заныкать.

Чтобы сервис заработал, его надо включить в ServiceManager через SystemServer вот тут.

Чтобы сделать сервис доступным на стороне приложения, его менеджер надо добавить в context (в блок статической загрузки).

Сам registerService выглядит в Android 4.4.4 так:

Как прорваться через SEAndroid/SELinux дописав свои правила

Ну вот вроде весь код и написан, но только даже после успешной сборки работать ничего не станет, так как драйвер безраздельно принадлежит пользователю root, сервис не запускается, извергая в логи сообщения об отсутствии прав на запуск, а потом и на чтение запись чего-либо и, в итоге, профита нет. Необходимые права и правила надо прописать в части sepolicy.

Платформенно-зависимая часть скрипта init, который обрабатывает почти самый ранний запуск всей системы.

Пропишем также права и разрешения самого файла устройства в ueventd.

А вот дальше… надо написать всяких SELinux правил, чтобы наш сервис мог быть загружен системным сервером (куда мы его уже добавили в коде), а также правила, позволяющие нашему сервису читать и писать символьное устройство, коим является наш драйвер. Я основывался, в основном, на примерах из Brillo. Не уверен, что я проникся и понял всё, но попробуем по порядку:

Здесь мы создали новый домен для нашего сервиса, определили наше устройство и показали, что наш сервис имеет права на чтение и запись нашего драйвера. Конечно, написать это всё получилось далеко не с первого раза. После всего этого загрузка система, наконец, избавилась от сообщений о заблокированном сервисе, а в adb shell стало видно, что драйвер записан на имя пользователя system и открыт для мира.

Как проверить — напишем простой апп

Надо бы еще как-то проверить, что оно всё будет работать. Можно, конечно, и через adb shell пялиться в logcat, но не все почему-то рады такому результату, поэтому добавим в кастомную OC еще и встроенное приложение. Конечно, встроенное. Кому оно нужно, кроме этого планшета. В исходниках положим в packages/apps/TrickyDemo, а также в build/target/product/core.mk укажем его с списке предустановленных.

Для душевной простоты приложение написано в Android Studio (не забыть правильно выставить sdk — мы собираем под 4.4.4), а далее оторвано всё лишнее. А вот для сборки снова используется Android.mk, который у меня выглядит так.

Когда при сборке возникают ошибки неправильных библиотек или нехватки каких-то из них, смотрим в out/target/common/obj/SHARED_LIBRARIES и ищем подходящие имена.

Как это всё собрать

Теперь осталось только всё это собрать. Итак, параметры целевого устройства такие:

HW: Nexus 7 (2012 grouper)
OS: Android Kitkat 4.4.4 KTU84P
Kernel: tegra3_android_defconfig 3.1.10-gle42d16

Сначала собираем ядро.
Нужные исходники ядра тут:

Скачиваем нужный инструмент для сборки ядра отсюда:

Как собрать ядро (находясь в корневой папке ядра):

После копирования кастомных изменений в make menuconfig в разделе device drivers должен быть выбранный драйвер для Tricky temperature sensor (смотрим эту информацию с помощью menuconfig — команда выше). Собирается ядро быстро. После сборки полученный образ лежит в kernel/tegra/arch/arm/boot/zImage.

Дальше Android. Для сборки Android OS из исходников надо иметь достаточно могучий компьютер, чтобы не заскучать надолго, и много места на диске (вот тут подробно). В моем случае, сборка проходила на Ubuntu 14.04 LTS x64 (сборка на Windows не поддерживается вообще, если что).

Процесс установки необходимых пакетов хорошо описан здесь, так что на нём не останавливаюсь. Единственное, надо помнить, что для сборки разных версий ОС используются разные версии Java (для Android 7 это OpenJDK Java 8, для Nexus 7 и Android 4.x это Oracle Java 6).

Для настройки окружения перед сборкой Android читаем вот это.

Для скачивания исходников из репозиториев используем Repo — нахлобучка над Git, позволяющая работать сразу с множеством git-репозиториев (подробности установки тут). После установки Repo переходим в папку с будущими исходниками и выполняем это:

Процесс скачивания довольно долгий, так как скачано будет около 50Гб.

Далее скачиваем дополнительные бинарники от производителя (в корень папки с исходниками Android OS) для версии 4.4.4 KTU84P в нашем Nexus`е:

Распаковываем и извлекаем содержимое бинарников:

Удалить предыдущую сборку можно командой:

После сборки конечные образы будут находиться в папке out/target/product/grouper (system.img, recovery.img, ramdisk.img, userdata.img). Apk-файл приложения находится в out/target/product/grouper/obj/APPS/Jdts160demo_intermediates/package.apk.

Создание и заливка образа через fastboot. Создаем .zip-архив с образами, которые нужно залить во FLASH планшета (по умолчанию это boot.img, system.img, recovery.img, userdata.img, ramdisk.img), а также файлом android-info.txt с содержанием:

Если версия загрузчика по умолчанию не та, то можно скачать готовый Factory image образ отсюда и выполнить скрипт flash_all.sh из него. Его же можно использовать как базовый образ для заливки своих изменений.

Для обновления boot.img нужно установить тулзу abootimg:

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

Переходим в режим fastboot. Варианты:

adb reboot bootloader (если планшет включен, подключен по usb и авторизован adb)
если выключен, то включить, удерживая кнопки питания и громкость.

Проверяем доступность fastboot (usb подключен и usb debugging включен).

Далее выполняем список команд. Совсем необязательно удалять всё, можно только изменяемые части:

Как понять, что в предыдущих пунктах что-то не так

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

Изменения в ОС рекомендуется делать в папке devices/asus/grouper/. написанием множества overlays, а не напрямую в структуре ядра и ОС, которые будут учтены при сборке. Я так до конца и не выснил, можно ли там городить ту же структуру, что в основных исходниках, или есть какие-то определенные требования.

Консольный выход через audio-jack так и не заработал. Дальше после всего была перечитана статья, которая снова заронила ядро сомнения, что что-то было сделано не так. А именно:

• На схемотехнике упоминается uart-1 & uart-4 для debug, а в таблице pinmux соответствующие GPIO были в таблице not_used/disabled.
• Google не использует usb-uart FTDI для подачи нужного уровня на канал микрофона, так как там ограничение по току 50мА, чего может быть недостаточно.
• В make menuconfig можно включить uart отладку на любой из четырех uart`ов. Мы это делали, но не в купе с остальными пунктами.
• Еще были fastboot и bootloader опции и command line аргументы для консоли. Мы, конечно, попробовали не все варианты.

Не удалось создать своего пользователя в системе, чтобы назначить ему доступ к драйверу и сервису. Поэтому пришлось использовать system

Источник