Сам себе Linux смартфон: Как я выкинул Android и написал свою прошивку с нуля

К огромному сожалению, старые смартфоны всё чаще и чаще находят своё пристанище в мусорном баке. К прошлым, надежным «друзьям» действует исключительно потребительское отношение — чуть устарел и сразу выкинули, словно это ненужный мусор. И ведь люди даже не хотят попытаться придумать какое-либо применение гаджетам прошлых лет! Отчасти, это вина корпораций — Google намеренно тормозит и добивает довольно шустрые девайсы. Отчасти — вина программистов, которые преследуют исключительно бизнес-задачи и не думают об оптимизации приложений совсем. В один день я почувствовал себя Тайлером Дёрденом от мира IT и решил бросить вызов проприетарщине: написать свою прошивку для уже существующего смартфона с нуля. А дабы задачка была ещё интереснее, я выбрал очень распространенную и дешевую модель из 2012 года — Fly IQ245 (цена на барахолках — 200-300 рублей). Кроме того, у этого телефона есть сразу несколько внешних шин, к которым можно подключить компьютер или микроконтроллер, что даёт возможность использовать его в качестве ультрадешевого одноплатника для DIY-проектов. Получилось ли у меня реализовать свои хотелки? Читайте в статье!

Честно сказать, идея попытаться реализовать свою прошивку мне пришла ещё давно. Однако, дабы не завлекать опытного читателя кликбейтом, я сразу поясню, в чём заключается «прошивка с нуля»:

Мы всё ещё используем Linux: в качестве ядра мы продолжаем использовать образ Linux, предоставленный нам производителем. Написание прошивки полностью с нуля заняло бы очень много времени (особенно без схемы на устройство). Однако, мы вообще не загружаем Android никаким образом.
Мы не используем библиотеки AOSP: наша прошивка без необходимости не использует никаких библиотек уже имеющегося образа Android. Вся работа с железом происходит с помощью низкоуровневого API Linux. Это значит, что отрисовка графики, звук, управление ресурсами и питанием ложится полностью на нас.
Прошивка может запускать только нативные программы: да, это тоже камень в сторону Android. Изначально, наша прошивка умеет запускать только нативные программы, написанные на C. Причём она экспортирует собственное C API — дабы приложения могли использовать всю мощь нашего смартфона в виде простого и понятного набора методов.

Проектов по выкидыванию Android из, собственно, Android-смартфонов как минимум несколько: UBPorts — бывший Ubuntu Touch, FireFox OS и его наследник Kai OS и конечно же, postmarketOS. Отчасти можно сюда отнести и Sailfish OS — но там образы имеются в основном на смартфоны от Sony. Все эти проекты объединяет сложность портирования и невозможность их завести на устройствах без исходного кода ядра. Даже если у вас есть исходный код ядра, но, например, устройство использует ядро 2.6 — навряд-ли вы сможете завести современный дистрибутив на нём.Другой вопрос в том, что можно использовать полу-baremetal подход, когда от Linux берется практически минимальный функционал. Всё, что мы имеем — busybox, libc и низкоуровневый доступ к железу, благодаря API самого ядра. Как под это всё программировать — я рассказывал в прошлой статье. Этот же подход мы будем использовать и сейчас — как иллюстрация реальногшо применения подобного способа.Итак, что наша прошивка должна уметь:

Отрисовывать произвольную графику: графическая подсистема нашей прошивки должна работать с фиксированным форматом пикселя, уметь загружать прозрачные и непрозрачные изображения, отрисовывать картинки с альфа-блендингом и т. п.
Уметь звонить и работать с модемом: общение с модемом происходит посредством AT-команд — общепринятого в индустрии стандарта. Однако в случае нашего устройства, есть м-а-а-а-ленький нюанс, о котором я расскажу позже.
Иметь механизм приложений: мы ведь не будем хардкодить все «экраны» в прошивке в виде кучи стейтов, верно? Для этого у нас должен быть простой и понятный механизм слинкованных с прошивкой приложений.
Обрабатывать ввод: обработка тачскрина и жестов — это задача подсистемы ввода.
Реализовывать анимированный UI: здесь всё очевидно, наша прошивка должна иметь готовые элементы пользовательского интерфейса для будущих приложений: кнопки, текстовые поля и т. д. О деталях реализации этой подсистемы, я расскажу ниже (а реализовал я её очень необычно для такой системы).

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

