Как использовать Android SDK и инструменты поставщика смартфона для загрузки другого ядра?

Question

Я добился определенного прогресса в поиске решения:

1) Удалить все пользовательские данные с устройств, которые будут использоваться для экспериментов (загрузка в режиме восстановления > очистка кэша / очистка данных / сброс настроек к заводским)

2) Просмотрел неофициальные источники

В сети есть ряд статей и сообщений на форумах. Некоторые из них полезны. Большинство из них довольно старые и последний раз обновлялись давно. Плохо то, что большинство из них содержат информацию о рутировании устройств (т. е. взломе безопасности ОС путем преднамеренной установки руткита, эксплуатирующего известную уязвимость для повышения своих привилегий) и ссылки на ненадежные/с низкой репутацией скрипты, содержащие такие руткиты. Эта потенциально вредная информация смешана с полезными частями, дающими общий обзор доступных опций.

Многие статьи опубликованы на сайте xda-developers.com, егоФорумраздел ивики.

Некоторые полезные статьи вики:

Эти статьи вики, как правило, поддерживаются довольно плохо (последние правки были в 2015 году).

3) Выбрать платформу (x86, ASUS Zenfone2)

В моем случае я выбирал из пула своих собственных подержанных устройств Android. Большинство из них имеют процессоры на базе ARM. Последним и самым мощным был ASUS с процессором Intel x86 (64-битный набор инструкций). Другой причиной выбора x86 была лучшая поддержка Linux и необходимость запуска контейнеров lxc на базе x86/AMD64. Выбор ARM потребовал бы разработки отдельной ветви контейнера или использования каких-либо инструментов эмуляции/конвертации (не уверен, что такие инструменты эффективны/хорошо обслуживаются/поддерживаются).

4) Понял, что цель может быть недостижима с официальными (поддерживаемыми поставщиком) инструментами.

Я написал в техподдержку ASUS по поводу использования их инструмента разблокировки загрузчика. Но ответ был прост: «Этот инструмент просто разблокирует загрузчик, мы не можем помочь вам с дальнейшими шагами, мы даже не можем сказать вам, что произойдет, если вы используете этот инструмент». Т.е. этот инструмент бесполезен (я даже не знаю, сработал ли он как-то в моем случае и чем он отличается от fastboot oem unlock). Чтобы активировать этот инструмент, мне сначала пришлось понизить версию до Android 5.0, так как он не поддерживался в более новых версиях ROM. Все, что касается смены загрузчика и загрузки других образов, является неофициальным, неподдерживаемым, нерекомендуемым, нарушает гарантию и т.д.

5) [НЕОБЯЗАТЕЛЬНО: ПРИМЕЧАНИЕ 1] Выберите и установите рекавери (официально не поддерживается производителем телефона или ОС)

'Восстановление'- жаргон Android для обозначения загрузчика / BIOS (отдельный раздел в памяти устройства, содержащий облегченную систему на базе Linux, которая загружается первой и отображает меню загрузчика с доступными инструментами, такими как «резервное копирование», «очистка кэша», «сброс настроек к заводским», «загрузка пользовательского ПЗУ» и т. д.). Оригинальное восстановление OEM не позволяет прошивать пользовательское ПЗУ или загружать пользовательскую ОС.

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

ПРИМЕЧАНИЕ 1:После установки TWRP и получения дополнительной информации о SDK Tools я понял, что, вероятно, можно прошить кастомную прошивку без установки кастомного рекавери (используя инструменты adb и fastboot из пакета SDK platform-tools).

ЗАМЕТКА 2:Процесс установки хорошо документирован для каждой модели. Я использовал «метод установки Fastboot». Краткое описание метода (см. страницу на сайте TWRP, соответствующую вашему устройству): 1) Установите инструменты Android SDK (вам понадобятся только компоненты adb и fastboot из пакета platform-tools), 2) Активируйте «режим разработчика» на вашем устройстве, нажав 7 раз на строку «Номер сборки» в меню «Настройки» > «О программе», 3) В разделе «Настройки» > «Параметры разработчика» включите «Отладку по USB», 4) Подключитесь к ПК через USB, 5) На вашем ПК вы можете проверить, подключено ли устройство, передав команду adb devices, 6) Запустите adb reboot bootloaderдля входа в режим fastboot, 7) Поместите правильный файл образа, загруженный с сайта TWRP и переименованный в «twrp.img», в папку, содержащую двоичные файлы adb и fastboot (обычно это папка «platform-tools»), 8) Запустите fastboot flash recovery twrp.img.В моем случае образ успешно прошился, хотя adb сообщил об ошибкеFAILED (remote: Permission denied), 9) Запустить fastboot reboot. Вы также можете перезагрузить свое устройство из меню TWRP. Важно позволить TWRP пропатчить ваш стоковый ROM (раздел с ОС Android), чтобы предотвратить стирание TWRP и замену его стоковым рекавери после загрузки. В противном случае вам придется повторить процесс. Да, это было страшно, отсюда и шаг №1.

