Портирование тем для андроид

Портирование на Android

Портирование на Android

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

Движок

Движок (хобби) находится в разработке уже 10 лет.
Движок полностью написан на C/C++, до начала портации на Android поддерживал iOS и Windows.
Логика, рендеринг, звук — все на C/C++.

Файловая система

Важная особенность которая сделала портацию на Android очень простой — это файловая система движка.

Итак: вся работа с файлами в движке основана на интерфейсе IStream, архитектура движка поддерживает фабрику объектов, и её кастомизацию.

Ничего нового и все довольно стандартно.

Так как все ресурсы запрепроцесенны в .pak файл, то для Android системы пришлось написать свою реализацию IStream специально для работы с Java.

Инициализация данного ресурса на Java

Нейтив класс все вызовы open,read,seek транслирует опять в Java

Java реализации чтения данного стрима с возвратом данных назад в нейтив

Важный момент — сборщик apk сжимает все ресурсы, а мы хотим читать файл как будто он просто лежит в файловой системе. Для того чтобы наш .pak файл не сжимался внутри apk — вы должны сменить ему расширение на одно из тех которые будут говорить упаковщику не сжимать данные файлы при упаковке (детали ponystyle.com/blog/2010/03/26/dealing-with-asset-compression-in-android-apps). Я выбрал .imy.
Загрузка ресуров таким способом очень быстра, например на Kindle Fire работает быстрее чем на iPad 1
Оговорю стразу что такой финт можно провернуть если у вас не очень много данных.
Для большого объема данных — вы можете сами распаковать данные на внутрений носитель(например при первом запуске) и напрямую их использовать посредством функций fopen fread (в моем случае, через не подмененный FileStream) и.т.д.

Для Windows и iOS был использован OpenAL. OpenAL для Android был собран благодаря pielot.org/2010/12/14/openal-on-android. Заработал не сразу, а только после исправлений которые описаны в комментариях на вебсайте.
Сборка под Android собрана только для Arm v7 — потому что сборка порта под Arm v6 OpenAL иногда приводила к лагам, в iOS OpenAL микшер работает быстрее и без лагов (даже на ArmV6, например на iPod Touch 2G).

Взаимодействие с нативным кодом из С/C++

За обработку вызовов платформо зависимых реализаций отвечает очень простая связка классов
Псевдо код:

Для iOS своя реализация на Objective-C а для Android своя реализация на JNI->Java.

Рендеринг

Нейтив часть работает с использованием OpenGL, для Android были сделаны минимальные изменения. Как в последствии оказалось этого было недостаточно. Дело в том что на Windows и на iOS текстуры не теряются когда приложение уходит в бакграунд, а вот для Android это происходит всегда. В движке уже был менеджер текстур (в основном для отладки) и добавить перезагрузку ресурсов оказалось не сложно.

Сборка

В самой первой статье я писал о том, что изначально компилировал iOS с использованием toolchain и у меня были настроенные makefile. Вот тут то мне это и пригодилось. Были дописаны таргеты для сборки с использованием Android NDK, добавлен степ в билдеры Eclipse и все взлетело. Да, можно использовать билд систему из Android NDK samples. Её я использовал только для выяснения параметров которые используются для вызовов gcc.

OpenFenit AdMob

Интеграция обоих библиотек прошла без проблем — четко по инструкции разработчиков

Proguard

Тут все более или менее понятно — нужно только позаботится о том чтобы ваши JNI Native бинды не обускейтились

Средства разработки

Железо: Kindle Fire, и пару планшетов и мобильных телефонов друзей(для тестирования).
Софт: Eclipse с плагинами

Шок номер 1

Android Market это не AppStore. Там все по другому. Там нет категории New.
Для сравнения на AppStore в первый день релиза было 800+ скачек, во второй 2000+, на Andoid Market официальная первая сотня скачек была получена только на третий день. Активность по раскрутке для обоих платформ была одинакова

Шок номер 2

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

Шок номер 3

Бестиарий устройств велик. Количество проблем соответственно.

Amazon

Процесс ревью на Amazon AppStore for Android занимает неделю, плюс еще несколько дней пока приложение появится в списке AppStore на Kindle Fire. Количество скачек и динамика соответствует Android Market

Реклама

Лучи ненависти Корпорации Добра — уже неделя как рекламный баннер был отправлен на апрув. До сих пор тишина.

Деньги

На данный момент количество денег (напомню в игре только реклама) которые приносит iOS версия в 40 (сорок) раз больше чем версия для Android. Понятно, что сравнение не корректно и надо подождать как минимум еще пару месяцев пока не стабилизируется количество постоянных игроков в день.

UPDATE: В секции звука я описал причину сборки только для ArmV7 Android устройств.

Источник

Портирование тем для андроид

Портирование CyanogenMod 12.X — 14.X MTK6592 и MTK6582