В качестве смартфона для нашего проекта, я выбрал популярную бюджетную модель из 2012 года — Fly IQ245 Wizard. Это простенький китайский смартфон, который работал на базе популярного в прошлом 2G-чипсета: MediaTek MT6573, да и стоил около 2х тысяч рублей новым. Однако вот в чём суть: мне удалось заставить работать «медиатековский» модем и даже позвонить с него на свой основной телефон, но… только ввод и вывод данных из звукового тракта модема происходит через звуковую подсистему Android — к которой доступа у нас нет!

Именно поэтому, мы идём на очень хитрый и занимательный костыль: мы распаяем внешний модем сами! В качестве радиомодуля у нас выступит модуль SIM800 от компании SIMCOM. И даже он очень близок к нашему смартфону в аппаратном плане: ведь в основе этого модуля лежит популярнейший чипсет из кнопочников тех лет: MediaTek MT6261D. Преимущество SIM800 в его цене — он стоит пару сотен рублей, так что по карману выбор модема не влияет.

На весу паять крайне неудобно. В финальном варианте перепаяю нормально.

Но как его подключать? SIM800 общается с другими устройствами посредством протокола UART — универсальный асинхронный приемо-передатчик. И вот тут мы включаем смекалочку. Разбираем устройство и видим то, что я пытаюсь долгое время донести до моих читателей — аж два канала UART: один практически посередине, второй справа. Нам нужны пятачки TXD4 и RXD4:

Обычно на этот канал UART летят логи ядра, которые можно без проблем отключить минорной правкой U-Boot в HEX-редакторе. Впрочем, модем никак не реагирует на «мусор» из консоли и просто отвечает ошибками — хватит лишь очистить буфер сообщений для того, чтобы все работало нормально. Подпаиваемся к UART'у с помощью преобразователя — у меня оным выступает ESP32 с выпаянным чипом.

Увидели логи? Замечательно, пора попытаться что-то отправить на ПК и с ПК. UART работают без тактовых сигналов и зависит исключительно от старт/стоп битов и бодрейта, который на устройствах MediaTek равен 921600. TXD4 и RXD4 обнаруживаются в системе на консоли /dev/ttyMT3. Пробуем что-то отправить: всё работает!

Вот теперь-то можно подключить наш внешний модем и попытаться пообщаться с ним, отправив тестовую команду AT. Модем отвечает OK! На этот раз я работаю с смартфоном из режима Factory mode — практически тоже самое, что и режим recovery, но позволяющий, например, получить доступ к камере устройства. Простая и понятная схема, поясняющая что и куда подключать:

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

На этот раз я решил загружать смартфон из режима рекавери. Однако никто не мешает в будущем просто прошить раздел recovery вместо boot и получить прямую загрузку прямо в нашу прошивку. Время такой загрузки будет заниматься ~3-4 секунды с холодного старта. Очень даже ничего.

Я взял уже готовый образ TWRP для своего смартфона и пропатчил его, дабы сам рекавери не мешал своим интерфейсом. Для этого я распаковал образ recovery.img с помощью MtkImgTools и убрал в init.rc запуск службы /sbin/recovery. После этого, я залил прошивку обратно на устройство и получил подобную свободу действий — консоль через USB и чистый холст в виде смартфона! Старые смартфоны на чипсетах MediaTek шьются через USB только после замыкания тест-поинта — на моем аппарате его местонахождение очевидно. Замыкаем контакты между собой, подключаем смартфон без АКБ к ПК и ждем прошивки:

Теперь можно деплоить программы! Важный нюанс: в отличии от Makefile из прошлой статьи, для Android 2.3 параметр -fPIE нужно убрать — иначе динамический линкер (/sbin/linker) будет вылетать в segmentation fault.

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

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

В случае с этим устройством (и большинством старых устройств), формат пикселя оказался RGB565 — т. е. 5 бит красный, 6 бит зеленый, 5 бит синий. Конвертация форматов пикселей всегда была занозой в заднице для программных рендереров, поскольку занимает дополнительное время, которое обратно зависимо от размера дисплея. Изначально я решил выделить буфер в том же формате, что и фреймбуфер, но затем решил сделать классический и самый портативный формат — RGB888 (24х-битный цвет), а при копировании кадра на экран, на лету делать преобразования цвета:

void CGraphics::Flip() { for(int i = 0; i < fbDesc.width; i++) { for(int j = 0; j < fbDesc.height; j++) { short* absPixel = (short*)&fbDesc.pixels[(j * fbDesc.lineLength) + (i * 2)]; char* absBackPixel = &backBuffer[(j * fbDesc.width + i) * 3]; short c16 = ((absBackPixel[0] & 0b11111000) << 8) | ((absBackPixel[1] & 0b11111100) << 3) | (absBackPixel[2] >> 3); *absPixel = c16; } } // We should pass a bit changed VSCREENINFO structure back to FB driver, to make it update our screen // This seems like a bit non-standard behaviour, because Android recovery uses this too: probably, something to save power. flip = !flip; vInfo.yres_virtual = (int)flip; ioctl(fbDev, FBIOPUT_VSCREENINFO, &vInfo); }

Очень важный нюанс, который я не упомянул в предыдущей статье: на устройствах прошлых лет для обновления фреймбуфера необходимо послать структуру var_screeninfo, где хотя бы что-то изменено, иначе никаких изменений мы не увидим. Этот же костыль используется в родном recovery для отрисовки, а судя по исходникам драйвера fb, «правильный» способ обновить экран — послать драйверу ioctl (который я пока что не пробовал).

После того, как я смог управлять дисплеем, я решил загрузить и отобразить какую-нибудь картинку. Пусть это будут обои для нашей прошивки:

FILE* f = fopen(fileName, "r"); LOGF("Loading %s\n", fileName); if(!f) { LOGF("Unable to open %s\n", fileName); return 0; } CTgaHeader hdr; fread(&hdr, sizeof(hdr), 1, f); if(hdr.paletteType) { LOG("Palette images are unsupported\n"); return 0; } if(hdr.bpp != 24 && hdr.bpp != 32) { LOG("Unsupported BPP\n"); return 0; } unsigned char* buf = (unsigned char*)malloc(hdr.width * hdr.height * (hdr.bpp / 8)); if(!buf) { LOG("Memory exhausted\n"); return 0; } //fseek(f, hdr.headerLength, SEEK_SET); fread(buf, hdr.width * hdr.height * (hdr.bpp / 8), 1, f); fclose(f); CImage* ret = new CImage(); ret->Width = hdr.width; ret->Height = hdr.height; ret->Pixels = buf; ret->IsTransparent = hdr.bpp == 32; LOGF("Loaded %s %ix%i\n", fileName, ret->Width, ret->Height); return ret;

Загрузчик TGA сильно не поменялся: я таскаю его в неизменном виде из проекта в проект. Он поддерживает любые форматы пикселя, кроме палитровых, но я его искусственн ограничиваю на RGB888 и RGBA8888 — для поддержки обычных картинок и картинок с альфа-каналом. После этого, я написал не очень шустрые, но достаточно универсальные методы для отрисовки картинок:

__inline void __ClipPrimitive(CFrameBuffer* fbDesc, int* dw, int* dh) { if(*dw > fbDesc->width) *dw = fbDesc->width - 1; if(*dh > fbDesc->height) *dh = fbDesc->height - 1; } void CGraphics::PutPixel(int x, int y, CColor color) { if(x < 0 || y < 0) return; char* col = &backBuffer[(y * fbDesc.width + x) * 3]; col[0] = color.R; col[1] = color.G; col[2] = color.B; } void CGraphics::PutPixelAlpha(int x, int y, CColor color, float alpha) { if(x < 0 || y < 0) return; char* col = &backBuffer[(y * fbDesc.width + x) * 3]; col[0] = (byte)(color.R * alpha + col[0] * (1.0f - alpha)); col[1] = (byte)(color.G * alpha + col[1] * (1.0f - alpha)); col[2] = (byte)(color.B * alpha + col[2] * (1.0f - alpha)); } void CGraphics::DrawImage(CImage* img, int x, int y) { if(img) { if(!img->IsTransparent) { for(int i = 0; i < img->Height; i++) { for(int j = 0; j < img->Width; j++) { if(j >= fbDesc.width) break; CColor col; unsigned char* pixels = &img->Pixels[((img->Height - i - 1) * img->Width + j) * 3]; col.R = pixels[2]; col.G = pixels[1]; col.B = pixels[0]; PutPixel(x + j, y + i, col); } if(i >= fbDesc.height) break; } } else { for(int i = 0; i < img->Height; i++) { for(int j = 0; j < img->Width; j++) { if(j >= fbDesc.width) break; CColor col; unsigned char* pixels = &img->Pixels[((img->Height - i - 1) * img->Width + j) * 4]; col.R = pixels[2]; col.G = pixels[1]; col.B = pixels[0]; float alpha = (float)pixels[3] / 255; PutPixelAlpha(x + j, y + i, col, alpha); } if(i >= fbDesc.height) break; } } } }

PutPixel желательно заинлайнить в будущем. В целом, сама отрисовка работает достаточно быстро, но поскольку рендеринг выполняется на ЦПУ — рано или поздно мы упремся в количество картинок на экране. Есть некоторые оптимизации: например, непрозрачные картинки можно просто коприовать сканлайнами прямо в задний буфер.

Сразу же реализовываем методы для рисования шрифтов: они у нас будут совсем простенькими — только моноширинные (все символы имеют одинаковую ширину) и растровыми (для каждого размера придется «запекать» несколько шрифтов). Для этого я написал маленькую программку, которая рисует виндовые шрифты прямо в наш самопальный формат:

Console.WriteLine("FontBake for BodyaPhone"); Console.WriteLine("(C)2023 Bogdan Nikolaev"); if (args.Length > 0) { string fontName = args[0]; int glyphSize = 16; Font fnt = new Font(fontName, glyphSize, FontStyle.Bold, GraphicsUnit.Pixel); SolidBrush brush = new SolidBrush(Color.White); SolidBrush bg = new SolidBrush(Color.Magenta); Bitmap glyph = new Bitmap(glyphSize, glyphSize); Graphics g = Graphics.FromImage(glyph); g.TextRenderingHint = System.Drawing.Text.TextRenderingHint.ClearTypeGridFit; BinaryWriter writer = new BinaryWriter(File.Create(fontName)); writer.Write(glyphSize); // Glyph size byte[] glyphData = new byte[glyphSize * glyphSize * 3]; for(int i = 0; i < 255; i++) { g.FillRectangle(bg, 0, 0, glyphSize, glyphSize); g.DrawString(((char)i).ToString(), fnt, brush, PointF.Empty); var data = glyph.LockBits(new Rectangle(0, 0, glyphSize, glyphSize), System.Drawing.Imaging.ImageLockMode.ReadOnly, System.Drawing.Imaging.PixelFormat.Format24bppRgb); System.Runtime.InteropServices.Marshal.Copy(data.Scan0, glyphData, 0, glyphData.Length); glyph.UnlockBits(data); writer.Write(glyphData); } }

Формат примитивнейший:

1 байт говорит нам о размере шрифта и далее идут 255 изображений символов. Да, это не очень эффективно т.к попадают пустые символы из ASCII-таблицы, но в будущем это можно поправить.

Прозрачность в символах обеспечивает фоновый цвет Magena — ярко-розовый. Я не стал делать дополнительный альфа-канал, т. к. иначе будут серьезные лаги при выводе большого количества текста.

void CGraphics::DrawString(CFont* font, char* str, int x, int y) { CColor col = { 64, 64, 64 }; DrawStringColored(font, str, x, y, col); } void CGraphics::DrawStringColored(CFont* font, char* str, int x, int y, CColor colorMultiply) { if(font && str && strlen(str) > 0) { for(int i = 0; i < strlen(str); i++) { DrawGlyph(font->Glyphs[str[i]], x + (i * (font->Glyphs[str[i]]->Width - 5)), y, colorMultiply); } } }

Теперь у нас есть отображение картинок и текста! Что с этим можно сделать?

Конечно же, реализовать обработку ввода! Это будет фактически минимальный функционал, который можно использовать для создания UI-приложений. В дополнение к прошлой статье хочу отметить то, что разные драйверы тачскрина ведут себя по разному. На этом устройстве, драйвер тачскрина не сообщал событие BTN_TOUCH, из-за чего пришлось идти на некоторые ухищрения. Однако в конце-концов, метод для проверки касания пальца в определенном месте у меня есть:

void CInput::Update() { input_event ev; int ret = 0; bool gotEvent = false; // Touchscreen driver sends us events each input "frame". So, if we don't have BTN_TOUCH event, we can track releasing finger when there are no events in current frame. while((ret = read(evDev, &ev, sizeof(input_event)) != -1)) { if(ev.code == ABS_MT_POSITION_X) TouchX = ev.value; if(ev.code == ABS_MT_POSITION_Y) TouchY = ev.value; gotEvent = true; } bool pressed = gotEvent; if(pressed && TouchState == tsIdle) TouchState = tsTouching; if(TouchState == tsReleased) TouchState = tsIdle; if(!pressed && TouchState == tsTouching) TouchState = tsReleased; } bool CInput::IsTouchedAt(int x, int y, int w, int h) { return TouchX > x && TouchY > y && TouchX < x + w && TouchY < y + h && TouchState == tsReleased; }

Пока что здесь не хватает обработки «хардварных» кнопок — домой, меню, назад и т. п. Однако в будущем это всё можно реализовать!

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

Аниматор напоминает оный из ранних версий Android: он имеет фиксированный набор свойств, которые умеет интерполировать в промежутках определенного времени. Если простыми словами: то он оперирует линейными отрезками времени a и b, в промежутке которых мы имеем значение «прогресса» — которое даёт нам результат от 0.0f (начало анимации) до 1.0f (конец анимации). Пока время тикает до необходимого интервала (duration), аниматор интерполирует заранее назначенные ему поля до нужных значений.

Именно так и получается плавность! Похожим образом реализованы анимационные системы во многих играх и мобильных ОС, только там они гораздо более комплексны: есть сериализация/десериализация из файлов, поддержка кейфреймов (несколько последовательных состояний на одном промежутке времени), поддержка кастомных свойств и т. п.

CAnimator::CAnimator() { SetDuration(1.0f); } CAnimator::~CAnimator() { } void CAnimator::SetTranslation(int xFrom, int yFrom, int xTo, int yTo) { this->xFrom = xFrom; this->yFrom = yFrom; this->xTo = xTo; this->yTo = yTo; } void CAnimator::SetRotation(float from, float to) { rFrom = from; rTo = to; } void CAnimator::SetDuration(float speed) { duration = speed; } float lerp(float a, float b, float f) { return a * (1.0 - f) + (b * f); } bool CAnimator::Update() { Time += 0.25f; if(Time > 1.0f) Time = 1.0f; X = (int)lerp((float)xFrom, (float)xTo, Time); Y = (int)lerp((float)yFrom, (float)yTo, Time); Rotation = lerp(rFrom, rTo, Time); } void CAnimator::Run() { Time = 0; IsPlaying = true; }

Как я уже говорил раннее, работа с модемом происходит посредством AT-команд. Лучше всего обрабатывать ввод-вывод модема из отдельного потока, поскольку он может отвечать довольно медленно и тормозить UI-поток основной программы, вызывая лаги. В SIM800 уже реализован весь GSM-стек, в том числе декодирование и вывод звука через встроенный усилитель с фильтром — остается только подключить динамики и микрофон от нашего телефона. Пока что я подсобрал аудиотракт на том, что было под рукой — микрофон от нерабочего смартфона и динамик от планшета, но для проверки этого хватает:

Важный нюанс: по умолчанию, tty-устройства в Linux работают по терминальному принципу — т. е. дробят транзакции по символу окончания строки (\n), имеют ограниченный буфер и т. д. Для нормальной работы в условиях модема — когда фактически длина ответа неизвестна, а в сам ответ могут «вклиниваться» Unsolicited-команды (своеобразные флаги о состоянии от модема, которые могут прийти в произвольное время — т. е. при входящем звонке, модем начнёт флудить RING в терминал), необходимо иметь возможность точно прочитать весь буфер до конца и парсить данные «по месту». Для этого используется raw-режим терминала:

После чего можно запросить состояние модема:

char atBuf[16]; // Check modem presence SendAT("AT\r\n", 250); GetATResponse((char*)&atBuf, sizeof(atBuf)); if(!CheckATStatus((char*)&atBuf)) { printf("Failed to initialize modem: Modem isn't anwered OK\n"); printf("Modem response: %s\n", &atBuf); return; } LOG("AT = OK, ready to operate\n"); ... void CModem::SendAT(char* command, int waitTime) { int result = write(modemFd, command, strlen(command)); if(!result) LOGF("SendAT failed: %i\n", errno); usleep(waitTime * 1000); } char* CModem::GetATResponse(char* buf, int maxLen) { pollfd pfd; pfd.fd = modemFd; pfd.events = POLLIN; memset(buf, 0, maxLen); int ev = poll(&pfd, 1, 2000); if(ev) { int num = read(modemFd, buf, maxLen); } else { LOG("AT Receive: Modem not responding...\n"); } }

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

void CModem::Dial(char* number) { if(strlen(number) > 32) return; char buf[64]; char atResponse[64]; sprintf((char*)&buf, "ATD%s;\r\n", number); LOGF("Dialing %s\n", buf); SendAT(buf, 250); GetATResponse((char*)&atResponse, sizeof(atResponse)); LOGF("Dial response: %s\n", &atResponse); } void CModem::Hang() { char atBuf[64]; SendAT("ATH\r\n", 250); GetATResponse((char*)&atBuf, sizeof(atBuf)); LOGF("ATH: %s\n", &atBuf); LOG("Hang\n"); }

Пытаемся позвонить с помощью метода Dial и видим, что всё работает! Это очень круто! А теперь, конечно же, самое время переходить к реализации того, чего вы ждали — пользовательского интерфейса!

К выбору концепции для интерфейса, я поступил максимально просто — «слизал» дизайн первых версий iOS. Как по мне, это одни из самых красивых версий iOS вообще — все эти приятные градиенты и переливания. Конечно, я не так крут, как инженеры Apple, да и мощного UI-фреймворка у меня пока что нет, поэтому я приступил к реализации с «минимальным» функционалом.

Начал я с разделения главного экрана на модули и продумывания архитектуры основного «лаунчера». У нас есть статусбар, который рисуется поверх всех приложений, полка с приложениями — AppDrawer и сами экраны приложений, унаследованные от суперкласса CScreen.

class CScreen { protected: CAnimator* windowAnimator; public: CScreen(); ~CScreen(); virtual void Show(); virtual void Update(); virtual void Draw(); virtual void Hide(); };

На данный момент, отрисовка достаточно примитивная: сначала рисуются фоновые обои, затем, если нет никаких активных экранов — AppDrawer и в самом конце рисуется статусбар и всевозможные оверлеи.

void CLauncher::DrawAppDrawer() { for(int i = 0; i < sizeof(Apps) / sizeof(CAppDesc*); i++) { int x = drawerAnimator->X + (i * 75); int y = drawerAnimator->Y; Graphics->DrawImage(Apps[i]->Icon, x, y); if(Input->IsTouchedAt(x, y, Apps[i]->Icon->Width, Apps[i]->Icon->Height)) { StartScreen(new CDialerScreen()); } } } void CLauncher::StartScreen(CScreen* screen) { if(screen) { currentScreen = screen; currentScreen->Show(); } } void CLauncher::Run() { CImage* test = CImage::FromFile("ui/stFiller.tga");; while(true) { Input->Update(); Graphics->DrawImage(Wallpaper, 0, 0); if(currentScreen) { currentScreen->Update(); currentScreen->Draw(); } else { drawerAnimator->Update(); DrawAppDrawer(); } Status->Update(); Status->Draw(); if(Dialog->IsVisible()) Dialog->Draw(); Graphics->Flip(); } }

Практически сразу я решил обкатать анимационную «систему» и добавить первые анимашки — выезжающий статусбар и анимация а-ля айфон:

animator = new CAnimator(); animator->SetTranslation(0, -imFiller->Height, 0, 0); animator->Run();

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

gLauncher->Graphics->DrawImage(imFiller, animator->X, animator->Y); gLauncher->Graphics->DrawImage(imBattery[(int)gLauncher->PowerManager->GetBatteryLevel()], imFiller->Width - imBattery[0]->Width - 5, animator->Y + 5); char timeFmt[64]; time_t _time = time(0); tm* _localTime = localtime(&_time); strftime((char*)&timeFmt, sizeof(timeFmt), "%R", _localTime); gLauncher->Graphics->DrawString(gLauncher->Font, (char*)&timeFmt, 0, 0);

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

#define APP_FACTORY(clazz) CScreen* __phone_factory_##clazz () { return new clazz (); } struct CAppDesc { char Name[16]; char IconPath[32]; CImage* Icon; CScreen* MainScreen; CScreen*(*Factory)(); }; ... CAppDesc _APhone = { "Phone", "ui/phone.tga", 0, 0, &__phone_factory_CDialerScreen };

После этого, я приступил к реализации первого приложений — собственно, звонилки. :)

#include <monohome.h> CDialerScreen::CDialerScreen() { dialerButton = CImage::FromFile("ui/dialer_btn.tga"); memset(&number, 0, sizeof(number)); } CDialerScreen::~CDialerScreen() { delete dialerButton; } void CDialerScreen::Update() { CScreen::Update(); } bool DialerButton(CImage* img, int x, int y, char* str) { bool state = CGUI::Button(img, x, y); gLauncher->Graphics->DrawString(gLauncher->Font, str, x + (img->Width / 2) - 8, y + (img->Height / 2) - 8); return state; } void CDialerScreen::Draw() { CScreen::Draw(); for(int i = 0; i < 3; i++) { for(int j = 0; j < 3; j++) { int num = i * 3 + j + 1; char buf[16]; memset(&buf, 0, sizeof(buf)); sprintf((char*)&buf, "%i", num); if(DialerButton(dialerButton, j * dialerButton->Width + 15, 65 + (i * dialerButton->Height) + windowAnimator->Y, buf)) { if(strlen((char*)&number) < 31) strcat((char*)&number, (char*)&buf); } } } if(DialerButton(dialerButton, 1 * dialerButton->Width + 15, 65 + (3 * dialerButton->Height) + windowAnimator->Y, "0")) { if(strlen((char*)&number) < 31) strcat((char*)&number, "0"); } if(DialerButton(dialerButton, 0 * dialerButton->Width + 15, 65 + (3 * dialerButton->Height) + windowAnimator->Y, "C")) { gLauncher->Modem->Dial((char*)&number); } gLauncher->Graphics->DrawString(gLauncher->Font, (char*)&number, 10, 48); }

Обратите внимание на удобство примененного подхода Immediate GUI. Нам понадобился новый элемент интерфейса, который описывает кнопку номеронабирателя? Мы просто реализовываем ещё один метод, который берет за основу стандартную кнопку и дорисовывает к ней текст. Всё крайне просто и понятно, хотя на данный момент слишком захардкожено. :)

Пришло время совершить первый звонок с нашей по настоящему кастомной прошивки. Набираем номерок и…

Да, всё работает и мы без проблем можем дозвониться :)