6) Углубился в официальную документацию AOSP

Потеряв надежду на использование подхода «черного ящика» в ОС Android для достижения цели, я начал просматривать общие разделы по архитектуре ОС Android и требованиям к поддерживаемым устройствам.

Хорошие фотографии (архитектура):

Информация о загрузчике и безопасности:

Основной вывод:Android определенно представил полезные функции ОС для запуска сокращенного ядра Linux на разнообразном спектре фирменных (FMCG-мир) устройств с нестрогими аппаратными стандартами. Одной из самых полезных функций, которая может и, вероятно, должна быть принята основным Linux, является уровень абстракции HAL, позволяющий разумным образом работать с зоопарком умиротворяющих драйверов. Модульное ядро с разделением ядра на части, зависящие от SoC и платы, функции энергосбережения и безопасности также примечательны.

Хорошие новости:Разработчики ядра Linux инекоторыйПоставщики дистрибутивов хорошо знают все эти хорошие части и делают все возможное, чтобы внести соответствующие изменения. Официальная статистика (см. Рисунок 2соответствующий раздел документа AOSP) показывают хорошие доказательства конвергенции между кодом AOSP и основным Linux. Существует определенный положительный экономический эффект от конвергенции для обеих сторон (сообществ AOSP и Linux). Когда дело доходит до таких заинтересованных сторон, как Google и производители оборудования, которые защищают свои инвестиции, они, кажется, тянут в противоположном направлении. Google защищает свои инвестиции в экосистему и пользовательскую базу, производители оборудования защищают свои инвестиции в разработку и производство hi-end оборудования. Трение между этими двумя силами создает своего рода положительный вектор. По моему мнению, должно быть какое-то соглашение между Google и производителями оборудования, которое регулирует это трение разумным образом. Например, производители оборудования могут отложить передачу своих BLOB-файлов драйверов, специфичных для платы, в ядро Linux, скажем, на 2-3 года (для BLOB-файлов драйверов, специфичных для SoC, этот период, возможно, должен быть короче). Это гарантировало бы разработчикам Google и AOSP, что экосистема Android снимает все сливки с рынка (все новые покупки современных hi-end устройств, доходы от рекламы, платное программное обеспечение и услуги от hi-end пользователей). По истечении этих 2-3 лет устройства (больше не считающиеся hi-end) выпускаются в свободное пользование путем помещения драйверных блоков в Linux (поставщики оборудования высшего класса, конечно, предпочли бы помещать исходный код). Продолжительность этого периода довольно близка к обычному гарантийному сроку, установленному для большинства устройств поставщиками оборудования, и периоду официальных обновлений Android (включая обновления безопасности), распространяемых этими поставщиками. Достаточно справедливо.

Плохие новости:Кажется, очень трудно договориться о такой сделке.(далее - Сделка)мудрым и явным образом. Основная проблема заключается в ее глобальном характере. Подумайте о возможных правовых соображениях (антимонопольное законодательство в различных юрисдикциях, трансграничные налоговые вопросы и т. д. и т. п.), количестве поставщиков оборудования (OEM, ODM, производители SoC и т. д. и т. д.) и других вовлеченных заинтересованных лиц (Google, AOSP, разработчики Android, Linux, поставщики дистрибутивов Linux - серверных, настольных и, возможно, мобильных, другие проекты на основе Linux, GNU, FSF и т. д. и т. д. вплоть до конечных пользователей). Отсутствие сделки определенно замедляет конвергенцию между Linux и AOSP к нашему (пользователей) общему сожалению. С точки зрения оборудования полная конвергенция была возможна несколько лет назад, когда на рынок вышли основные [многоядерные x86 CPU / > 2Gb RAM / > 16Gb flash drive]-устройства. Проблема становится очевидной, когда это оборудование не может использоваться для запуска стандартного ядра Linux (серверный дистрибутив, даже не настольный). Установщики отсутствуют, инструменты для прошивки официально не поддерживаются вендорами, документация скудна и разрозненна. В июне 2019 года все могло бы быть намного лучше...

7) Следующим шагом станет мониторинг усилий, предпринимаемых ведущими сообществами, ориентированными на конверсию, и поддерживающими поставщиками, а также шагов, предпринимаемых поставщиками оборудования и AOSP/Google для переговоров по сделке.

Answer 1