Отзыв: Операционная система AOSP Extended 10 — Не первый взгляд
Всем привет! Начну с того, что несколько лет назад, на волне внезапно вспыхнувшей народной любви к бренду Xiaomi мною также были приобретены пара смартфонов. Время идёт, уже 4 года, они всё никак не ломаются, в одном только поменял батарею, а во втором разбитый экран.
Как водится, по прошествии некоторого времени, фирма успешно «кладёт» на свои старые модели и поддерживает только новые разработки. Плюс ко всему эта мерзкая оболочка miui просто ни в какие ворота не влазит.
В общем жизнь, в данном случае Redmi 3s, замерла на 7 андроиде с камнем miui на шее и с этим надо что-то делать.
Уже выпущены совершенно новые версии операционки Андроид, 8,9, 10, но даже совершенно новые модели смартфонов не всегда могут похвастать такой обновой. Поэтому я решил подобрать новую прошивку, желательно на чистом Андроиде. Это оказалось непросто, перепробовал множество вариантов и остановился на AOSP Extended 10.
Но это же просто «Песня»!, и вот почему.
Прошивка легковесная, чуть больше 500 Мб, в то время как современная miui c гуглохламом легко переваливает за 1,5 Гб.
В оперативной памяти занимает мало места, это актуально для старых устройств с небольшим объёмом памяти.
Меню андроида полностью переработано, разделов стало меньше и в них легче ориентироваться. Практически каждому приложению можно настроить допуск в интернет, отдельные разрешения, работу в фоновом режиме и режим уведомлений.
Добавлены свои расширенные настройки, в основном связанные с жестами, переназначением функций кнопок, настроек экрана и различных эффектов.
Работает всё плавно и быстро, анимации можно изменить или вообще отменить.
Также работают всевозможные блокировки с использованием отпечатка пальца, графического ключа и т. д.
Виджеты, настройка стилей и обоев, а также настройка обоев экрана теперь вызываются длительным нажатием на главном экране.
Буквально в несколько кликов можно создать свою тему, с изменёнными стилями элементов.
Появилась возможность добавить пользователей, к примеру детей, и назначить им свои ограничения по использованию приложений.
Добавлен раздел для телефонов Xiaomi, в основном здесь собраны улучшалки звука для наушников и профили для разных режимов производительности. Мне неинтересно, поэтому отключил.
Про камеру не пишу, у Redmi 3s она довольно хороша даже на сегодняшний день, в данной прошивке она предельно простая, но легко можно установить стороннее приложение.
Полностью переработан раздел «Батарея». Информации не особо много, но главное – это график потребления заряда и возможность перевести устройство в режим экономии.
Вот, кстати на официальном сайте команды разработчиков есть раздел, посвящённый статистике по использованию Андроид 10 AOSP Extended, весьма интересные цифры. Тут же можно, собственно и посмотреть, есть ли прошивка для Вашего устройства и сразу скачать.
После всех многочисленных настроек, телефон крепко спит, когда надо и не спит когда не надо .
Поддерживаются обновления «по воздуху».
Что в итоге? На древнем Redmi 3s (и не только) совершенно спокойно работает самый современный Андроид со всеми своими «плюшками». Автономность устройства стала лучше и я решил пока повременить с продажей и пользоваться телефоном ещё какое-то время. Также теперь есть замечательная возможность – это самому выбрать – пользоваться всеми сервисами гугла или использовать альтернативные варианты.
И главная задача выполнена – я просто не думаю про зарядку пару дней и ещё остаётся запас хода. Так что, Андроид 10 AOSP Extended рекомендую.
Напоследок хочу предупредить, что это не штатная установка и надо осознавать всевозможные риски, связанные с данными и нюансами в работе некоторых специфических программ, наподобие банковских приложений и др.
Источник
Новейший Android уже можно установить на любой смартфон с поддержкой Project Treble
Благодаря инициативе Project Treble, которая призвана ускорить процесс обновления Android-устройств, можно установить GSI-сборку Android на основе AOSP без необходимости менять компоненты, отвечающие за работоспособность аппаратного обеспечения. OEM-производители, которым требуется сертификация Google, должны проверять свои устройства на соответствие требованиям Project Treble, загрузив эту сборку и протестировав основные функциональные возможности оборудования. Однако они не обязаны проверять их работоспособность. К сожалению, это означает, что GSI-сборки прекрасно работают на одних смартфонах и совершенно не работают на других. Вот тут на помощь приходят кастомные GSI, созданные сообществом разработчиков XDA.
Пользовательские GSI-сборки имеют минимум ошибок и поддерживают максимально возможное количество Android-устройств. К примеру, последняя версия GSI от разработчика Phhusson позволяет установить Android 10 на любое устройство, поддерживающее Project Treble, и делает это без нарушения работы основных системных функций, таких как Wi-Fi, сотовая связь, управление яркостью и так далее.
Google предлагает собственные GSI-сборки для Android 10, но они предназначены только для того, чтобы разработчики могли тестировать свои приложения на новом API. Если вы владеете популярной моделью смартфона, то у вас есть все шансы поставить на него кастомную прошивку с более свежим Android, в противном случае вам остаётся надеяться на PhIusson GSI. Эта сборка подходит для любого сертифицированного устройства, поддерживающего Project Treble (Android 8 Oreo и выше). Учтите, что вы можете столкнуться с некоторыми проблемами, если попытаетесь загрузить сборку на смартфон, приобретённый в Китае.
Для установки обновления необходимо выполнить три условия. Прежде всего убедитесь, что ваш смартфон поддерживает Project Treble. Для этого используйте утилиту Treble Info. Далее необходимо разблокировать загрузчик и установить кастомный Recovery. Последняя GSI-версия Android 10 находится на GitHub, инструкцию по прошивке можно взять на XDA. Также не лишним будет прочитать и саму тему с пользовательской сборкой от Phhusson.
Источник
Загрузка и сборка AOSP
Решил поделиться своей инструкцией как собрать AOSP (Android Open Source Project). Эта инструкция будет полезна тем кто хочет посмотреть что-же внутри Android и возможно заняться системной разработкой. В любом случаи эти знания полезны для понимания самого Android, как раз для этого и решил собрать AOSP.
Проект собираю на elementary 5.1 OS Ubuntu 18.04 LTS (bionic), пытался на MacOS собрать, но так и не удалось. Для исходников и сборки нужно 200 Гб на жестком диске (лучше SSD, на обычном производительность сильно проседает). Так же много времени, я потратил чтобы скачать и собрать около 20 часов, частично виновата «слабая» конфигурация моего компьютера. У меня установлено всего 8 Гб оперативной памяти, но увеличил размер swap-а до 16 Гб.
Загружаем AOSP
Установить требуемые пакеты для загрузки и сборки :
Создаем папку и качаем repo утилиту для загрузки исходного кода
Исходники AOSP состоят из отдельных проектов с собственными git-репозиториями, repo позволяет упросить всю загрузку всех проектов и разложить по нужным папкам.
- -u — урл git-репозитория с манифестом
- -b — ветка (самая последняя на текущий момент)
- —depth — скачивать только одну ветку (если не использовать, то для каждого репозитория скачается весь индекс, что увеличит время загрузки и место на диске)
Выбрал самую последнюю версию Android 10. Не использую develop или master, так как там устаревший манифест и проект скорее не соберется.
Теперь можно запустить загрузку исходников AOSP
- -c — скачивать только текущую ветку манифеста (как указал выше — android-10.0.0_r45)
- -j — количество потоков, обычно указывается столько доступно процессоров
- —no-tags — не скачивать тэги с репозитариев
- —no-clone-bundle — не пытаться качать clone.bundle (упакованная репа, которая уменьшить время на загрузку, но не у всех сервер формирует этот bundle),
—no-clone-bundle можно попробовать убрать, что в теории ускорит скачивание, но у меня заваливается с 404 ошибкой
Скачивание может занять минуты и часы, теперь с repo закончили, если нужно почитать больше то ищите в официальной документации: https://source.android.com/setup/develop/repo
Сборка
Настраиваем среду разработчика:
x86_64 — указывается под какой девайс собирать, в данном случае Generic x86_64 подходит для эмуляторов, если будете запускать на Nexus девайсах, то ищите детали в документации https://source.android.com/setup/build/building#choose-a-target
eng — тип сборки (сокращение от engineering), с максимальными логами и дополнительными утилитами для отладки. Другие тип сборки думаю не особо интересны
Для сборки java файлов увеличиваем Heap size, если этого не сделать, то сборка всего завалится с StackOverflow ошибкой:
Так же можно добавить в .bashrc чтобы постоянно не повторять команду
Все, теперь готовы к сборке:
Можно не использовать CCACHE, что уменьшит количество занимаемого места на диске, но увеличит время повторной сборки. На моем «слабом» компьютере сборка заняла где-то 16 часов.
После окончания сборки, запускаем эмулятор:
-show-kernel — выводить уведомления в консоль
Если нажать Enter, то попадем в консоль эмулятора
Если эмулятор не запустился, нужно будет проверить что включена виртуализация
Готовим IDE для отладки
Для начала необходимо сгенериовать проект для IDE, проект генерируется для IDEA. Собираем модули для генератора:
Чтобы весь AOSP затолкать в проект, то просто запускаем генератор
Но сгенерированный IDEA проект будет очень «тяжелым». Одно открытие и индексация занимает достаточно много времени. Лучше генерировать IDEA проект для каждого отдельного проекта, например для Android фреймворка
Весь список доступных проектов можно посмотреть в
Открываем сгенерированный base.iml (находится в папке frameworks/base) в IDEA. Дальше нужно настроить Java, только нужно подключать java без библиотек, так как у AOSP-а свои реализации.
Запускаем отладку
Для начала необходимо запустить monitor
возможно потребуется дополнительно поставить jre
sudo apt install openjdk-8-jre-headless
Выбираем процесс, который будем отлаживать. В monitor-е выбираем процесс и справа от порта процесса появится /8700, это как раз порт отладчика, к нему можно подключаться через IDEA.
Все системные штуки находятся в system_process. Его мы и будем отлаживать.
monitor один самых полезных инструментов при отладке и исследования работы AOSP
В проекте добавляем новую Remote конфигурацию, только указываем 8700 порт. Именно к этому порту и будем подключаться
Запускаем Debug (Run → Debug)
Чтобы удостоверится, что все подключилось поставьте брейкпоинт в frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java файле на метод:
и запустить любое приложение на эмуляторе (например, Settings).
Источник
Aosp extended android 10
Начнем. Вы, наверное, слышали, что в некоторых устройствах используется какая-то диковинная 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
Источник
