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

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

❯ Мотивация

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

1. Мы всё ещё используем Linux: в качестве ядра мы продолжаем использовать образ Linux, предоставленный нам производителем. Написание прошивки полностью с нуля заняло бы очень много времени (особенно без схемы на устройство). Однако, мы вообще не загружаем Android никаким образом.
2. Мы не используем библиотеки AOSP: наша прошивка без необходимости не использует никаких библиотек уже имеющегося образа Android. Вся работа с железом происходит с помощью низкоуровневого API Linux. Это значит, что отрисовка графики, звук, управление ресурсами и питанием ложится полностью на нас.
3. Прошивка может запускать только нативные программы: да, это тоже камень в сторону 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-режим терминала:

tcgetattr(modemFd, &tio);     tio.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON);     tio.c_oflag &= ~(OPOST);     tio.c_cflag |= (CS8);     tio.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG); tcsetattr(modemFd, TCSAFLUSH, &tio);

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

        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!

Возможно, захочется почитать и это:

• ➤ Подключаем дисплей к любому одноплатнику с SPI: большой мануал о поиске экранчиков для ваших проектов
• ➤ Nokia N900 — легендарный Linux смартфон
• ➤ Простая разработка IoT приложений на C# для Raspberry Pi и других одноплатников, на Linux
• ➤ Как распутать уроборос роутинга в Linux
• ➤ История зарождения Linux — как это было?