Конечно же, это далеко не весь функционал, необходимый любому современному смартфону. Здесь много чего еще нужно реализовать хотя бы для соответствия уровню бюджетных кнопочных телефонов: телефонную книгу, поддержку СМС/ММС, мультимедийный функционал с играми. Однако начало уже положено и самая необходимая часть модулей реализована. Этот проект очень занимательный для меня и я горд, что смог не на словах, а на деле показать вам, моим читателям, возможности моддинга совершенно NoName-устройств, без каких либо опознавательных знаков…

Моя задача заключается в том, чтобы показать вам возможности использования старых телефонов не только в потребительских, но и в гиковских DIY-сферах. Судите сами: огромный классный дисплей, емкостной тачскрин, готовый звук, камера — и всё это за каких-то пару сотен рублей. Главное показать людям, как всю эту мощь использовать в своих целях и делать совершенно новые устройства из существующих, а не выбрасывать их на помойку!Сейчас смартфоны, подобные Fly из этого поста стоят копейки, а портировать на них прошивку можно без каких-либо трудностей. Я очень надеюсь, что после этого поста читатели попытаются сделать что-то своё из старых смартфонов, благо свои наработки я выкладываю на GitHub!

Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и TimeWeb на DTF, чтобы не пропускать новые статьи каждый день!