• Фикс громкости на СМ 12.1
• Если громкость не регулируется на СМ 12.1
• Патч для звука на См 12.1
• Ещё один патч для звука на СМ 12.1
• Ещё один патч на звук на См 12.1
• Изменение параметров громкости звука без входа в инженерное меню
• Фикс микрофона (если не слышат Вас и не распознаёт голос голосовой поиск google) — распаковать в system\etc\ —audio_policy.zip ( 942 байт )

в радио не регулируется громкость — подбираем libaudioflinger.so

Не коннектится по usb с ПК — лечится заменой в рамдиске init.usb и init.mt6582.usb.

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

При перегрузке иногда отваливается сеть — лечится повторной перегрузкой

Вместо названия сети показывает номер — добавить файл selective-spn-conf.xml с работающей сборки (скачать можно тут)

Если в БТ гарнитуре не проигрывается музыка или БТ вообще не работает — подкинуть в hw либу audio.a2dp.default.so

Проблемы при приёме вызова при подключённых наушниках — рекомендуют при прослушивании музыки в наушниках включать вибро-режим — макросы для macrodroid (костыльный метод решения)

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

Сообщение отредактировал derak1129 — 01.11.21, 21:10

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

• для запуска прошивки необходима перепаковка бута с кернелом и проверка графики на mali mod
• Трогать либы в system нужно по минимуму. исключительно для запуска модулей. например если тронуть hv\bluetooth.default.so то можно потерять блюпуп совсем.
• для камеры обычно использую только
  lib\hv\camera.default.so
  lib\libcam.paramsmgr.so
  libcamdrv.so
  libcameracustom.so
  libfeatureio.so ну и строчки рамдиска init_mt6592.rc под #CAMERA само собой должны быть стоковыми.
• для работы большинства модулей селинукс должен быть разрешающим.
• Для работы модема стабильно работает подмена модема) etc\firmware
• Для того чтобы починить монтирование правлю в рамдиске: Fstab*, демон монтирования в init_mt6592.rc(внизу) и вначале права к разделам проставьте.
  так же нужно перепаковать апктуллом Framework-res.apk по пути res\xml\storage_list.xml(от стока файлик)

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

Ну а все остальное ищите в теме. Рекомендую только более менее опытным пользователям.

Источник

Портирование тем для андроид

Начнем. Вы, наверное, слышали, что в некоторых устройствах используется какая-то диковинная A/B структура разделов . Она отличается от структуры в большинстве Android устройств.
На ней как-то странно и непривычно устанавливаются обновления, прямо при работающей системе (O_o). Внутри OTA образов другая, нечитабельная структура. Установка TWRP сопровождается какими-то, раннее не встречаемыми, сложностями, дополнительными манипуляциями и значительно отличается от всего, что «я» раньше видел. Все говорят о каких-то буквах «А», «Б», слотах, двух и системах и прочих, непонятных «мне», вещах. Что же, давайте попробуем во всем этом разобраться.

Начнем с общих вопросов:
Q: Ну и кто все это придумал? Проклятые производители простым гикам жизнь усложняют?
A: Новая структура «A/B разделов» разработана непосредственно Google-ом как часть глобальных изменений в архитектуре Android. Она успешно используется в смартфонах Google Pixel, Essential Phone и различных других устройствах. В дальнейшем все больше устройств от сторонних производителей будут ее использовать. Ничего плохого и страшного в этом нет, наоборот, открывается много новых возможностей.

Q: Так что же из себя представляет A/B структура разделов?
A: Если говорить совсем просто — внутри вашего устройства расположены сразу две (а в зависимости от реализации и больше), независимые между собой, системы. Что-то на подобии MultiROM (если слышали о таком), только с гораздо более продуманной реализацией на более низком уровне. Если интересует конкретная информация с объяснением всех аспектов — прошу продолжить чтение.

Таблица разделов на примере Google Pixel:
Дабы наглядно отобразить, изложенную выше, теорию и увидеть отличия по сравнению с другими устройствами — познакомимся с таблицей разделов Google Pixel.
Если вы вообще не знакомы со структурой разделов в Linux-подобных системах, и Android в частности, — советую поискать информацию об этом в Google, благо ее полно.

Нас интересуют конкретные разделы, существующие в двух копиях для наглядности и демонстрации.
Итак (раскрываем код полностью):

/dev/block/bootdevice/by-name/aboot_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/apdp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/bootlocker_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/cmnlib32_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/cmnlib64_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/devcfg_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/hosd_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/hyp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/keymaster_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/msadp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/pmic_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/rpm_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/tz_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/xbl_a # Разделы первого загрузчика (Слот «a»)

/dev/block/bootdevice/by-name/aboot_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/apdp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/bootlocker_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/cmnlib32_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/cmnlib64_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/devcfg_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/hosd_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/hyp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/keymaster_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/msadp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/pmic_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/rpm_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/tz_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/xbl_b # Разделы второго загрузчика (Слот «b»)

