Несмотря на незаурядное название, наверняка многие олдовые читатели моего блога будут рады видеть статью в «старом» формате с оживлением и попыткой использования чего-то очень дешевого, грязного и нерабочего. В процессе подготовки подробного материала о том, как работали 2D игры на телефонах из прошлого, я не терял времени и искал различные интересные девайсы на онлайн-барахолках «за копейки». Так уж получилось, что на моей карте осталось 60 рублей, ещё 250 рублей задонатил читатель и я увидел её: Android-игровую консоль «на запчасти», которую мне удалось забрать всего за 300 рублей. Сегодня мы с вами: поговорим, есть ли смысл брать дешевые консоли на Android, во всех подробностях отремонтируем и отреставрируем нерабочий, грязный девайс «из подвала» и проведем бенчмарки эмуляторов, дабы понять — реально ли получить игровую консоль по цене шаурмы. Интересно? Тогда жду вас под катом!
❯ Предисловие
Друзья! Если вы хотите не только читать, но и смотреть, то для этой статьи доступна видео-версия. А те, кто любят читать текст - листают вниз!
Пожалуй, тематика портативного гейминга была актуальна всегда. Ещё в нулевых, многие мои читатели наверняка уже играли на своей личной игровой консоли: будь это тетрис, полноценная PSP, а то и редкая в СНГ Nintendo DS! С резким падением цены на дисплеи и относительно мощные чипсеты, китайские производители начали делать огромное количество своих собственных консолей. Но понятное дело, что в одиночку запускать собственную платформу без игровой библиотеки смысла нет и поэтому китайские вендоры решили поступить проще всего: они портировали эмуляторы NES, Sega Mega Drive и иных популярных консолей из прошлого и просто устанавливали пиратские ромы в подобные устройства. Одной из самых популярных ретро-консолей, которая в своё время произвело фурор на рынке портативного гейминга была известная в узких кругах Dingoo A320, которая стоила копейки для того функционала, который она предлагала (менее 100$ на релизе в 2009 году).
Та самая Dingoo A320 в форме кирпичика
Казалось бы, чем же могла быть интересна самая обычная, «стандартная» дешевая игровая приставка с кучей ретро-игр? И ответ прост: тем, что ОС устройства поддерживала запуск сторонних приложений, а производитель умудрился поделится (или слить, обычно такие вещи под NDA разработчика чипсета) исходный код прошивки устройства и SDK для разработки нативных программ для этой консоли. Стоит ли говорить о том, что энтузиасты сразу принялись портировать популярнейшие игры с открытыми исходниками и множество эмуляторов? Но настоящий успех к этой консоли пришёл лишь спустя год, когда энтузиасты портировали… полноценный Linux на это устройство и библиотеку SDL1.2, дав возможность запускать вообще любой софт, собранный под MIPS для Linux. Конечно-же, на волне популярности со временем у консоли появились и свои клоны, не имеющие отношения к Dingoo A320.
Спустя время, даже корейская Ritmix решилась выпустить RZX-50 на том-же чипсете, что и Dingoo A320 и сразу с Linux на борту, а хабровчанин, нынешний администратор форума «MotoFAN», под ником exl даже работал над разработкой и выпуском этого устройства в РФ! Благодаря дешевизне, такие игровые устройства раскупали как горячие пирожки себе или детям, создавая отдельный рынок дешевых ретро-консолей. Вплоть до того, что в 2012 году появилась первая игровая консоль на перспективной ОС Android — JXD S601 и всего чуть больше, чем за 100$!
В подарке читателя затесался RZX-50!
Идея китайцев была простой: они взяли дешевое, но относительно неплохое железо для планшетов и просто приделали ему аппаратные кнопки, проще уже не придумаешь! Многие Android-игры уже тогда поддерживали управление физическими кнопками (поскольку в те годы ещё выходили QWERTY-смартфоны, например HTC Desire Z), не говоря уже об эмуляторах, из-за чего, по мнению производителей, такие девайсы должны были сметать с витрин учитывая копеечную цену устройств. И в целом, так и происходило: со временем, некоторые бренды в РФ начали называть такие консоли своими именами и продавать в салонах сотовой связи за цену несколько выше, чем в Китае…
Я уже восстанавливал похожий девайс практически ровно год назад!
Помимо этого, JXD даже заморочились и реализовали свой собственный «магазин»… пиратских ромов! Да, в отдельном приложении можно было скачать нелегальные образы игр и сразу же закинуть их в папку эмулятора… Таким образом, получался «топ за свои деньги» тех лет. Покупаешь одновременно и игровую консоль, и планшет, из-за чего для рядового пользователя покупка подобного девайса была весьма неплохим решением: и дитю поиграть, и самому юность в играх для ретро-консолей вспомнить.
Продержались подобные устройства на рынке примерно до 2015 года. К сожалению, в таких консолях было слишком много недостатков и их нужно было вручную доводить до юзабельного состояния, как это часто бывает с дешевыми устройствами: например, многие вендоры почему-то реализовывали аналоговый стик как цифровой (!) в системе, прошивка очень часто была крайне лагучей и страдала от отсутствия оптимизации, а силиконовая токопроводящая резинка для кнопок быстро изнашивалась и кнопки имели уже далеко не такой плавный и мягкий ход как в новом устройстве. К слову, похоже рынок игровых консолей на Android понемногу возвращается: пару лет назад появилась консоль от Anbernic, в которой пофиксили эти недостатки и бонусом снабдили устройство нормальным OLED-дисплеем и чипсетом Unisoc, но цена в 15 тысяч рублей за Android-смартфон с кнопками наверняка вас отпугнет (это реально очень дорого).
Отпугнула и меня. В моей юности у меня тоже была подобная консоль на Android и я, оказавшись в один прекрасный день с 60 рублей на карте, начал листать онлайн-барахолки в поиске чего-нибудь интересного в пределах своего города. И нашёл: некий мужик продавал за копейки устройства на запчасти, среди которых оказалась и моя консоль: JXD S601.
Я предложил 300 рублей, продавец согласился, читатель задонатил ещё 250 рублей на контент и я выкупил консоль в абсолютно неизвестном состоянии, которая оказалась ещё грязнее, чем было на фото. Тем и интереснее!
❯ Реставрируем
Как я уже говорил выше, консоль я купил в совершенно непонятном состоянии: грязная, слишком легкая, резистивный тачскрин был в пузырях, а кнопка триггера вообще не работала. Кроме того, внутри консоли что-то болталось, но и мы не из робкого десятка и готовы отреставрировать старенькую консоль! Разбирается она очень просто: четыре винтика с обратной стороны консоли и расщелкиваем заднюю крышку пластиковой картой. Правда в моем случае, все винты были закисшими и зализанными, но главное что клипсы задней крышки не пострадали.
Разобрав консоль, я увидел вот такую картину (скриншот из видео): кто-то менял аккумулятор, просто припаяв новую банку к старой BMS без изоляции прямо поверх конденсаторов на линиях питания процессора. Само собой, это не дело, благо у меня был аккумулятор такого форм-фактора. Я выпаял остатки BMS и уже подготовил новый АКБ для подкидывания.
Что было особенно неприятно — прошлый мастер потерял динамик и оторвал полностью камеру с шлейфом:
Упомянутая мной кнопка продолжала болтаться по корпусу и её умудрились выломать даже при том, что она сидела с завода на герметике. Видимо уж очень активно её нажимали. Ну, это поправить несложно: убираем припой с посадочной площадки кнопки, вставляем её пинами вниз и припаиваем. Теперь кнопка держится надежно!
Затем я очистил спиртом контакты кнопок и пробрызгал WD'шкой стик и пошёл набирать воду в тазик, дабы отмыть корпус от грязи. После мытья корпуса, я просушил его феном. Перед финальной сборкой консоли, я решил проверить плату на работоспособность, подключив дисплей и подпаяв питание и…
Да, даже дисплей оказался разбитым :( Но и это не беда, ведь в таких консолях используются экранчики от… навигаторов! Подкинув новый дисплей и убедившись что плата рабочая, я принялся собирать всё обратно…
Но не тут-то было! Консоль оказалась на пароле и очень сильно тормозила, каждое действие занимало ~5 секунд. Ну, тут уже и причина разбитого дисплея очевидна: видимо консолью пользовался ребенок, который психанул от лагов и разбил замечательный девайс. Благо фиксится легко: качаем прошивку, распаковываем в корень MicroSD-флэшки, включаем консоль нажатием «Питание + Меню» и ждём окончания процесса прошивки.
Наконец-то консоль снова в рабочем состоянии! Ремонт обошелся мне… ну, можно сказать 100 рублей за навигатор. Сейчас они вообще никому не нужны и стоят копейки… На ремонт я потратил где-то час своего времени — не так уж и много, зато фана от восстановления достаточно :)
Давайте же посмотрим, на что способна консоль по прямому назначению — в играх!
❯ Тесты
Как я уже говорил выше, фактически подобные консоли — это планшеты с аппаратными кнопками. Само собой у них есть и Wi-Fi, что позволяет их использовать как бюджетный планшет из начала 2010-х годов… например, накатить клиент ВК и YouTube, заюзать встроенный клиент-почты или использовать консоль как плеер.
Запускаем CPU-Z и видим, что характеристики у нашего девайса следующие:
Чипсет: AMLogic AML8726-M3 с одним ядром Cortex-A9 на частоте 600МГц. В качестве GPU используется Mali-400MP.
ОЗУ: 512Мб DDR3.
Flash-память: NAND-модуль на 4Гб.
Дисплей: 4.3", 480x232, TN. Резистивный тачскрин, само собой на одно касание.
Система: Android 2.3 с возможностью апгрейда до 4.0.
Видеовыходы: аналоговый TV-Out.
Для подобного устройства весьма неплохо! Уж, полагаю, подобных характеристик должно хватать и для достойной эмуляции PlayStation 1. Давайте проверим!
Начинаем с самого простого, конечно же NES: я использовал эмулятор emu.NES, настройки стандартные. Эмулятор сразу же подхватил аппаратные кнопки, всё работает шустро и без проблем:
Переходим к Sega Mega Drive, в этом случае я использовал эмулятор emu.MD. Ром «соника» запускается и работает шустро, без каких-то особых проблем или фризов. Но возможно, для кого-то окажется слишком большим инпут-лаг — тут всё сильно индивидуально.
Дальше — больше, переходим к эмуляции PS1. В качестве игры я выбрал Driver, эмулятор epsxe: игра идёт довольно неплохо, в почти стабильные 25-30 кадров. Не все современные консоли с алика могут позволить себе подобный уровень производительность в 3D играх на PS1!
И не забываем, конечно-же, о нативных играх! Здесь тоже всё весьма шустренько: можно погонять в Android-классику тех лет типа Temple Run и иную мобильную годноту тех лет. Ностальгия!
❯ Заключение
Вот такую игровую консоль я купил за 300 рублей. Да, многие читатели скажут, мол, твоё время и затраты на поиск подходящего дисплея это ещё плюс пару тысяч рублей… но лично мне в кайф было пополнить свою коллекцию консолей ещё одним рабочим устройством. Надеюсь и вам было интересно!
Если захотите поискать такие устройства на барахолках по дешману, то найти их можно по названиям брендов (func, exeq, spider) и по описанию (android консоль, android приставки и т. п.). А если вам интересна тематика ремонта и моддинга различных дешевых девайсов, в том числе и телефонов, программирования, DIY — то подписывайтесь на мой Telegram-канал, в котором есть ламповый чат!
Интересно?
Была ли у вас похожая консоль?
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Моддинг-сцена с разработкой и портированием кастомных прошивок для Android-устройств существует вот уже более 10 лет. В основном, энтузиасты пытаются проапгрейдить свои устройства путем портирования более свежих версий Android, чем предлагает производитель девайса. Чего уж говорить, если Galaxy S III, которому уже 12 лет стукнуло, получил неофициальный апгрейд до Android 14. Порой мне в голову приходят различные, весьма странные моддерские мысли: например, почему бы не портировать на старенький смартфон… ещё более старую версию Android, дабы посмотреть «что будет». Казалось бы «портировал и портировал», но в процессе работы я столкнулся с множеством интересных нюансов и особенностей работы Android, о которых хотел бы рассказать и вам — моим читателям! Сегодняшняя статья будет в классическом «научпоп»-стиле без кода, зато с подробными объяснениями одной из техник портирования Android-прошивок путем патчинга скриптов для конфигурации системы и подмены Board-specific библиотек, дабы система «увидела» всё необходимое железо! Интересно? Тогда жду вас под катом!
❯ Мотивация
У меня, как и у многих моих читателей, одной из первых версией Android в жизни была 2.x. Наверное, я уже никогда не смогу забыть первые впечатления от использования своего новенького, пусть и бюджетного и слабого Android-смартфона после простеньких китайских кнопочников. Эти ощущения были прекрасными: вот я разблокирую смартфон, потянув «замочек» вправо, свайпаю рабочие столы и тапаю на значок приложения браузера, выполненный в стиле скевоморфизма, загружаю полноценную страницу Википедии через GPRS-сеть (мой первый смартфон не имел 3G) и плавно скроллю страницу, не забывая смахнуть шторку вниз и проверить статус уведомлений в пока ещё совсем простенькой панели нотификаций… Это были по настоящему ламповые впечатления, которые не смог превзойти ни один современный девайс: ни AOSP, ни MIUI, ни OneUI.
Моим первым смартфоном была китайская реплика Samsung Galaxy S III Mini, купленная в самом начале 2013 года. Возможно, кто-то из вас помнит, как подобные дешевые смартфоны и планшеты «Sumsanc» можно было купить на рыночных развалах, в метро и прочих местах, где допускается торговать несертифицированными гаджетами. Даже с учётом накрутки, эти смартфоны стоили всего 2 000 рублей, что было просто «подарком» для цены абсолютно нового гаджета. Девайс был крайне простым для начала 2013 года и имел следующие характеристики:
Процессор: Spreadtrum SC6820. Одно ядро Cortex-A5 на частоте до 1ГГц, Mali400 MP в качестве GPU. Чипсет был крайне высоко-интегрированным для своих лет: в одном корпусе располагалось ARM-ядро, GPU, контроллер питания, GPS, множество периферии (например, DAC), а также Baseband-часть GSM-радиотракта. BT/Wi-Fi реализовывались в отдельном комбочипе разработки RDA.
Память: 256Мб DDR1 ОЗУ/256Мб NAND-памяти в одном чипе eMCP от Hynix. Предположительно, эти чипы остались на складах ещё со времен первых Android-смартфонов, но очень быстро потеряли актуальность и их, вероятно, отдавали «за бесценок» что позволило ещё сильнее снизить цену производства таких смартфонов.
Дисплей: безоговорочно, TFT, обычно с разрешением не выше 480x320, что для 3" дисплея было нормальным, но для 5" — уже несколько маловато. Тем не менее, сами дисплеи были нормальными и глаза от них не «вытекали». Тачскрин обычно ёмкостной, на 2 касания.
Android: 2.2, на некоторых похожих моделях встречался 2.3.
Аккумулятор: ~1.500мАч, не больше. По форм-фактору напоминает BP-4L, без проблем подходит от многих S60 смартфонов Nokia тех лет.
Не густо, да? Уже в апреле того же года вышел Galaxy S4 с Snapdragon 600, 2Гб ОЗУ и 32Гб встроенной памяти, а мы тут с одноядерным чипсетом и 256Мб ОЗУ сидим. Но мне, будучи школяром, это было за счастье — чего я на нём только не делал, и на PHP какие-то WAP-сайты динамические пытался писать и на FTP заливать, и даже ADT Bundle скачал, дабы попытаться что-то своё запилить под собственный смартфон! В общем, я был счастлив, несмотря на лаги девайса. Именно того девайса у меня уже давным-давно не осталось… но память я всё ещё храню и стараюсь дать новый дом таким китайчикам, которые в большинстве своем оказались на свалке истории в новом мире современных смартфонов!
Но на самом деле, смартфоны 10+ летней давности могут быть интересны и своим форм-фактором: в современном мире едва ли можно найти хоть какие-то телефоны с полноценной QWERTY-клавиатурой (исключение — смартфоны UniHertz, которые стоят недешево) и уж тем более, боковые слайдеры. Поэтому мой интерес к подобным девайсам очень легко объяснить!
Однако, порой мне самому хочется снова пережить эти эмоции и ещё раз походить с подобным девайсом «на каждый день», даже когда на Android 2.2 особо никакие сервисы уже не работают. Отчасти, я решаю свои проблемы сам и пишу клиенты нужных мне сервисов, если они действительно нужны, дабы рано или поздно всё таки вдохнуть новую жизнь в «старенькие» девайсы. И казалось бы, это можно списать на синдром утёнка и банальную ностальгию, но мои ощущения «ламповости» отнюдь не мимолетны и всё равно меня тянет именно на те смартфоны, с тем самым интерфейсом, которые я когда-то увидел впервые!
Пожалуй, сказать что я решил портировать старый Android на отнюдь не новый смартфон «просто так» было бы ложью. Я всё ещё верю в то, что смогу в одиночку хотя бы частично вдохнуть новую жизнь в эти девайсы и позволить им работать с современными сервисами, дабы они могли приносить пользу не только мне, но и другим людям, которые намеренно занимаются дауншифтингом или вынуждены сидеть на девайсах с старыми версиями Android! Сегодняшним нашим подопытным станет один из представителей подобных noname-смартфонов тех лет, реплика Galaxy S III Mini на том самом железе, на котором работал мой первый смартфон. Однако с завода на нём стоял Android 2.3 — слишком свежая, по моему мнению, версия системы, которую я конечно-же захотел откатить до Android 2.2!
Задача облегчалась тем, что смартфоны на этом чипсете с Android 2.2 уже выходили, что позволило мне портировать прошивку путем несложных патчей скриптов инициализации и копирования Platform-specific файлов, дабы завести все необходимые для смартфона модули. А поскольку о таком простом способе портирования свежих и старых прошивок знают далеко не все мои читатели — я решил написать об этом отдельный подробный материал! Давайте же перейдём к практической части нашей статьи.
❯ Первые шаги
Перед тем, как начать портирование системы, нам необходимо разбираться в том, как вообще происходит процесс загрузки Android и какие процессы при этом загружаются. Вкратце, описать весь процесс загрузки можно так:
Загрузчик: при включении смартфона, первичный загрузчик BootROM, аппаратно-прошитый в чипсет ещё на этапе изготовления чипа, инициализирует некоторую периферию, загружает вторичный загрузчик из NAND (коим может быть SPL — Second Program Loader, занимающийся инициализацией контроллера DDR и UART) и передаёт ему управление. Вторичный загрузчик в свою очередь передаёт управление U-Boot — в задачи которого входит также инициализация периферии, обработка устройств постоянной памяти (например, NAND или контроллер SD), загрузка ядра Linux и конфигурация самого процесса загрузки. U-Boot можно считать эдакой альтернативной UEFI/BIOS в мире не-x86 устройств. В смартфонах на базе чипов MediaTek и Qualcomm, роль U-Boot выполняет LK — маленькая ОС, в задачи которой входит инициализация периферии и передача управления ядру Linux с помощью программы aboot.
Ядро Linux: после загрузки образа ядра с initrd (небольшая файловая система, которая загружается сразу в память и содержит в себе скрипты для конфигурации всего остального) и передачи управления ядру, Linux начинает выполнение программы с PID 0 — /init, в задачи которой входит выполнение скриптов инициализации userspace-окружения системы в init.rc. При этом смартфон уже фактически готов к работе — в одной из своих статей я показывал, как можно приостановить загрузку Android и выполнять свой код, используя все ресурсы смартфона для своих целей.
zygote и app_process: помимо запуска необходимых для работы смартфона служб, динамической загрузки драйверов (с помощью insmod) и определения режима загрузки (например, если телефон подключили выключенным к зарядке — необходимо показать анимацию этой самой зарядки), init.rc запускает две программы, одна из которых необходима для функционирования системы. Первая — это bootanimation, которая проигрывает анимацию включения смартфона и app_process, который в одном из режимов работы превращается в zygote — самый важный процесс для работы Android, который предварительно при старте системы загружает системный Java-байткод, отвечающий за отрисовку интерфейса, проигрывание звука и т. п. из framework.jar и другие системные ресурсы (например темы и изображения), а затем при запуске каждого приложения просто клонирует сам себя (с уже загруженными ресурсами) и начинает выполнение байткода любого запущенного Android-приложения или службы.
Каждое запущенное приложение или служба — это отдельный app_process, в том числе и лаунчер, и Google-сервисы и клиент любого мессенджера.
Всё выглядит просто и логично, не так ли? Подытожив, можно сказать что для того, чтобы система минимально стартовала, нам необходима подходящее ядро для нашего устройства, рабочий init.rc и адекватно запускающийся init.rc. Кроме того, Android зависит от некоторых платформо-специфичных библиотек: в основном, они находятся в /lib/hardware и без них система может не запуститься или что-то может не работать. Особенно осторожно надо подходить к libhardware.so.
Как я уже сказал выше, прошивку мы будем портировать от другого смартфона на том-же чипсете и что забавно — такую же реплику, просто более-раннюю! «Из коробки», мой смартфон работает на Android 2.3, значительно более стабильной, чем изначальный порт 2.2 на эту платформу. Отличий 2.3 от 2.2 достаточно: например, на 2.2 совсем иной цвет шторки, по умолчанию стоит Light-тема, нельзя закрывать уведомления смахиванием и в целом система несколько отличается внешне. Для работы нам нужно будет два образа прошивки: ту, которую будем портировать и та, которая стоковая. Прошивки в смартфонах на платформе Spreadtrum распространяются в формате pac, однако нет никаких проблем подменить образ раздела в ResearchDownload — фирменной утилите для прошивки смартфонов на этом чипсете.
Я решил взять прошивку от FeiTeng N9300 Mini, родная для моего смартфона — M-Horse 9500 Mini. В случае моего девайса, разметка и список разделов между устройствами никак не отличалась, поэтому изначально я напрямую прошил раздел system.img, дабы посмотреть что будет с устройство. Не забывайте, что ядро и init.rc хранится в образе boot.img — поэтому прошивка раздела system безопасна!
❯ Первый запуск
После прошивки чужого раздела system, смартфон стартовал… однако работал несколько странно: во первых, у нас не было сети, во вторых не работал тачскрин (при родном то ядре), а в третьих, Android ни в какую не видел аккумулятор, вися на 0% и моментально отключаясь, если смартфон не стоит на зарядке, а при попытке воткнуть кабель — смартфон показывал индикацию зарядки, но потребление было на нуле.
Поскольку тачскрина у нас нет, root доступ через adb придется включать «ручками» — для этого нам необходимо перепаковать наш родной раздел boot. Для распаковки и запаковки образов, я пользуюсь MtkImgTool — весьма удобная «кухня» для работы. Вытаскиваем boot.img из pac, закидываем в Unpack/Image/ и распаковываем с помощью Boot -> Unpack -> boot.img
В Unpack/boot/ramdisk/default.prop нам необходимо изменить ro.debuggable на 1, а ro.secure на 0. Это даст возможность отлаживать устройство даже если Android фактически не загрузился.
Теперь у нас есть root-консоль устройства, даже если смартфон висит на заставке. Прошиваем обратно образ, пишем adb shell в консоли и смотрим, что же тут не так… Вообще, драйвер тачскрина обычно статически слинкован с ядром, но в случае устройств Spreadtrum — они вынесены в динамические модули ko, которые можно найти в папке /lib/modules/, либо /sps/. Давайте глянем init.sp6820a.init.3rdparty.rc, который отвечает за специфичную для этой модели смартфона инициализацию.
Ага, видим insmod gt868.ko? Это команда загрузки драйвера тачскрина, в нашем случае — это вышеупомянутый GT868. Иногда встречаются другие модели тачскринов, но главное отличие прошивки 2.2 от 2.3 — разные названия папок с драйверами и некоторые службы. Достаём из родного образа драйвер gt868.ko, используя всё тот-же MtkImgTools, распаковывая его как обычный ext2 раздел:
И наслаждаемся тем, что у нас теперь появился тачскрин! Android сам подхватил новое устройство ввода, поскольку драйвер тачскрина — обычное устройство в /dev/input/. Чтобы драйвер грузился при загрузке, его достаточно добавить в init.sp6820a.3rdparty.rc, предварительно закинув в раздел /system/. Перед этим, раздел нужно перемонтировать для возможности записи:
После модификации rc-скрипта, нужно обратно запаковать boot.img с помощью MtkImgTools и прошить его с помощью ResearchDownload — тачскрин будет работать даже после перезагрузки!
❯ Поднимаем зарядку и сеть
Переходим к отсутствию связи с аккумулятором и нулевым потреблением АКБ. Здесь мне пришлось несколько покопаться и почитать логи ядра с помощью команды dmesg. Я обратил внимание на то, что некая служба пишет что-то об аккумуляторе, но разобраться было несложно: в папке /system/bin я нашёл программу charge, которая, очевидно, отвечает за настройку КП для старта зарядки. Что она точно делает — мне неизвестно, возможно корректирует какие-то значения в sysfs, возможно с помощью ioctl общается с драйвером КП и даёт разрешение на старт зарядки и обновление информации в sysfs. В любом случае, после замены /system/bin/vcharged на оный из родной прошивки, зарядка заработала.
Для этого мы снова перемонтируем /system/ в режим записи и копируем vcharged, не забыв вернуть обратно необходимые права:
Перезагружаем устройство и… зарядка с индикацией появилась!
Вроде всё работает на первый взгляд: и звук, и вибро, и Wi-Fi с Bluetooth… однако сети-то нет! Девайс не определял наличие SIM, а вместо IMEI у нас был null/null:
Чтобы её поднять, нам необходимо разобраться в том, как работает подсистема взаимодействия с радиомодулем в Android, которая называется ril — Radio Interface Library. RIL предоставляет API для системы, дабы оперировать не напрямую AT-командами (которые могут быть проприетарными, а на некоторых чипсетах, как, например, Qualcomm вообще отсутствовать), а удобным набором функций — например о запросе статуса радиомодуля, начале звонка, поиска сети и т. п. RIL состоит из сервиса rild в /system/bin/ и библиотеки libril.so, которую можно найти в папке /system/lib/. При запуске системы, TelephonyManager открывает сокет с rild и опрашивает его состояние. Именно из TelephonyManager система берет информацию о силе сигнала, название оператора, IMEI и другие данные.
Путем ковыряния в dmesg я понял, что система флудит из-за невозможности запустить проприетарный сервис Spreadtrum — sprd_monitor. При попытке позвонить в 112, смартфон бесконечно пытается включить радиомодуль. Я ковырялся в UI-части исходного кода Android, дабы понять логику работы, но проблема крылась как раз в упомянутых выше службах sprd_monitor. Берём их из /system/bin/ оригинальной прошивки, закидываем их в устройство, не забыв установить права и отправляем систему в ребут:
Ошибки в dmesg пропали, IMEI появился, но устройство до сих пор не хочет никуда звонить и просто висит на экране звонка. В настройках смартфон говорит о том, что уровень сигнала недоступен, а значит, радиомодуль до сих пор не работает :(
Но и мы так просто не сдаемся! Поковыляв по файловой системе, в директории /system/opl/telephony/bin/ я нашел скрипт, отвечающий за инициализацию радиотракта, который вызывает родной 3rdparty.rc! Запускаем sh-скрипт и обнаруживаем, что сеть появилась и девайс дозвонился в 112, а также увидел SIM-карту!
Теперь всё полностью работает :) Дабы радиотракт запускался при старте устройства, я перенес часть инита из boot.img от прошивки, которую мы портировали. Для кого-то, казалось бы, это всё достаточно сложно и долго. Но у меня ушел всего один день на полную отладку и запуск такой кастомной прошивки на своем устройстве! Можно сказать, это самый базовый и краткий экскурс в такое нелегкое дело, как моддинг Android-устройств.
Но мы ведь это всё не просто так делали! Давайте глянем, как будет работать такой девайс на Android 2.2 в 2024 году — спустя 14 лет после выхода системы. Всё ли так плохо, как кажется?
❯ Знакомимся с девайсом
Думаю, многие читатели вспомнят этот ламповый интерфейс, обои с одуванчиком и лаунчеры а-ля TouchWiz на тех смартфонах, где интерфейс Samsung был не предусмотрен. А эти «бульк»… их сложно забыть!
Конечно, изначально может показаться, что устройство плохо подходит для выполнения современных задач: браузер не способен загрузить большинство страниц, а из альтернатив есть только Opera Mini, где вообще нет динамического контента, а официальные клиенты ВК, WhatsApp и YouTube уже давно не работают. Опечаленный читатель может подумать, что девайс, как и многие его ровесники уже давно превратились в звонилки…
Но это отнюдь не так! Ведь как я уже говорил, я стараюсь своими силами вдохнуть в подобные девайсы новую жизнь, реализуя на них клиенты нужных мне сервисов сам! Да, пусть примитивно и корявенько, далеко не ынтырпрайз-уровень, но эти приложения выполняют свои функции и что, немаловажно, весят очень мало (до 100Кб) и работают крайне шустро! Клиент ВКшечки просто летает, несмотря на то, что фактически реализован только мессенджер с нотификациями и музыка.
Пожалуй, многие читатели удивятся — но на таких девайсах есть YouTube! Мой самопальный клиент не поддерживает стриминг из сети (да и многие девайсы объективно не потянут), поэтому предварительно загружает видео на MicroSD-флэшку и затем уже их воспроизводит. Как приятный бонус — видео потом можно посмотреть в любой момент в галерее.
Я помню насколько было лампово слушать музыку с таких девайсов. И если претензии к основному динамику не очень актуальны, то к качеству звука в наушниках были придирки — звук был громкий, но ему не хватало низких частот, из-за чего он звучал несколько плоско, хотя мне и этого хватало — ведь я слушал музыку в наушниках по 200-300 рублей с рынка! Я всё ещё помню те времена, как качал mp3-треки по 2-3 мегабайта через 2G-интернет… слушаешь один трек — как раз загрузится другой и так по кругу наполнял свою фонотеку. Эх времена то какие были! Тем не менее, для некоторых базовых мультимедийных возможностей девайс подходит и сейчас, например в машину в качестве BT-хоста с музыкой. А ещё на таких девайсах порой клёво скачать какой-нибудь Temple Run образца 2011 года и вспомнить самое начало смартфонного гейминга тех лет… ведь далеко не все игры того времени запускаются на свежих версиях Android!
❯ Заключение
В остальном же, подобные девайсы отнюдь не бесперспективны! Несмотря на совсем не новое железо, они всё ещё могут выполнять многие задачи, стоит лишь снова запилить необходимые приложения для них! Мессенджеры, соц. сети, музыкальные сервисы и даже просмотр видео — всё это доступно даже для таких, казалось бы, «устаревших» девайсов, когда есть запал энтузиазма и жгучее желание походить именно с этим конкретным устройством как с основным!
Для кого-то это просто проявление синдрома утенка или картинки «вот кому-то делать не.»… ну а для меня — это крайне интересное, захватывающее и кайфовое времяпровождение: начиная от аппаратного ковыряния с такими девайсами и копания исходников ядер/драйверов, заканчивая написанием оптимизированных клиентских приложений, которые весят не 100-200Мб, а 100-200Кб :)
Друзья, если у вас есть подобные китайчики и вы не разделяете желания пытаться вдохнуть в них жизнь, но выбрасывать их жалко — можете задонатить их мне :) Как сами видите — девайсы попадают в хорошие руки. Из недавнего — я взял нерабочую, утопленную китайскую копию 14 Pro Max из под СЦ в качестве основного смартфона. Также у меня есть канал в Telegram, куда я выкладываю бэкстейджи статей, различные заметки о ремонте, моддинге, программировании и реверс-инжиниринге и свои мысли. Кому интересно — залетайте!
Понравилась ли вам статья? Какими были ваши первые Android-смартфоны? Пишите в комментариях, будет интересно почитать!
Осторожно: в статье аппаратная диагностика и ремонт, реверс-инжиниринг и патчинг загрузчика, а также программный моддинг noname-устройства, для которого нет вообще никакой информации. В материале куча познавательного контента, даже если вы не фанат такого своеобразного класса устройств, как подделки на брендовые девайсы.
Пожалуй, споры о том, какая мобильная платформа лучше не утихнут никогда. Люди из года в год спорят, какая же мобильная платформа круче: iOS или Android, и какие только аргументы не выдвигают в сторону оппонента. Но что делать, когда хочется усидеть сразу на двух стульях и иметь смартфон в корпусе iPhone, но при этом с привычным Android на борту? Когда душа моддера и любителя красноглазия просто требует чего-то необычного!? Правильно, обратиться к китайским «подвалам» и взять себе дешевую реплику на андроиде! А в моём случае — ещё и Б/У утопленную подделку 14 Pro Max чуть больше, чем за «тыщу» рублей, так ещё и проапгрейдить её! Сегодня будет познавательный и интересный материал, в котором мы с вами: узнаем как диагностировать некоторые аппаратные проблемы с помощью минимального и дешевого оборудования, оживим наше «яблочко» после попадания влаги, «отреверсим» и пропатчим в IDA Pro загрузчик, дабы разрешить загрузку unsigned-ядер, портируем кастомное рекавери и накатим рут, а также узнаем что из себя представляет такой «айфон» в повседневной жизни и как мне вообще взбрело в голову купить китайскую подделку яблочной техники! Материал диковинный, но обещаю — будет интересно! Жду вас под катом :)
❯ Содержание
Ещё каких-то 10-12 лет назад люди собирались в комментариях под различными постами и жарко спорили о том, чья платформа более продвинутая. Чаще всего темой спорой была iPhone vs Android, реже — iPhone vs Windows Phone, а иногда и Android vs Symbian! Но годы идут, на рынке осталось только два крупных игрока, а споры всё не утихают. Стоит только зайти на профильный сайт, зайти в любой пост с новостями и насладится всеми прелестями споров «A vs B». Кто-то поддерживает экосистему Apple, кто-то Android в чистом виде, а кто-то микс фишек Apple в Android окружении от Xiaomi. Некоторые люди даже поддерживают, казалось бы, «неактуальные» платформы как Symbian/WP и среди них есть мои читатели (я и сам очень люблю их и запилил клиенты ВК и YouTube на них, о чём рассказываю в отдельной статье) :)
Но как мои давние читатели наверняка знают, я лично всегда придерживался позиции, что и iOS, и Android, и Symbian, и WP — замечательные системы, которые так или иначе нашли своего пользователя. У меня сейчас есть довольно много смартфонов прошлого десятилетия: полтора года назад я взял себе Galaxy S4 Mini в качестве основного девайса, год назад ходил уже с обычным Galaxy S4, а чуть больше полугода назад читатели подарили мне оригинальные iPhone, от 2G до 5s! И лично я очень люблю iPhone за отличный дизайн, за шуструю iOS, за достойную поддержку старых девайсов, но в тоже время… я ведь и сам вырос на 4pda, пользуясь ультрабюджетными «декспами», «зте» и «флаями»! И тяга к аппаратному и программному моддингу, а также написанию хоумбрю-приложений и прочим фишкам действительно открытых платформ отнюдь не угасла, скорее только наоборот!
Поэтому от нового девайса, с которым я хотел бы походить как с основным, я требовал лишь три вещи:
Дизайн одной из последних моделей iPhone. Пожалуй, кто-то из читателей сочтет это за «тупой понт», но это не совсем так, яблочные дизайны действительно неплохо продуманы и их приятно держать в руках. Важно понимать, что выпуская подделки, заводы откровенно экономят на железе, но при этом стараются достаточно качественно скопировать корпус, используя в конструкции и алюминий, и каленое стекло, а также установить относительно неплохую IPS-матрицу, пусть и низкого разрешения.
Поддержка LTE. Вы удивитесь, но да, всё ещё выходят реплики iPhone, Samsung, да даже Poco и Realme, которые построены на базе чипсета 2015 года — речь, конечно же, о MT6580. И к сожалению, радиотракт этого чипсета не умеет работать с LTE, да и у платформы очень серьезные ограничения на объём ОЗУ (не более 2Гб) и разрешение дисплея (не выше HD) :(
Android на борту. Ну, по этому пункту я всё рассказал выше. При этом для меня не имеет значение версия системы, я не гонюсь за самыми новыми фишками: китайцы уже не ставят Android ниже 6-7 версии (впрочем, это спорно, предположительно ещё попадаются девайсы с 5.1 на борту среди самого дешевого сегмента), а «шестерки» мне вполне достаточно для всех моих применений, в том числе и YouTube с ВКшечкой. Чего там говорить, если мне чего-то действительно не хватает и у меня есть настроение — я сам себе запилю приложение :) Касательно статуса загрузчика я не волнуюсь: в «подвальных» девайсах практически никогда не бывает секьюрбута и нет никакой необходимости патчить загрузчик, что открывает широкие возможности к его моддингу. Эх, вот бы еще исходники ядер выкладывали — но это уже мечты :)
И под эти требования вполне попадают «новодельные» реплики последних моделей iPhone в среднем ценовом сегменте (от 10 000 рублей). Казалось бы, кто-то из читателей спросит: «автор, ты дурак за фуллпрайс брать такой девайс?». И нет, не дурак, поскольку смартфон я купил за 1 500 рублей (и это ещё дорого за его состояние, после покупки мне попался похожий девайс, но уже рабочий, с коробкой и всего за 500 рублей). Девайс продавал человек из СЦ, с которым мы состоим в одной беседе посвященной ретро-телефонам. Смартфон был заявлен как «невключайка» без признаков жизни, в непонятном состоянии, с битой задней крышкой и даже без базовой информации, такой, как о потреблении девайса на зарядки и при зажатой кнопке включения. Ну, как вы и сами понимаете, это настоящее комбо: не подающий признаков жизни китайский смартфон без какой-либо сервисной документации и схемы, который уже побывал в СЦ (потенциально в качестве донора) и наверняка разбирался, да ещё и, как потом оказалось, утопленный в воде… Это же только интереснее! Конечно берем!
Когда девайс приехал ко мне, то ещё до прихода домой я решил оценить его тактильные качества. Конечно, задняя крышка, увы, была подбита, но в целом мне всё равно девайс очень понравился. Как я уже сказал, рама смартфона выполнена из алюминия (за исключением толкателей кнопок), а задняя крышка из стекла с приятной на ощупь текстурой и, конечно же, выгравированным яблочком! Пока дисплей выключен, даже рамки дисплея едва ли дают себя выдать: по сути, определить реплику сможет только человек, который в теме яблочек и сможет опознать фейковые линзы с обратной стороны смартфона. Остальным можно наплести про «китайский дисплей» и т. п. :)
Придя домой, я понял — приключения только начинаются. Отклеив заднюю крышку с помощью фена, выяснилось, что девайс вскрывался: пару винтов потеряли, да и заводскую пломбу содрали.
Замеряем напряжение на АКБ и понимаем, что она села ниже 3.4В (3.5В — это уже 0%) и контроллер питания должен начать зарядку в режиме Precharge (режим «расталкивания» аккумулятора низким током). В режиме Precharge смартфон не показывает никакой индикации зарядки, поэтому остаётся лишь смотреть на потребление девайса и терпеливо ждать включения! Я ещё немного помог устройству раскачать АКБ с помощью внешнего 5В источника и вот, потребление поползло выше 0.2А — а девайс показал яблочко и индикацию зарядки. Неужели он рабочий?
На фото выше не видно, однако смартфон был залит водой и на дисплее появились большие разводы. И попадание воды не прошло просто так: он просто перезагружался на «яблочке», как и настоящий айфон… Вы, читатели, можете пока предположить, что же с девайсом было не так, а я включаю логическое мышление и перехожу к диагностике.
Друзья! Если вам не особо интересны технические детали аппаратного ремонта, или наоборот программного и вы хотели увидеть только обзор на устройство — можете прыгнуть сразу к обзору смартфона. Однако в технической части тоже много всего интересного!
❯ Диагностируем и ремонтируем
Итак, давайте сделаем выводы, которые мы можем понять из существующих симптомов:
Девайс заряжается и у него есть потребление, пусть оно и кажется заниженным, а значит модуль чарджера в контроллере питания, скорее всего, исправен.
Девайс включается и есть изображение яблочка, а значит, есть связь с eMMC и контроллер DDR инициализируется успешно, девайс проходит цепочку загрузки Preloader -> LK и возможно ядро, а также КП нормально реагирует на кнопку включения и включает необходимые выходы LDO для питания всех основных модулей смартфона (процессор и его периферия, чип памяти eMCP, драйвер bias-напряжений дисплея и т. п.). Скорее всего (но это не 100% гарантия), от воды не пострадали ни процессор, ни флэш-память.
Девайс уходит в перезагрузку: здесь причин может быть масса, например, данные на eMMC были повреждены в процессе залития и требуется прошивка, или всё же процессор или его обвязка оказались частично повреждены и при обращении к одному из встроенных периферийных модулей основное вычислительное ядро виснет и встроенный в КП WatchDog при отсутствии сигналов «сердцебиения» считает смартфон зависшим и отправляет его в намеренный ребут, из-за чего мы получаем циклическую перезагрузку. Не исключён вариант, что одна из внешних шин данных оказалась посаженной на массу в следствии КЗ одного из чипов на плате (или их обвязки), из-за чего драйвер, например, вываливает систему в Kernel panic и WatchDog также отправляет систему в ребут…
Наш девайс отказывался зайти в рекавери, что даёт нам понять, что до init дело скорее всего не доходит и девайс стопорится либо на LK (который и показывает анимацию зарядки и первое лого), либо на загрузке ядра. Казалось бы, столько причин, а метод лечения у многих ребят один: сейчас будем делать диагностический прогрев, а потом снимать все чипы и катать их, и если не поможет — глянем обвязку и межслойные обрывы :) Но не стоит так торопиться, ведь в некоторых случаях для диагностики аппаратных проблем можно использовать программные инструменты!
Дело вот в чём: многие китайские производители, особенно это касается ультрадешёвых смартфонов и планшетов, специально оставляют диагностические пятачки, которые дублируют контакты АКБ, если вы случайно сорвали пятачки при пайке аккума, USB, если вы не смогли найти китайский Lightning под замену, а также пятаки UART, иногда даже на несколько каналов, которые позволяют читать логи — диагностическую информацию, которую девайс выводит при загрузке и работе устройства! И порой, подписанные пятачки с включенным дебагом на UART'е полезнее даже полной схемы устройства с бордвью!
На фото отмечены пятаки, дублирующие USB
Ой-ой, а ведь присмотревшись к плате, мы увидим, что кто-то снимал защитный экран и пытался прогревать BT/Wi-Fi/FM комбочип, а также то, что вся плата в подтеках флюса! Да ещё и всю обвязку кто-то посдувал фиг пойми куда, да так, что часть обвязки лежала прямо на пинах комбочипа, а у нас ведь даже схемы нет! Не беда — эти смартфоны построены на базе референсной платы MediaTek и с большой вероятностью, обвязка будет расположена идентично с другими смартфонами на базе этих чипсетов. Но в моем случае, я просто поставил SMD-компоненты туда, где они, очевидно, стояли: резисторы к резисторам, конденсаторы к конденсаторам, а иных элементов у меня пока-что не было. Дабы комбочип точно не вмешался в работу устройства, я временно его сдул с платы:
За качество фото извиняюсь, сделано в попыхах
Я сразу же снял дамп своего устройства и нашел по платформе прелоадера и названию сборки оригинальную прошивку (линк в описании, решил оставить оригинальную ссылку, поскольку автор нормальный и не просит писать ему в мессенджеры за паролем для архива), дабы исключить вероятность косяка со стороны eMMC.
Обратите внимание — я сначала сделал дамп, дабы в случае неподходящей прошивки, прошить свою или собрать из двух прошивок одну! Поскольку мой китайский псевдолайтнинг уже был слегка подуставший (хотя 14 Pro Max ещё относительно свежий девайс) и сигнальные линии D+ D- были просажены, а девайс не определялся ПК, я отключил нижнюю плату АКБ и подпаялся напрямую к дублирующим пятачкам USB: после этого, девайс определился в системе как MTK Preloader, что дало мне возможность прошить официальную прошивку, но ожидаемо, эффекта это не принесло — смартфон всё так же перезагружался на яблочке :(
Затем я решил подпаяться к UART'у и всё же почитать логи подробнее: для этого, нам пригодится UART-преобразователь. Также, в качестве UART-преобразователя подойдет и ESP32, который частенько можно найти в местных радиомагазинах за копейки. Сигнал EN необходимо кинуть на 3.3В - это погрузит МК в RESET и не даст ему влиять на шину!
Подпаиваемся так, как я отметил на фото ниже, не забывая подключить общую массу. Для чтения UART'а я использую putty.exe: выбираем наш COM-порт, ставим бодрейт 921600 и запитываем девайс: теперь у нас побежали логи…
С левой стороны каждой строки лога написано время с момента старта ядра — т. н. «аптайм». На него тоже важно обращать внимание, поскольку он помогает приблизительно понять, на каком визуальном (т. е. то, что мы видим на дисплее) этапе стопорится загрузка. Мой девайс падал в Kernel panic и уходил в перезагрузку на 30 секунде работы… казалось бы, что можно понять из этих логов и как определить неисправность? Вот тут мы фокусируем наше внимание на двух строках:
Первая — это то, что у нас пытается проинициализироваться драйвер stk301x — датчика освещенности и приближения к уху, а вторая, где написано таймаут — означает об ошибке передачи данных на шине I2C к устройству по адресу 47. И чтобы понять суть ошибки, нам нужно иметь базовое понимание о принципах работы самых часто применяемых аппаратных протоколах для общения с другими чипами: SPI, I2C и 8080. В протоколе I2C, у каждого устройства есть собственный адрес, выраженный в 7-битном формате (до 127 адресов на одной шине), в случае stk301x — это 47. Что делает драйвер: он посылает датчику набор команд для инициализации или получения данных, при этом на хост-устройстве (т. е. процессор в нашем случае), сначала формируется состояние СТАРТ и посылает всем устройствам на шине адрес нужного устройства. Затем, нужный чип должен «подхватить» свой адрес и на все байты передаваемых данных формировать статус ПОЛУЧЕНО (ACK). Если статус ACK не получен аппаратным I2C-контроллером процессора телефона за определенное время (допустим, 1 секунда), то он формирует прерывание (или просто изменяет статусный регистр), который обрабатывает драйвер контроллера I2C, который затем и выдает драйверу датчика статус таймаут, а тот в свою очередь выводит ошибку в логи!
Пример с сайта компании Microchip
Всё равно ничего не понятно? И снова мы с вами включаем смекалку. Если устройство жалуется на отсутствие состояния ACK, значит, возможны две причины поломки: обрыв линии SDA/SCL до устройства, либо то, что в следствии попадания воды, одно из периферийных устройств «сгорело» и садит всю шину I2C на массу, из-за чего, например, драйвер другого устройства на шине I2C крашится, а поскольку это драйвер работающий в пространстве ядра — он тащит за собой все! Может быть и такой вариант, что драйвер КП не может посылать сигналы Heartbeat из-за просаженной шины и КП отправляет устройство в ребут.
Сдуваем наш датчик освещенности, включаем девайс и он вроде даже не выключился спустя 30 секунд… проходит пару минут и…
Решил вставить оригинальное фото первого включения, как раз сделанное «по быстрому» и в порыве радости :)
Он включился и работает! Он выжил, хотя разводы воды заметно сказались на состоянии его дисплея! Но поскольку комбочип пока что выпаян, у нас не будет ни Wi-Fi, ни BT, ни GPS, ни радио. Поэтому отключаем девайс и припаиваем обратно комбочип, не забыв восстановить всю обвязку. В финале мы отмываем плату от подтеков флюса (не весь флюс мне удалось нормально вымыть, потому что старый прикипел).
После установки комбочипа и остатков обвязки (а может, это и вся обвязка что была с завода, китайцы ведь часто экономят и на этом — ставят необходимый минимум), я проверил и Wi-Fi, и BT — теперь девайс звонит и без проблем выходит в интернет!
На этом аппаратный ремонт закончен. Поскольку девайс теперь работает, можно приступать к его программному моддингу! Но сначала, нужно отключить проверку подписи образа ядра.
❯ Патчим загрузчик
Как я уже говорил выше, в подобных репликах и просто дешевых noname-девайсах фактически отключен полноценный секьюрбут. Однако конкретно в этой реплике, при сборки прошивки, производитель включил в lk (загрузчик второго уровня) принудительную проверку подписи у образов ядра boot.img и recovery.img, предварительно включив возможность его отключения (т. е. разблокировки загрузчика) в режиме fastboot. На многих девайсах достаточно лишь перезагрузить устройство в режим fastboot и выполнить специальную oem-команду:
adb reboot bootloader fastboot oem unlock
Которая вызовет соответствующий диалог. Но вот незадача: девайс не реагирует на кнопку вверх, из-за чего загрузчик разблокировать не получается. Намеренная подлянка от производителя? Скорее недосмотр при проектировании платы, благо исходный код вторичного загрузчика LK, который и реализовывает режим fastboot сливали в сеть. Давайте изучим его подробнее!
Итак, что мы здесь видим? При запросе разлочки устройства, девайс падает в бесконечный цикл, в котором проверяет и реагирует на одну из соответствующих клавиш — громкость вверх, или кнопка «ОК», которая считается кнопкой вниз. Почему же девайс не определяет кнопку вверх? В чипсете есть отдельный периферийный модуль, который отвечает за обработку Keypad-кнопок клавиатуры. Он же позволяет реализовать полноценную QWERTY-клавиатуру без внешних контроллеров, если того захочет производитель. Однако он оперирует не конкретными логическими уровнями на GPIO (иначе потребовалось бы слишком много пинов и, скорее всего, сильно увеличивать размер чипа), а специальным АЦП (аналогово-цифровой преобразователь) с низким разрешением, который вычисляет, какая кнопка нажата относительно определенного сопротивления. Следовательно, если производитель каким-то образом накосячил при разводке платы и резистором иного номинала «присвоил» громкости вверх другой аппаратный KeyCode-клавиши, функция mtk_detect_key банально не «увидит» нажатие нужной нам кнопки, которая захардкожена как 0x0.
Но почему тогда в Android, кнопка громкости вверх работает нормально?
У Android есть отдельный механизм для маппинга кнопок, называемый keylayout'ами. В текстовом файле хранятся ассоциации числовых KeyCode'ов с константными обозначениями, такими как VOLUME_UP и VOLUME_DOWN например. Поэтому вы без проблем можете поменять их значение местами, или, например, если у вас сломалась кнопка включения, переназначить её на громкость вверх без необходимости кидать перемычку!
Подробнее о подсистеме ввода в Android я рассказывал в другой своей статье.
Как же это поправить? Не собирать же нам lk самим, да и будет ли пропатченный загрузчик работать? И да, будет! Как я уже сказал, в девайсе не включен полноценный секьюрбут с верификацией того, что вы прошиваете через FlashTool в внутреннюю память устройства. Preloader (первичный загрузчик после BootROM) не проверяет ни целостность lk, ни хэш-суммы, просто читает его в 0x0 и передает ему управление… А что это значит? Что мы можем просто пропатчить условие, отвечающее за «громкость вверх», дабы lk считал, что мы все таки нажали эту кнопку! Открываем дизассемблер IDA Pro и наш lk.bin в нём, как обычный binary-файл со смещением 0x0 и ищем те строки, которые встречаются ближе всего к нужному нам условию. В нашем случае, это Start unlock flow.
Как видите, IDA Pro, как самый крутой дизассемблер по моему мнению, уже построил xref'ы (все ссылки на бинарные данные из инструкций) и сразу показывает нам куда обращается тот или иной код. Опана! А вот мы и нашли код функции, которая отвечает за старт анлока загрузчика и проверяет нажатые кнопки. Что же нам с этим делать? Правильно, переключится в режим графа и анализировать код подробнее. Я не так силен в ARM-ассемблере, как x86, но всё же не без помощи ISA-мануала от ARM понял значение всех мнемоник.
Обратите внимание на инструкцию BL — она вызывает подфункцию и сохраняет адрес PC + длина инструкции в стек, дабы продолжить выполнение после возврата из неё. Это и есть вызов нашей функции mtk_detect_key. Оптимизатор сократил код так, что сразу после возврата из функции, её возвращаемое значение оказывается в регистре R4, который программа переносит в регистр R0, а затем сравнивает R0 с нулем. Если R0 оказывается ноль (инструкция BEQ, branch if equal to zero, т. е. кнопка не нажата), программа прыгает к проверке кнопки «вниз», а если нет — то продолжает выполнение кода, который стартует разблокировку загрузчика. Уже смекнули, о чем я? Нам достаточно лишь пропатчить CMP R0, #0, дабы заставить программу считать, будто кнопку мы все таки нажали и перейти к процессу разблокировки!
Обратите внимание, что в #0 (т. е. с решеткой) — это Immediate-значение, которое уже является операндом инструкции, а не загружается, например из регистра, а значит мы можем просто найти это значение в HEX-редакторе и пропатчить его на 1, либо просто NOP'нуть всю инструкцию. Адрес операнда инструкции — 0x1FB0C, поэтому сразу переходим к нему в hex редакторе и просто меняем 0 на 1 и сохраняем:
Прошиваем новый lk.bin с помощью SP Flash Tool, перезагружаемся в fastboot, пишем fastboot oem unlock и… сработало! Смотрим статус разлочки с помощью fastboot oem device-info (unlocked и secure) и видим что девайс действительно разлочен! Теперь смартфон каждое включение будет напоминать нам о том, что мы разлочили загрузчик. Ну разлочили и разлочили, зато теперь у нас полная свобода действий :) Переходим к ответственному действияю — портированию рекавери и накатыванию рута! Но здесь всё уже гораздо проще.
❯ Портируем рекавери и накатываем рут
Поскольку мы с вами уже разблокировали загрузчик, то и без проблем можем грузить что захотим: и LineageOS, и MIUI — всё что уже портировано для этого чипсета на этой версии ядра. Правда не забывайте, что чипсет 64х-битный, множество прошивок — тоже, а китайцы почему-то собрали 32х-битную прошивку — это стоит иметь ввиду при портировании. Если честно, изначально я хотел включить часть с портированием прошивки в основную статью, но опросив читателей понял, что вам не особо комфортно читать статьи 20+ минут длиной, поэтому если вам интересен подробный материал о портировании прошивки без пересборки ядра на нонейм устройствах — проголосуйте в опросе ниже (или маякните в комментариях)!
Начинаем с накатывания «кухни». Я пользуюсь MTK Img Tools, весьма удобный софт. Для его использования, нужно вручную создать папки Pack/Image и Unpack/Image.
Закидываем в папку Unpack/Image родной recovery.img, и тот, который будем портировать — назовем его recoverytwrp.img. Распаковываем их в менюшке Unpack image -> Boot. После распаковки, у нас появятся папки recovery и recoverytwrp в папке Unpack, где мы и будем вести нашу работу. В целом, на MT6753 в нашем случае достаточно лишь перенести родное ядро в тот рекавери, который мы портируем. fstab же трогать не нужно. Делается это легко: просто копируем recovery/kernel/kernel в recoverytwrp/kernel/kernel с заменой и пересобираем образ командой Pack image -> Boot обратно. Собранный образ мы найдем в папке Pack/Image, его можно либо прошить в флэштуле взамен стандартного, либо загрузить прям из фастбута без необходимости прошивать память устройства (это, кстати, ещё один отличный способ грузить Android с MicroSD если флэшка «закончилась»).
fastboot boot recovery.img
Кастомный рекавери загрузился без проблем — а это значит, что нам открыты большие возможности по кастомизации нашего девайса! Берем SuperSU с официального сайта, прошиваем SuperSU.zip с помощью adb sideload и балдеем, теперь с полноценным рут-доступом к устройству и без необходимости патчить Magisk'ом или распаковывать раздел system!
Теперь можно вычистить весь мусор из предустановленных приложений благодаря спец. софту для менеджмента приложений на смартфоне.
❯ Можно ли пользоваться девайсом?
Давайте посмотрим! Девайс из коробки похож на iOS 16, при этом, поскольку такие «айфоны» работают на общей аппаратной платформе, теоретически есть возможность поставить на 12 Pro Max прошивку от, например, 15 Pro Max (с некоторыми изменениями) :)
Функционал системы скопирован достаточно точно. На некоторых репликах особо не заморачиваются и просто чуть изменяют значки на айфоновские, не убирая даже нижнюю панель кнопок. Здесь же все скопировано с настоящей iOS: свайп снизу вверх сворачивает приложение, свайп до центра экрана открывает меню многозадачности, свайп шторки с левой стороны открывает панель нотификаций, а справа — панель управления. И ведь это не просто чужие готовые лаунчеры из условного Play Market, компания-производитель либо аутсорсит копирование некоторых фишек разработчикам на стороне, либо держит свой собственный штат программеров, который, в том числе, занимается сборкой прошивок и портами с рефборды!
В настройках, система гордо называет себя iOS, а модель смартфона — iPhone 14 Pro Max! Но что на практике? CPU-Z говорит о следующих характеристиках:
Тоже не знали, что Apple A16 разрабатывала MediaTek? :)
Более половины характеристик — брехня. Настоящие спецификации девайса следующие:
Процессор: MediaTek MT6753. 8 ядер Cortex-A53, 4 из которых работают на частоте 1.5ГГц, а оставшиеся — на частоте 1.3ГГц. Чипсет выпущен в 2015 году и выполнен по техпроцессу 28Нм, поддерживает до 3Гб ОЗУ.
GPU: Mali T720, преемник легендарного Mali 400. Уже немолодой, но всё ещё кое-что, да может. Vulkan не умеет.
ОЗУ: 3Гб DDR3. Не так много, но в целом пока ещё относительно адекватно.
Флэш-память: хотели 512Гб? Получите 32Гб, а недостаток можно нарастить MicroSD-флэшкой, слот под которую производитель заботливо предусмотрел под крышкой устройства. Это частая практика для китайских айфонов.
Дисплей: с диагональю не наврали, честные 6.7". А вот с разрешением, конечно-же, приукрасили: здесь стоит HD+ IPS матрица с разрешением 720x1540. Не особо высокое разрешение для такой диагонали дисплея, но в остальном дисплей показывает себя адекватно: яркость приемлемая, цвета хорошие, матрица отзывчивая.
В целом, характеристики ближе к ультрабюджетным моделям Realme и Poco. Нельзя сказать, что всё прям очень плохо, но ожидать что он будет работать на уровне флагманов, конечно же, не стоит. Но как оно на практике?
Начинаем с мессенджеров: ВКшечка и Telegram. В качестве клиента ВК, я юзаю исключительно Kate Mobile, который шустро работает даже на 10-летних китайцах на MT6572. Официальный клиент давно не признаю, всё таки при grishka он был лучше :)
Последний официальный клиент телеги работает шустро. Чипсет, конечно, печка ещё та, но посидеть в чатиках, посмотреть видосы и всякое такое можно без каких либо проблем. Главное чтобы память резко не закончилась. WhatsApp здесь тоже работает нормально.
Переходим к видосам. Ни официальный клиент, ни ревансед последних версий нормально здесь работать не будет — официальные клиенты требуют Android 8+. Но разве ж это проблема для нас, когда есть SkyTube? :) Работает шустренько, девайс без проблем держит 720p видосы, а больше и смысла нет.
Как насчет навигации? Google-карты работают адекватно. Всё весьма шустренько, хотя порой просадки FPS всё же бывают. Но я лично предпочитаю выкидывать гаппсы из своих смартфонов и накатывать навигацию по OSM. Что забавно — в девайсе есть собственный клон AppStore'а! И если рескины Google Play в стиле яблочного магазина для меня не удивление, то наличие полноценного бренда CH с эдаким фидбеком у смартфона меня весьма удивило. Я всё ещё помню GooPhone'ы, которые когда-то предоставляли хороший клиентский сервис покупателям своих реплик айфонов, но не думал что эта практика даже сейчас актуальна. Вполне возможно, что CH — это и относительно крупный завод-производитель со своим R&D отделом, поскольку маркировка есть и на межплатном шлейфе, и на АКБ. Эта компания также производит реплики Galaxy S и Note серии, на базе той-же аппаратной платформы.
И переходим, конечно-же, к камере! Самое приложение скопировано 1 в 1 с оригинала, даже есть какие-то панорамные режимы и фишки с цифровым зумом и подобием изменения FOV. Но понятное дело, тест не может быть объективным на 100%: девайс после воды, топился в районе камеры и на фото явно видны засветы. Есть вероятность, что оптика всё же оказалась немного повреждена :(
"Фотосет" из двух наиболее удачных фотографий есть на imgur. Увы, на Пикабу очень большие ограничения на число картинок в одном посте!
Но на скринах всё красиво, а как на деле? Смотрим:
❯ Заключение
В целом, девайс весьма хорош для моих повседневных задач. Работает шустренько, выглядит как айфон как с внешней точки зрения, так и с точки зрения системы, дисплей весьма неплох по качеству, смартфон отлично поддаётся моддингу. Собственно, а почему-бы и нет?
Цель материала была рассказать вам не только о том, на что подобные реплики способны «из коробки», но и об их возможностях моддинга и кастомизации с подробной практической частью, а не на уровне «пойдите туда и сделайте это»! Но учтите, я не рекомендую покупать реплики айфонов, если вы ожидаете от них хорошей работы из коробки и у вас нет желания в них ковыряться. Зато мне очень понравилось с ним возиться и я надеюсь, по итогу было интересно и вам! Пишите своё мнение в комментариях, будет интересно почитать! Также у меня есть канал в телеге, где я публикую бэкстейджи статей, различные посты по тематике аппаратного и программного моддинга, программирования, а также разработки собственного DIY-железа!
Кстати, если у кого-то из читателей есть похожие подделки будучи нерабочими, тормозящими, или окирпиченными и вам не хотелось бы выкидывать их на свалку, а наоборот, отдать их в хорошие руки и увидеть про них статью — пишите мне в Telegram или в комментах! Готов в том числе и купить их. Особенно ищу донора дисплея на китайскую реплику iPhone 11 Pro Max: мой ударник, контроллер дисплея калится и изображения нет :(
Что думаете о девайсе?
Что думаете о покупке его за 10.000 рублей? А за 1.000 рублей?
Материал полезен?
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Мы вводим новую рубрику #СделаноВСаяногорске. В ней мы будем рассказывать про наших местных предпринимателей, производящих продукцию, которую знают далеко за пределами муниципалитета.
Первый, о ком пойдет речь – социальный предприниматель Анатолий Туганашев.
Анатолий Бекмурзович более 10 лет изготавливает технические средства реабилитации для людей с ограниченными возможностями - специальные велосипеды, ходунки, тренажеры, беговые дорожки, регулируемые кровати для лежачих пациентов и ряд других товаров.
Каждый тренажер изготавливается вручную небольшой командой единомышленников, которые работают на предприятии. Продукция постоянно дорабатывается и отвечает всем стандартам качества. В ней все продумано до мелочей. Например, велотренажер для детей, болеющих ДЦП, может использоваться как на улице, так и дома. Специальная откидывающаяся конструкция позволяет сделать его универсальным. И это лишь один из примеров.
Социальное предпринимательство – сложный и ответственный труд. Анатолий Бекмурзович успешно участвует в федеральных и региональных конкурсах, неоднократно получал материальную поддержку проекта в том числе и со стороны муниципалитета.
Мы хотим, чтобы как можно больше людей знали, что рядом с нами живут такие мастера.
Узнать более подробную информацию о производстве Анатолия Туганашева можно на сайте: www.велостарт.рф и по телефонам: 8 (39042) 3-10-96, 8-961-740-30-13.
Вот такая информация для инвалидов, опубликованная на сайте Саяногорска, надеюсь будет полезна не только вам.
я каждый день ищу себе какое-нибудь приспособления, которое поможет моим родным меня перемещать меня с места на место и недавно, я нашёл видео там показано одно устройство, но не указано как оно называется и где её можно купить, Если вообще можно
Если сейчас приехать в пункт приема металлолома, то можно обнаружить просто огромные кучи различных телефонов и прочих электронных «отходов», которые стоят под открытым небом и ждут, когда придёт их черёд окончательного разложения. Однако при ближайшем рассмотрении выясняется, что многие девайсы оказываются полностью рабочими даже после недельного лежания под палящим солнцем и проливными дождями, а сдали их в чермет по причинам «не нужен, надоел, купил новый» и т. п. Я не считаю это правильным, ведь даже в простые кнопочные звонилки имеется возможность вдохнуть новую жизнь, если знать один интересный, но малоизвестный факт: для них можно писать нативные приложения на C и использовать железо телефона в своих целях. А это, на минуточку, как минимум: дисплей с подсветкой, вибромотор, динамик, клавиатура и GSM-радиомодуль с возможностью выхода в сеть. Сегодня мы с вами: узнаем, на каких аппаратных платформах работают китайские телефоны, какие существуют программные платформы и где взять для них SDK, а в практической части мы напишем 2D-игру с нуля, которая будет работать на многих китайских кнопочниках. Интересно? Тогда жду вас под катом!
Содержание:
Не J2ME едины
Аппаратные ресурсы
Кроссплатформенный рантайм
Кроссплатформенный рантайм: Win32
Кроссплатформенный рантайм: MRE
Кроссплатформенный рантайм: VXP
Наконец-то пишем игру
Тестируем на реальных девайсах
Заключение
❯ Не J2ME едины
Думаю, многие мои читатели помнят о такой платформе, как J2ME. Java-приложения стали фактически основной возможностью расширения функционала телефонов в 2000-х годах. API для них был достаточно хорошо стандартизировано, программы не зависели от архитектуры процессора и ОС устройства, а порог вхождения для написания собственных приложений был довольно низкий и даже новички могли за пару дней написать свою игрушку или какое-нибудь GUI-приложение!
Однако не одним J2ME мы были едины: существовало множество платформ, которые так или иначе пытались занять нишу Java на рынке. Некоторые из них я упоминал в своей прошлой статье о написании 3D-игры под Sony Ericsson с нуля: например, была такая платформа на телефонах Sony Ericsson серии T, как Mophun, а CDMA-телефонами с чипсетами Qualcomm использовалась нативная платформа BREW. Пожалуй, я не буду упоминать о .sis и .cab — поскольку это форматы нативных приложений для смартфонов, а не простых «фичефонов».
В какой-то момент, ближе к 2006-2007 году, прилавки российских официальных ритейлеров (по большей части это были телефоны Fly) и неофициальных продавцов на рынках заполонили различные китайские телефоны, которые предлагали какой-то немыслимый функционал для тех лет за копейки, да ещё и визуально напоминали флагманские модели известных брендов. Пожалуй, одним из самых популярных таких телефонов была Nokla TV E71/E72 (да, именно «нокла»), вышедшая примерно в 2008 году и производившаяся аж до 2011 года! За 2-3 тысячи рублей (это менее 100 баксов), пользователь получал здоровый 2.4" дисплей с разрешением 240x320 весьма неплохого качества (когда в те годы многие продолжали ходить с 176x220), да ещё и с тачскрином, гироскоп, огромный громкий динамик (пусть и не очень качественный), поддержку SD-карточек до 32Гб, нередко фронтальную камеру, а также премиальный дизайн с вставками из алюминия. Частенько китайцы заботливо клали в коробку ещё чехольчик и дополнительный аккумулятор :)
Были даже полные копии существующих устройств от Nokia. Особенно китайцы любили подделывать массовые модели на S40: они были очень популярными и китайцы хотели откусить свой кусок рынка у Nokia. Пусть и рынка серого импорта — очевидно, в салонах связи подделки никто не продавал:
Но была и ложка дёгтя в этой бочке меда: китайские телефоны очень часто не имели поддержки Java, из-за чего многие пользователи разочаровывались в них из-за отсутствия возможности установить необходимые им приложения. Никакой тебе оперы, аськи, игр… Скорее всего, это связано с необходимостью отчислений Sun, а также разработчикам реализации J2ME-машины (JBed/JBlend) и установки чипа флэш-памяти чуть большего объёма.
Но многие пользователи не знали, что такие девайсы не просто поддерживали сторонние приложения, но и умели выполнять настоящие нативные программы, написанные на полноценном C! Всему помешала китайская костыльность и тотальная закрытость. Платформа предполагалась для работы на внутреннем рынке. Для вызова менеджера нативных приложений необходимо было вводить специальный инженерный код в номеронабирателе, предварительно скопировав приложение в нужную папку, а SDK долгое время было платным и доступно только для компаний из Китая. Кроме того, далеко не все приложения могли запустить на конкретном девайсе — были серьезные проблемы с совместимостью.
Всё как вы любите: HiTech-девайсы на фоне ковра, который старше автора лет на 30 :)
В ранних китайских телефонах использовалась платформа Mythroad (MRP, MiniJ) от китайской компании SkyWorks, которая лицензировала свою технологию производителям чипсетов. Поддержку MRP можно было встретить на телефонах с чипсетами MediaTek, Spreadtrum, а также MStar (и возможно Coolsand). Mythroad предоставлял некоторое API для работы с железом телефона и разработки как UI-приложений, так и игр, кроме того, Mythroad позволял хранить ресурсы в одном бинарнике с основной программой и даже имел какой-то интерпретируемый язык помимо возможности запуска нативного кода. Для работы таких приложений необходимо было скопировать менеджер приложений dsm_gm.mrp и игру в папку mythroad во внутренней памяти устройства или на флэшке, а затем набрать в номеронабирателе код *#220807#, иногда при отключенной первой SIM-карте. Костыльно? Костыльно! Откуда об этом знать среднестатистическому пользователю? Не откуда! Но работало!
Эта платформа поддерживалась на большинстве подделок под брендовые устройства Nokia, Sony Ericsson и Samsung, а также iPhone и на многих китайских кнопочных телефонах 2008-2010 годов.
Ближе к 2010 году MediaTek разработала свою собственную платформу, которая должна была заменить MRP — WRE (VXP). Эта платформа была гораздо шире с точки зрения функционала (например, был доступ к UART) и её API был вполне удобно читаем для программиста, а SDK свободно доступен для всех. Один нюанс всё портил — приложения без подписи привязывались к IMSI (даже не IMEI) симки в девайсе и на некоторых девайсах требовали переподписания под каждую конкретную SIM или патчинг дампа оригинальной прошивки телефона на отключение проверки подписи. Эта платформа поддерживалась на многих кнопочниках и смарт-часиках 2010-2020 годов: к ним относятся новодельные телефоны Nokia, телефоны DNS и DEXP, Explay и т. п. Для запуска приложений достаточно было выбрать файл с разрешением VXP в проводнике и просто запустить его. Но с совместимостью всё равно имелись проблемы: если запустить VXP для версии 2.0 и выше, мы получим лишь белый экран. Ну хоть не софтресет, и на том спасибо!
Далеко не все такие часы поддерживают MRE, смотреть нужно от устройства к устройству
❯ Аппаратные ресурсы
Большинство китайских кнопочных телефонов работает на базе одних и тех же чипсетов. В конце нулевых чаще всего использовались чипсеты MT6225, SC6520 и некоторые чипы от Coolsand. Средние хар-ки девайса были следующими:
Процессор: ARMv5 ядро на частоте ~104МГц, ARM926EJ-S. Нет FPU, есть Thumb. Большую часть процессорного времени программа могла забрать себе.
ОЗУ: ~4Мб SDRAM. Программам было доступно 512Кб-1Мб Heap'а. Это, в целом, довольно немало для большинства применений.
Флэш-память: ~32Мб, пользователю доступно пару сотен килобайт. Да, вы не ослышались, килобайт! Однако можно без проблем использовать MicroSD-флэшки до 32Гб.
Дисплей: от 128x128 до 320x480, почти всегда есть 18-битный цвет (262.000 цветов), в случае TV E71/E72 используется очень неплохая TN-матрица с хорошими углами обзора и яркой подсветкой. Иногда есть тачскрин.
Звук: громкий динамик, наушники.
Аккумулятор: ~800мАч, на некоторых девайсах может быть и 2.000мАч, а то и больше!
Ввод: клавиатура, иногда была поддержка QWERTY.
Внешние шины: почти всегда был доступен UART, причём его можно было свободно взять прямо с платы — он был явно подмечен! Взять GPIO с проца не выйдет (кроме, возможно, вибромотора), SPI и I2C также напрямую недоступны. Внешние шины можно реализовать с помощью UART через GPIO-мост из микроконтроллера.
В итоге мы получаем очень неплохие характеристики для устройства, которое сочетает в себе сразу всё. На базе такого девайса можно сделать и сигнализацию, и HMI-дисплей с интерфейсом для управления каким-нибудь устройством, и игровую консоль с эмуляторами… да на что фантазии хватает! И это за какие-то 200-300 рублей, если мы говорим о б/у устройстве или 600 рублей, если говорим о новом. Это дешевле, чем собирать девайс с подобным функционалом самому из готового МК (например, RP2040) и отдельных модулей. Кстати, дешевые 2.4" дисплеи на алике — это ни что иное, как невостребованные остатки дисплеев для подобных китайских телефонов на складах! А вы думали, откуда там значки на тачскрине снизу?
Однако в рамках данной статьи мы не будем ограничиваться лишь теорией и на практике напишем примитивную 2D-игрушку, которая будет работать сразу на трех платформах без каких-либо изменений в коде самой игры: Windows, MRP (Mythroad) и VXP. Но для того, чтобы достигнуть такого уровня абстракции от платформы, нам необходимо написать рантайм, который оборачивает все необходимые платформозависимые функции для нашей игры.
Игрушка будет простой: 2D скролл-шутер с видом сверху, а-ля Asteroids. Летаем по космосу, и стреляем по враждебным корабликам, стараясь не попасть под вражеские лазеры. Всё просто и понятно :)
❯ Практическая часть: Кроссплатформенный рантайм
Итак, что нам необходимо от абстракции для такой простой игры? Давайте посмотрим:
Графика: очистка экрана, отрисовка спрайтов с прозрачностью (без альфа-блендинга, только колоркей), отрисовка текста. При возможности, желательно использовать нативное API системы для рисования графики, а не городить собственный блиттер. Формат пикселя фиксирован: RGB565 (65к цветов).
Ресурсы: хранятся в одном образе с основной игрой. Фактически, все ресурсы упакованы в виде обычных массивов байт в заголовочных файлах. Я пользуюсь вот этой тулзой для конвертации спрайтов в массивы байтов.
Звук: воспроизведение хотя-бы одного WAV-потока. Почему одного? Потому что далеко не на всех платформах есть доступ к аппаратному микшеру… да и вообще не везде есть прямой доступ к PCM (привет MRP), иногда разработчики ограничиваются лишь одним каналом для WAV-звука без возможности воспроизведения нескольких аудиофайлов одновременно.
Ввод: абстракция от клавиатуры классического моноблока: стрелки, OK, левый и правые софткеи.
Стандартная библиотека: не на всех платформах можно вызывать функции напрямую из stdlib. Как минимум в MRP и, например, «эльфах» для Motorola, нет возможности вызывать аллокатор, rand и некоторые другие функции из обычных заголовочников стандартной библиотеки. На таких платформах, системные инклуды дефайнами подменяют стандартные функции на своих реализации:
#define malloc system_alloc
#define free system_free
Но если у нас игра кроссплатформенная, то и платформозависимые инклуды мы использовать не будем.
Выглядит всё достаточно просто, верно? Примерно такого набора функций хватит для нашей игры:
❯ Win32
Давайте же перейдем к реализации рантайма на каждой платформе по отдельности. Начнём с Win32, поскольку адекватно отлаживать игру можно только на ПК.
На десктопе у нас будет фиксированное окно 240x320, в качестве GAPI будет использоваться аппаратно-ускоренный OpenGL, а для обработки ввода будет использоваться классически GetAsyncKeyState. Реализация точки входа, создания окна и инициализации контекста GL и главного цикла приложения у нас такая:
Реализация отрисовки спрайтов очень примитивная — OGL 1.0, полностью FFP, вся отрисовка — это 2 треугольника, формирующие квад. Спрайт заливается при первом использовании в текстуру, последующие кадры реюзается уже готовая текстура. Фактическая реализация всего рендерера — т. е. функций для рисования «просто картинок», без поддержки атласов, блендинга цветов (З.Ы - длинные листинги будут на пастбине, на Пикабу нет нормального тега для кода):
С вводом тоже всё просто. Есть биндинг кнопок клавиатуры к кнопкам на кейпаде телефона. inGetKeyState предполагается вызывать один раз за кадр, поэтому функция опрашивает ОС о состоянии нажатых кнопок на клавиатуре и назначает состояние виртуальных кнопок относительно состояния физических кнопок на клавиатуре.
Результат:
❯ MiniJ
Переходим к реализации рантайма для первой китайской платформы — MRP. Обратите внимание — я использую нативное API платформы для рисования спрайтов. Связано это с тем, что софтварный блиттер работает невероятно медленно даже с прямым доступом к скринбуферу устройства, а в чипсете предусмотрена отдельная графическая подсистема с командбуфером для быстрой отрисовки примитивов и графики:
SDK для MRE можно найти здесь (SKYSDK.zip): оно уже пропатчено от необходимости покупки лицензии. MRP не развивается более 10 лет, поэтому, думаю, его можно считать Abandonware. Компилятор находится в compiler/mrpbuilder.NET1.exe. За китайские SDK в публичном доступе нужно поблагодарить пользователя 4pda AjlekcaHgp MejlbHukoB, который раздобыл их на всяких csdn и выложил в свободный доступ :)
У MRP собственная система сборки, основанная на конфигурациях. Поскольку MRP может работать на устройствах с разными платформами и размерами дисплеев, под каждую можно настроить свой конфиг, который пережмет ресурсы в нужный формат. Дабы ничего не ломать, я заюзал абсолютные пути:
Компиляция приложения:
mrpbuilder.net1.exe game.mpr
Начинаем с функций обработки событий и инициализации, которые вызывает рантайм при старте приложения: mrc_init вызывается при старте приложения, а mrc_event при возникновении события. Вся инициализация очень простая: создаём таймер для обновления и перерисовки состояния игры и вызываем инициализацию игры:
С вводом тоже никаких проблем нет, нажатия кнопок прилетают как события в mrc_event. Переводим кейкоды MRE в наши кейкоды и сохраняем их состояние:
Опять же, отлаживать MRP-приложение под реальным устройством проблематично, поэтому платформозависимый код должен быть минимальным. Кроме того, обратите внимание, что некоторые функции в MRP зависят от библиотек-плагинов. Линкер слинкует вашу программу, но на реальном устройстве их вызов вывалится в SIGSEGV и софтресет устройства. Также нельзя использовать ничего из стандартной библиотеки именно в стандартных заголовочниках (т. е. stdlib.h, string.h и т. д.), часть стандартной библиотеки реализовывается MRP и дефайнится в mrc_base.h
Что интересно, защиты памяти толком нет. Если приложение падает в SIGSEGV или портит память — систему, судя по всему, ребутит Watchdog. Защиты памяти никакой, можно напрямую читать и писать в память ядра, а также писать в регистры периферии чипсета. jpegqs, покумекаем над этим? :)
Переходим к рендереру. Тут буквально две функции, gClearScreen очищает экран, а gDrawBitmap рисует произвольный спрайт с форматом пикселя RGB565. В качестве ROP используется BM_TRANSPARENT — таким образом, mrc_bitmapShowEx будет использовать левый верхний пиксель в качестве референсного цвета для реализации прозрачности без альфа-блендинга.
voidgDrawBitmap(CBitmap* bmp, int x, int y) {
mrc_bitmapShowEx((uint16*)bmp->pixels, x, y, bmp->width, bmp->width, bmp->height, BM_TRANSPARENT, 0, 0);
}
Да, всё вот так просто. Рантайм теперь запускается на реальных китайских девайсах и работает стабильно.
❯ VXP
Теперь переходим к VXP — платформе не менее неоднозначной, чем MRP. Пожалуй, начать стоит с того, что VXP существует аж в трёх версиях: MRE 1.0, MRE 2.0 и MRE 3.0. В MRE 2.0 и выше появилась поддержка плюсов (в MRE 1.0 только Plain C) и довольно интересного GUI-фреймворка, MRE 1.0 же предлагает реализовывать гуй самому. Платформа распространена на большинстве кнопочных телефонов и смарт-часиков на чипсетах MediaTek, примерно начиная с 6235 и заканчивания 6261D. SDK можно скачать вот здесь (см MRE_SDK_3.0).
VXP сам по себе более функционален чем MRE, поскольку ориентирован исключительно на телефоны с чипсетами MediaTek. Но что самое приятное — есть доступ к уарту без каких либо костылей! То есть, если сделать GPIO-мост на условной ESP32, то мы можем получить готовый мощный МК с клавиатурой, кнопками, дисплеем, звуком и т. д. Звучит не хило, да? Кроме того, у нас есть доступ и к BT, и к GPRS, и к SMS без каких либо ограничений.
Однако в бочке мёда нашлась и ложка дёгтя: для компиляции MRE-приложений необходимо накатывать и крякать довольно старый компилятор ADS, который сам по себе поддерживает только C89 (например, нет возможности объявить переменную в объявлении цикла или середине функции, только в начале, как в Pascal). ADS уже вроде как Abandonware, так что это вроде не наказуемо… но всё равно неприятно.
Кроме того, на некоторых девайсах (в основном, фирменных Nokia а-ля 225), прошивка требует подписи у всех бинарников, либо если бинарник отладочный, то должна быть привязка к конкретному IMSI.
К тому же, каждая программа должна фиксированно указывать в заголовке, сколько Heap-памяти ей необходимо выделить. Оптимальный вариант — ~500Кб, тогда приложение запустится вообще на всех MRE-телефонах.
Зато у VXP есть адекватный симулятор под Windows. Но зачем он нам, если у нас порт игры под Win32 есть? :)
Начинаем с инициализации приложения. В процессе вызова точки входа, приложение должно назначить обработчики системных событий, коих бывает несколько. Для обработки ввода и базовых событий хватает всего три: sysevt (события окна), keyboard (физическая клавиатура. Есть полная поддержка QWERTY-клавиатур), pen (тачскрин).
Переходим к обработчику системных событий. Обратите внимание, что MRE-приложения могут работать в фоне, из-за чего необходимо ответственно подходить к созданию и освобождению объектов. Что важно усвоить с самого начала — в MRE нет понятия процессов и защиты памяти, как на ПК и полноценных смартфонах. Любая программа может попортить память или стек ОС, более того, программа использует аллокатор остальной системы, поэтому если ваша программа не «убирает» после себя, данные останутся в памяти со временем приведут к зависанию. Впрочем, WatchDog делает свою работу быстро и приводит телефон в чувство (софтресетом) за 1-2 секунды. Но как и в случае с MRE, есть приятный бонус: прямой доступ к регистрам чипсета :)
Переходим к обработке событий с кнопок. Тут всё абсолютно также, как и на MRE, лишь имена дейфанов поменялись :)
И наконец-то, к графике! Пожалуй, стоит сразу отметить, что более 20-30 FPS на большинстве устройств вы не получите даже с прямым доступом к фреймбуферу. Похоже, это связано с тем, что в MRE довольно замороченная графическая подсистема с поддержкой альфа-канала (только фиксированного во время вызова функции отрисовки картинки/примитивов, сам пиксельформат всегда RGB565) и нескольких слоев. Кроме того, похоже есть ограничения со стороны контроллера дисплея.
Изначально, MRE предполагает то, что все картинки в программе хранятся в формате… GIF. Да, весьма необычный выбор. Однако для работы с пользовательской графикой, есть возможность блиттить произвольные картинки напрямую из RAM. Вот только один нюанс — посмотрите внимательно не объявление следующей функции:
dst_disp_buf — это целевой RGB565-буфер. Логично предположить, что и src_disp_buf — тоже обычный RGB565-буфер! Но как бы не так. Документация крайне скудная, пришлось посидеть и покумекать, откуда в обычном 565 буфере возьмется индекс кадра. С подсказкой пришёл пользователь 4pda Ximik_Boda — он скинул структуру-заголовок, которая идёт перед началом каждого кадра. В документации об этом не сказано ровным счетом ничего!
Сначала я реализовал софтовый блиттинг, но он безбожно лагал. Мне стало интересно, почему нативный blt быстрее и… вопросы отпали после того, как я поглядел в ДШ чипсета: тут есть аппаратный блиттинг. И даже с ним девайс не может выдать более 20FPS!
Для реализации более-менее шустрого вывода графики, необходимо сначала создать канвас (фактически, Bitmap в MRE), создать и привязать к нему layer, получить указатель на буфер слоя и только потом скопировать туда нашу картинку. Да, вот так вот замороченно:
И только после этого всё заработало достаточно шустро :) В остальном же платформа довольно неплохая. Да, без болячек не обошлось, но всё же перспективы вполне себе есть.
На данный момент, этого достаточно для нашей игры.
❯ Пишем геймплей
Рантайм у нас есть, а значит, можно начинать писать игрушку. Хоть пишем мы на Plain-C, я всё равно из проекта в проект использую +- одну и ту же архитектуру относительно системы сущностей, стейтов и т. п. Поэтому центральным объектом у нас станет CWorld, который хранит в себе на пулы с указателями на другие объектами в сцене, а также игрока и его состояние:
Система стейтов простая и понятная — фактически, между состояниями передавать ничего не нужно. При нажатии в главном меню на «старт», нам просто необходимо проинициализировать мир заново и начать геймплей, при смерти игрока — закинуть его обратно в состояние меню. Стейты представляют из себя три указателя на функции: переход (инициализация), обновление и отрисовка.
typedefvoid(CGameStateCallback)();
Поскольку мы хотим некоторой гибкости при создании новых классов противников, то вводим структуру CEnemyClass, которая описывает визуальную составляющую врагов и их флаги — могут ли они стрелять по игроку или просто летят вниз (астероиды), как они передвигаются (зигзагами например) и т. п.
Всё! Для текущего уровня реализации игры этого достаточно :) Переходим к реализации игровой логики. Вообще, динамический аллокатор в играх для китайских платформ лучше использовать как можно меньше. Heap'а довольно мало (~600Кб), да и не совсем понятно, как этот аллокатор реализован, есть вероятность, что используется аллокатор и куча основной ОС.
Начинаем с реализации полёта кораблика. Для этого он должен реагировать на стрелки и не улетать за границы экрана, а ещё для красоты он должен «вылетать» из нижней границы экрана при старте игры:
Переходим к динамическим пулам с объектами. Как вы уже заметили, их всего два — враги и летящие снаряды. Реализация спавна врагов/снарядов простая и понятная: мы обходим каждый элемент пула, если указатель на объект не-нулевой, значит объект всё ещё жив и используется на сцене. Если нулевой — значит ячейка свободна и можно заспавнить новый объект:
При обходе пула во время обновления кадра, мы обновляем состояние каждого объекта и если его функция Think вернула true, значит объект больше не нужен и его нужно удалить:
if (enemyThink(world.enemyPool[i]))
{
sysFree(world.enemyPool[i]);
world.enemyPool[i] = 0;
}
А вот и реализация Think:
boolenemyThink(CEnemy* enemy) {
enemy->y += enemy->_class->speed;
if (enemy->y > gGetScreenHeight() || enemy->health <= 0) return true;
return false;
}
Но кораблики должны же откуда-то появляться! Для этого у нас есть переменная nextSpawn, которая позволяет реализовать самый простой тип спавнера — относительно времени (или в нашем случае тиков):
world.nextSpawn--;
if (world.nextSpawn < 0) {
CEnemy* enemy = spawnEnemy(&enemyClasses[0]);
world.nextSpawn = randRange(40, 70);
}
Результат: мы уже можем полетать, пострелять и поуворачиваться от вражеских корабликов!
Уже что-то напоминающее игру! Осталось лишь добавить подсчет очков, менюшку, разные виды противников, возможно какие-то бонусы и у нас будет готовая простенькая аркада. В целом, выше приведена достаточно неплохая архитектура для простых 2D-игр на Plain C. Фактически, она может быть хорошей базой и для ваших игр: в теме о китах на 4pda я встречал немало людей, которые банально не знали, с чего начать.
❯ Что у нас получилось?
Но без тестов на реальных устройствах материал не был бы таким интересным! Поэтому давайте протестируем игру на двух реальных телефонах, как вы уже догадались, один — Nokla TV E71, а второй — клон Nokia 6700, который подарил мне мой читатель Никита.
На TV E71 игра идёт не сказать что очень бодро. Кадров 15 точно есть, что, учитывая разрешение 240x320, весьма неплохо для такого девайса.
а 6700,, даже учитывая более низкое разрешение — 176x220, дела примерно также — ~15FPS! Но поиграть всё равно можно. Уже хотите написать «автор наговнокодил, а теперь ноет из-за низкого FPS»? Ан-нет, я попробовал игры сторонних разработчиков — они идут примерно также :( К сожалению, таковы аппаратные ограничения устройства.
Исходный код игры с Makefile'ами и файлами проектов для Visual Studio и MRELauncher доступны на моём GitHub. Свободно изучайте и используйте его в любых целях :)
❯ Заключение
Но в остальном же, демка получилась довольно прикольной, как и сам опыт программирования для китайских телефонов. В общем и целом, китайцы пытались максимально упростить API и привлечь разработчиков к своей платформе. Если ради примера взглянуть на API для Elf'ов на Motorola, можно ужаснуться от state-based архитектуры платформы P2K. А тут тебе init, event, draw — и всё!
Но популярности помешала непонятная закрытость платформы, костыльный запуск программ, отсутствие нормального симулятора. А ведь сколько фишек было: даже возможность писать и читать память ядра! А вы как считаете? Можно ли вдохнуть в китайские кнопочники новую жизнь, узнав о наличии возможности запуска нативного кода на них?
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады! Да и чего уж там говорить: эта статья уже сама по себе весьма наглядный пример! Найти меня можно в комментариях тут, на Пикабу, и в тг @monobogdan
Понравился материал? У меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Полезный материал?
Были ли у вас такие китайчики?
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!