Как вам проект?

Это очень круто и действительно нужно! Материал практически уникальный в своём роде. Продолжай пилить!21

Это вообще не круто, нафиг ты фигней маешься???

Автор наркоман

Как вам DIY-тематика в недавних статьях?

Платиновый контент от bodyawm и MDXE1337. Продолжай в том-же духе!

Вообще какашка! Отписался.

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

Безусловно есть!

Нет. Так и будут на свалке лежать :(

#monobogdan_ништячки #девайсы #гаджеты #android #смартфоны #моддинг #linux #unix #программирование #программирование_2D #программирование_графики #хакинг #iphone #apple #одноплатники #raspberry_pi #orange_pi

48 комментариев

FCR707

18.08.2023

Государство - нужно дополнительно 300 лярдов на свою ОС для смартфонов. Чел - дайте мне пару тысяч рублей и пару литров пива и я состряпаю вам ОС ))))

Ответить

Андрей

Есть подозрение, что в конце к этому и приходят. А весь бюджет теряется по пути.

Alex SSS

Такой кал как в статье и так уже давно сделан. Эту системы корпоративные клиенты используют

Слайс питцы

Ты думаешь они на разработку бабки тратят?

Haze

19.08.2023

Если ты про Аврору то это давно устоявшиеся ос, ведь этот продолжения симбиана

monobogdan Мобилкин-консолькин

Автор

Ну что-ж друзья, думаю этим материалам я показал вам, как можно на практике юзать смартфоны прошлых лет в качестве одноплатников. Могу и полноценный материал с мостом URAT -> GPIO написать. Интересует такое?

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

heitr

хех, компилятор чего-либо и терминал будешь делать?

Сам себе Linux смартфон: Как я выкинул Android и написал свою прошивку с нуля

❯ Мотивация

❯ Аппаратная часть

❯ Заставляем смартфон запускать нашу прошивку

❯ Графическая подсистема

❯ Обработка ввода

❯ Анимация

❯ Модем

❯ Главный экран

❯ Звоним!

❯ Заключение