/dev/block/bootdevice/by-name/modem_a # Раздел первого модема/радиомодуля (Слот «a»)
/dev/block/bootdevice/by-name/modem_b # Раздел второго модема/радиомодуля (Слот «b»)

/dev/block/bootdevice/by-name/boot_a # Раздел первого ядра (Слот «a»)
/dev/block/bootdevice/by-name/boot_b # Раздел второго ядра (Слот «b»)

/dev/block/bootdevice/by-name/vendor_a # Первый проприетарный раздел (Слот «a»)
/dev/block/bootdevice/by-name/vendor_b # Второй проприетарный раздел (Слот «b»)

/dev/block/bootdevice/by-name/system_a # Первый системный раздел (Слот «a»)
/dev/block/bootdevice/by-name/system_b # Второй системный раздел (Слот «b»)

Как видно из выдержки выше, — имеются два, независимых между собой, слота, а именно «группы разделов», которые содержат в себе основные, обновляемые компоненты прошивки.

Два представленных слота состоят из:
Bootloader (загрузчик) — 28 разделов (14 на каждый слот).
Radio/Modem (радиомодуль) — 2 раздела (по одному на слот).
Boot (ядро) — 2 раздела (по одному на слот).
Vendor (драйверы) — 2 раздела (по одному на слот).
System (система) — 2 раздела (по одному на слот).

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

Принципиальные отличия по сравнению с другими устройствами:
С дублированием разделов и, структурой в целом, разобрались. Однако, вы могли заметить (если просматривали полную таблицу разделов) отсутствие, привычных в любом устройстве, разделов «/recovery» и «/cache». Да, их действительно нет. Но могут и встречаться в отклонениях от нормы.

Q: Стоп. Но если раздела для Recovery нет, а сам Recovery есть (Он ведь есть, правда?), где же он находится?
A: Система восстановления (Recovery) включена в состав образа ядра (boot). А потому, наличие, отсутствие и тип установленного recovery напрямую зависят от ядра системы. Переключение в него (Recovery), как и раньше, осуществляется специальным флагом в «/misc» разделе.
Именно в этом и состоит загвоздка установки TWRP — его как-то нужно «засунуть» в ядро. Потому TWRP сначала временно загружают (устанавливать то его некуда), а затем уже из TWRP, специальным скриптом, на лету распаковывается ядро и вшивается в него TWRP. Такая же схема «перепаковки ядра на лету» применяется при получении «systemless» рут-прав через SuperSU и Magisk.

Q: Хорошо, а что же тогда случилось с «/cache» разделом?
A: В привычных устройствах он необходим лишь для хранения OTA обновлений и системных логов Recovery, в данном же случае, ввиду применения новой схемы этих самых обновлений (см. ниже), раздел стал попросту «не нужОн». Вот от него и избавились.

Ручное переключение слотов:
Естественно, помимо самих слотов, должен быть способ ручного взаимодействия с ними. И он есть. Для ручного переключения текущего активного слота необходимо воспользоваться утилитой fastboot. Команды:

Так же, переключится в другой слот можно в соответствующем пункте TWRP (Reboot -> Slot A / Slot B).

Итоги и положения:
1. Между слотами как система, так и сам пользователь могут переключаться.
2. Изначально (с завода) слоты полностью идентичны между собой. Различия появляются после применения любого OTA обновления системы.
3. Слоты изолированы между собой. Состояние и целостность одного слота никак не влияет на другой. За исключением применения OTA обновлений (см. ниже).

«Seamless» система обновлений:
Итак, с разделами и слотами разобрались. Но что же там с обновлениями, наверняка их тоже коснулись изменения, ввиду описанного выше?
Да, OTA обновления на устройствах с A/B структурой кардинально отличаются от того, что мы можем видеть на других устройствах.

Итоги и положения:
1. Все OTA обновления устанавливаются в неактивный, противоположный слот. То бишь — обновляется лишь один слот.
2. Все OTA обновления устанавливаются в фоновом режиме при рабочей системе, без перезагрузки устройства.
3. Все OTA обновления устанавливаются в два этапа «Шаги»: «Шаг 1» — Загрузка обновления. «Шаг 2» — Фоновое применение обновления в неактивный, противоположный слот.
4. После установки OTA обновления, при перезагрузке устройства, оно автоматически загрузится в обновленный слот (ранее неактивный).

Android 8.0+ — трансляция обновлений:
Начиная с версии Android 8.0 возможна (но не обязательна) частичная реализация трансляции обновлений с одновременным их применением (прямая запись).
Это значит, что обновления не нуждаются в предварительной их загрузке, а применяются «на лету».

Сообщение отредактировал Displax — 08.06.20, 01:27

Источник