Touch screen emulator android

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

Краткое описание:
Эмулятор сенсорного управления для использования любых USB/Bluetooth игровых контроллеров/геймпадов в играх с сенсорным управлением.

Описание:
Game Controller 2 Touch Pro — это наиболее функциональное, совершенное и простое в использовании премиальное программное обеспечение для Эмуляции Сенсорного Управления. Оно позволяет использовать для управления в играх на Android любые USB/Bluetooth Игровые Контроллеры/Геймпады путём Эмуляции Сенсорного Управления. Превратите любую игру с Сенсорным Управлением в игру с полной поддержкой Игровых Контроллеров. ПолучИте в своих играх управление с высокой точностью. Станьте Победителем в Онлайновых Баталиях. И многое другое.

ВАЖНО: ТЕПЕРЬ СОВМЕСТИМО С ANDROID MARSHMALLOW И ANDROID NOUGAT (с версии1.2.1). Требуются права пользователя root и наличие последней версии SuperSU. На Android 6.0+ установите Busybox.

Wireless & Wired Xbox 360 Controller
Wired PS4 Dual Shock 4
All iPega Controllers
All Logitech Controllers
All Moga Controllers including the New Moga Pro Power and Hero Power[HID MODE]
Nyko PlayPad/Pro
Ouya Controller
Mad Catz Controller
Samsung Gamepad
SteelSeries
nVidia Shield’s Gamepad
Wired PS4 & PS3 Controllers
Snakebyte iDroid
Green Throttle Atlas
G910
Some Fake Dual Shock 3.

ЗАМЕЧАНИЕ: PRO-версия Game Controller 2 Touch поддерживает гораздо большее число Контроллеров по сравнению с обычной версией. Данный выше список НЕ является исчерпывающим. Это всего лишь несколько Контроллеров, которые Разработчик имел возможность проверить лично.

Тщательно прочитайте Руководство Пользователя, FAQ и прежде чем размещать негативный отзыв, пожалуйста, обратитесь за помощью.

Требуется Android: 4.0+
Русский интерфейс: Нет

версия 1.2.7.3: Game Controller 2 Touch PRO (Пост Giacomino )
версия 1.2.4: com.catalyst06.gc2tpro_1.2.4.apk ( 7.68 МБ )

версия 1.2.2: Game Controller 2 Touch PRO (Пост IMixI #56043486)
версия 1.0.1: com.catalyst06.gc2tpro_1.0.1.apk ( 6.77 МБ )

Сообщение отредактировал iMiKED — 15.02.21, 18:17

Game Controller 2 Touch Pro 1.2.2
Что нового:
• Now compatible with Android Marshmallow & Nougat.
• Revamped UI & Graphics.
• Automatic Profile feature for Nougat.
• Dynamic Permission System implemented.
• Improved Swipe Mechanism.
• New Backend. No Custom Kernel Required.
• Fixed Crash when changing profile.
• Fixed Crash when tagging background image.
• Added Instructions regarding Controller Assignment.

Сообщение отредактировал IMixI — 09.01.17, 01:58

Источник

Джойстик и Android. Четыре способа играть кнопками на сенсоре

Приставка на Android

Радикально, смело, решительно. Именно так можно описать приобретение любой из нынешних приставок с ОС от Google. Их стоимость впечатляет, удобность находится под вопросом, но библиотека игр чрезвычайно внушительна. Для примера возьмём NVIDIA Shield, ласково прозванную в народе «шильдиком». Явными преимуществами этого устройства являются: хороший аккумулятор, отличный джойстик, агрессивная поддержка именитых разработчиков, включая Valve и TaleWorlds, собственный аналог Google Play, который можно скачать в самом Google Play, а также вещь, которая обеспечит комфортную игру даже в самом требовательном проекте — охлаждение. К недостаткам относятся: факт, что по консоли нельзя звонить, и приходится иметь два устройства (Shield и телефон) вместо одного, что неудобно, непомерно высокая цена, особенно для сегмента рынка в СНГ, и малое количество действительно сочных эксклюзивов. Хотя уже те, что есть, обеспечат игроку незабываемые впечатления.

Цена вопроса с доставкой: $388,3

Подходит для: настоящих фанатов мобильных игр, верящих в прогресс

Однако не шильдиком единым, как говориться. За несколько лет китайцы наловчились вставлять Android во все щели, куда он способен поместиться. А возможность заработать на консолях привела к тому, что компании вроде JXD породили целый сегмент своих устройств. Видели когда-нибудь PSP на Андроиде? А Wii U? Понятное дело, что это лишь форм-фактор, но впечатление всё равно производится очень солидное. Да и цена у топовых моделей будет ниже того же Shield раза в два. За это приходится платить отсутствием охлаждения, отсутствием поддержки со стороны разработчиков, нестабильным качеством и далеко не топовой начинкой. К явным плюсам запишу просто феноменальные возможности эмуляции — некоторые модели обладают поддержкой игр с 12 (!) платформ, включая PSP, PS1, GBA, NeoGeo (привет SNK Playmore), и я не буду говорить, что на Shield можно установить всё это и даже больше, потому что из коробки оно недоступно. Также у большинства имеется ещё фотокамера, что есть сомнительный, но имеющий место плюс.

Цена вопроса: от 3 до 6 тысяч рублей

Подходит для: желающих иметь собственную приставку, сэкономить, получить PSP-lookalike на Android

JXD V5200. Источник — aplaymart

Игровые джойстики

Ну это вообще отдельная песня. Разнообразие моделей не так велико, как хотелось бы, но плюсов у подобных устройств хватает. Для примера возьмём MOGA — беспроводной джойстик с креплением для смартфона. Цена такого чуда не превышает $100, универсальность решения зашкаливает, так как его хоть к смартфону на Android можно прицепить, хоть к iPhone/iPod, хоть куда угодно. Удобность тоже на высоте, батарея держит долго, претензии к начинке не предъявляются, так как всё зависит от смартфона. Но если сравнивать с шильдиком, есть всё-таки пара недостатков. Ни в одном современном смартфоне нет активного охлаждения, эксклюзивы тоже из воздуха не возьмутся. Да и система крепления, пускай и надёжная, как плоскогубцы, но всё же вызывает определённые сомнения. Кроме того, планшет на них не закрепишь, хотя никто не мешает поставить его на подставку, используя MOGA в качестве следующего клиента. Помимо MOGA есть ещё ipega 9017, чья нелюбовь к процессорам MTK невыразима цензурно, G910 и Samsung EI-GP20. Есть ещё красавец Defender Mobile Master, но его сложно найти.

Цена вопроса: до $100

Подходит для: всех любителей мобильных игр с устройством среднего класса и выше

Что касается просто беспроводных джойстиков, то тут дела немного похуже будут. Стоят они ещё меньше, но никак не поддерживают смартфон/планшет, посему смартфон нельзя уже рассматривать, как полноценную замену приставке. Но универсальность таких устройств очень высока, так как они идут в обход разъёмам и проводам, подключаясь ко всему, что поддерживает беспроводные технологии. Компьютер, консоль, планшет, ноутбук — Bluetooth-контроллер себе место найдёт! В эту же категорию мною будет включена и OUYA, так как ей тоже не нужны провода для работы, хотя это и полноценная консоль, и беспроводная периферия для компьютера — мышки да клавиатуры, которые, впрочем, на цену вопроса не повлияют.

Цена вопроса: до 1700 рублей (джойстик для OUYA)

Подходит для: любителей поиграть дома и тех, кто уважает универсальность

OUYA Controller. Источник — ouyaforum

Проводные джойстики

Господа, вот мы и вышли к берегу моря. Необъятного, бесконечного и бесконтрольного. Я о том, что количество моделей, которые можно присоединить к смартфону с OTG, не поддаётся описанию в трезвом виде. Серьёзно, из десятка компаний, производящих игровую периферию, хорошо если пара не занимается выпуском джойстиков на серьёзном уровне. Качество такого продукта вальяжно плавает от «никогда больше не отпущу этот шедевр» до «пластмасса растаяла от тепла рук», а стоимость я даже пытаться расписывать не буду. Преобладающий интерфейс разъёма, понятное дело, начинается на U и заканчивается на B (три буквы, попробуйте угадать), а если нет, то переходники в помощь. Среди недостатков проводных джойстиков я упомяну, пожалуй, неудобность в работе (провод любит путаться), зависимость в OTG — как-никак, а технология относительно редкая, а также необходимость настраивать значение кнопок для каждой игры. Эта же беда касается беспроводных джойстиков, кроме, наверное, MOGA, мышек, клавиатур и прочей периферии ввода.

Цена вопроса: от 100 рублей

Подходит для: любителей поиграть дома, любителей проводов, любителей воевать с настройками, желающих сэкономить кучу денег

Источник

Touchscreen Repair 5.2

(Ремонт сенсорного экрана)

Скачать

Тут вы можете скачать АПK-файл «Touchscreen Repair» для Андроид бесплатно, апк файл версии — 5.2 для загрузки на ваш андроид просто нажмите эту кнопку. Это просто и безопасно. Мы предоставляем только оригинальные апк файлы. Если какой-либо из материалов на этом сайте нарушает ваши права, сообщите нам

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

ФУНКЦИИ
-> Ремонт вашего сенсорного экрана, удаляя сенсорные лаги и улучшая вашу отзывчивость сенсорного экрана.
-> Упрощает ввод текста на клавиатуре.
-> Уменьшает время отклика сенсорного экрана.
-> Простой и быстрый процесс.
-> Легкий вес apk. Нет нежелательной графики.

КАК РАБОТАЕТ СЕНСОРНЫЙ РЕМОНТ?
Восстановление сенсорного экрана занимает 4 значения времени отклика от 4 частей вашего сенсорного экрана. 3 таких образца взяты для лучшей точности. Основываясь на этих значениях, приложение рассчитывает сокращенное, единообразное время отклика и применяет его к сенсорному экрану на стороне программного обеспечения.
Вот как приложение восстанавливает ваш сенсорный экран.

Источник

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

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

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

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

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

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

Введение

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

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

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

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

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

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

Версия 2013 года не подходит к найденной нами схеме, так как имеет в себе другие процессоры и кучу отличающихся мелких деталей
Версии 2012 года .1 имеет распаянное посадочное место для задней камеры и всё в ней хорошо
Версии 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 под линукс (крайне) желательно видеть лог загрузки ядра/системы, так как там загружается в том числе и наш драйвер. И как только что-то идет не так, всё прекращается и почему неизвестно.

Читайте также: Apple tv plus android

Поэтому, покурив интернеты, мы разузнали, что 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 включен).

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

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

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

Консольный выход через 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

Источник