Generic Kernel Image на Google е следващата стъпка към решаването на проблема с фрагментацията на Android

Google работи за намаляване на фрагментацията на Android от години, въпреки че част от причината за това е присъщата природа на Android и ножът с две остриета на избор и свобода. Има безброй OEM активни в пространството и всички те искат да направят свои собствени модификации за собствените си устройства. Проблемът тогава е, че изглежда, че актуализациите на Android OS се разпространяват бавно навсякъде, но всъщност Google не може да направи много, за да принуди OEM производителите да актуализират своите устройства. Като такова, следващото най-добро нещо, което Google може да направи, е да направи процеса на актуализиране възможно най-лесен и безпроблемен.

Облекчаване на болката при актуализиране на Android

Първата голяма инициатива в дългосрочния проект на Google за намаляване на тежестта на разработката беше Проект Treble. Обявен заедно с Android 8.0 Oreo през 2017 г., Project Treble модулира Android чрез разделяне на рамката на ОС от внедряването на доставчика (HAL и специфичното за устройството разклонение на ядрото на Linux). Това улесни OEM производителите на Android да пребазират своите операционни системи върху най-новата рамка на AOSP, тъй като те можеха да стартират най-новата версия, без да се нуждаят от актуализиран код от доставчици. В резултат на това производителите на оригинално оборудване биха могли да подготвят своите персонализирани разклонения на Android по-бързо от преди и като разширение да пуснат основни актуализации на операционната система по-бързо.

Следващата стъпка в плановете на Google беше да рационализира доставката на актуализации на ключови компоненти на Android. Google нарече тази инициатива Основна линия на проекта когато го представи заедно с Android 10 през 2019 г. Google по същество пое контрола върху ключови компоненти на операционната система и забрани на OEM производителите да ги модифицират. След това те настройват механизъм за доставка чрез Google Play, така че да могат дистанционно да пускат актуализации на тези ключови компоненти, без да се налага да чакат OEM производителите да приложат самите корекции. Mainline значително подобри колко бързо устройствата получават актуализирани версии на важни OS компоненти, като на свой ред подобри сигурността на екосистемата на Android като цяло.

Що се отнася до Treble обаче, ядрото на Linux реалистично не трябва да се смесва с код на доставчик със затворен код. Тод Кьос в тазгодишната конференция на водопроводчиците на Linux е обяснил в миналото трудностите, с които се сблъскват, когато става дума за фрагментация на Android, и голяма част от него сега се съсредоточава около ядрото на Linux, което OEM производителите доставят с устройствата си. За контекст Google разклонява всяко основно Linux ядро ​​в „Общо ядро ​​на Android” (ACK), който следи отблизо основната версия, но добавя няколко специфични за Android корекции. Доставчици на SoC като Qualcomm, MediaTek и Samsung след това се разделят че ядро за всеки SoC, който правят. След това OEM производителите вземат това специфично за SoC ядро ​​и добавят допълнителни пачове, за да внедрят поддръжка за конкретния хардуер, който искат да доставят.

Горната диаграма показва как ядрото на устройството преминава през няколко слоя на промяна, които го абстрахират далеч от Linux LTS ядрото. За да го опростим, започваме с ядрото на Linux и то се обединява с общото ядро ​​на Android с няколко промени. Оттам общото ядро ​​на Android се обединява в ядро ​​на доставчик (Qualcomm, MediaTek и т.н.) със свои собствени модификации и промени. И накрая, ядрото на доставчика се обединява в ядрото на OEM, специфично за устройството. До този етап ядрото на всяко устройство е далеч от Linux LTS ядрото, с което е започнало.

В резултат на всички тези разклонения, до 50% от кода, изпълняван на устройство с Android, е код извън дървото, което означава, че не е от общите ядра на Linux или AOSP нагоре. Това прави невероятно трудно (да не говорим за времеемко и скъпо) обединяването на промените нагоре по веригата. За OEM производителите няма стимул да го правят, но тази практика може да бъде вредна за сигурността на устройството. Това е и причината много устройства с Android да са оставени на по-стари версии на LTS ядрото, което има страничния ефект на устройствата, които губят достъп до нови функции на ядрото на Linux.

Android е фрагментиран и Google го знае

Google знае много добре, че това е проблем, и дори има раздел, наречен "Цената на фрагментацията“ в документацията за разработчици на Android. Google казва това "повечето водещи устройства се доставят с версия на ядрото, която вече е на поне 18 месеца". Дори по-лошо, Google също казва това „Android 10 поддържа ядра 3.18, 4.4, 4.9, 4.14 и 4.19, които в някои случаи не са били подобрени с нови функции след Android 8 през 2017 г.“ Това затруднява добавянето на функции, които изискват нови версии на ядрото на Linux. Ядрото на Linux 3.18 беше пуснато през декември 2014 г., когато Android 5.0 Lollipop беше най-новата версия на Android. Това очевидно е проблем и може да задържи платформата назад.

Например, Code Aurora Forum или накратко CAF хоства изходния код за различни Qualcomm Snapdragon SoC. Qualcomm, като SoC доставчик, разпространява разклонена версия на Linux ядрото до OEM/ODM производители и тези компании след това добавят специфични за устройството промени при доставка устройства. Това е, което добавя няколко слоя фрагментация. В допълнение, Qualcomm прави промени в рамката на AOSP, за да оптимизира Android за всяка от мобилните платформи Snapdragon на компанията. Qualcomm частно разпространява своето модифицирано ядро ​​на Linux, рамка AOSP и други софтуерни инструменти на своите партньори като част от пакет за поддръжка на борда или BSP. CAF е мястото, където Qualcomm публикува публично тези промени в ядрото на Linux и промените в рамката на AOSP.

Тази версия на CAF може да бъде полезна за персонализирани разработчици на ROM, които искат да я използват като отправна точка, а не като чист AOSP, поради което понякога виждате „Базирани на CAF“ ROM в нашите форуми. Помните ли Snapdragon 625, който изглежда захранваше толкова много смартфони от среден клас години наред? Това стартира с Linux Kernel 3.18 и едва към края на 2018 г. (две години след пускането на чипсета) Qualcomm актуализира изходните кодове на ядрото и ги публикува на CAF за msm8953 (името на чипсета на Snapdragon 625), осигуряващ поддръжка за Linux Kernel 4.9. Проблемът е, че повечето производители на оригинално оборудване няма да актуализира телефоните до тази нова версия на ядрото на Linux, особено телефоните от среден клас две години след пускането на чипа освободен. Вярно е, че е много рядко подобна основна актуализация на ядрото да се случи дори на първо място, но въпросът е, че има се случи, така че това не е просто невъзможен сценарий.

Като цяло текущата фрагментация в Android е бъркотия, леко казано. Последните опити на Google да коригира тази фрагментация идват под формата на Generic Kernel Image или GKI.

Представяне на Generic Kernel Image

За да се справи с тази фрагментация, Google работи върху Android Generic Kernel Image (GKI). Това по същество е ядро, компилирано направо от ACK клон. GKI изолира персонализирането на доставчика на SoC и OEM към плъгин модули, елиминира кода извън дървото и позволява на Google да изпраща актуализации на ядрото директно до крайния потребител. Повече от година Google работи върху начин за доставяне на GKI актуализации чрез Play Store, чрез използване на модул Mainline.

В резултат на това устройствата, които се стартират с Android 12 и работят с Linux ядро ​​5.10.43 или по-нова версия, трябва да направят едно от следните неща, според Мишал Рахман.

• Разположете подписано от Google изображение за зареждане

ИЛИ

• Разположете изображение за зареждане с ядро, което експортира KMI (интерфейс на модул на ядрото), който е подмножество на KMI, експортиран от GKI, експортира API за потребителско пространство, който е надмножество на UAPI, изложен от GKI, и поддържа всички функции на съответния GKI версия

Доставчиците могат да създават модули, които се включват в GKI, но идеята на GKI е, че Google поема тежестта на отговорността за обработката на промените в ядрото. Интерфейсът на модула на ядрото (или KMI, повече за това в следващите части на статията) всъщност е мястото, където се очаква да отиде кодът извън дървото.

Серията Google Pixel 6 стартира с Android 12 от кутията и се доставя с Linux ядро ​​5.10 и е първият телефон, който се доставя с GKI. Тъй като Google потенциално може да актуализира ядрото чрез Play Store, може дори да видим чести актуализации на ядрото, тъй като актуализациите на LTS ядрото обикновено се пускат всяка седмица. Така или иначе, това е много по-добра система от сегашния тромав метод за актуализиране чрез OTA, въпреки че това означава, че тя е присъщо свързана с GMS рамката.

Google просто дефинира GKI като следното:

• Създаден е от източниците на ACK.
• Това е двоичен файл с едно ядро ​​плюс свързани зареждаеми модули за архитектура, за LTS версия (в момента само arm64 за android11-5.4 и android12-5.4).
• Тестван е с всички версии на платформата Android, които се поддържат за свързания ACK. Няма отмяна на функцията за целия живот на версия на ядрото на GKI
• Той излага стабилен KMI на драйверите в даден LTS.
• Не съдържа SoC или специфичен за платката код.

Google дори иска да бъде в позиция до 2023 г., в която може да приеме модел на развитие „първо нагоре по веригата“. Това ще помогне на Google да гарантира, че новият код се приземява първо в основното ядро ​​на Linux, намалявайки „техническия дълг“, натрупан извън дървовиден код на устройства с Android.

Интерфейсът на модула на ядрото (KMI)

Интерфейсът на модула на ядрото или KMI е част от решението на Google за продължаващата фрагментация в Android. По същество SoC и поддръжката на платката вече не се намират в ядрото на ядрото и вместо това се преместват в зареждаеми модули. И ядрото, и модулите могат да се актуализират независимо след това, тъй като модулите се актуализират в /lib/modules. Предполага се, че самият GKI е възможно най-чист и общ, което е възможно чрез разтоварване на това, което сега е код извън дървото, в отделни модули.

Като Тед Кьос обясни при тазгодишната конференция на водопроводчиците на Linux, „големият многогодишен тласък е да извадим целия специфичен за хардуера код от генеричното ядро ​​и в модули на доставчика. Трябва да имаме стабилен интерфейс между тези модули на доставчика и генеричното ядро, така че да могат да се доставят асинхронно." GKI 1.0 е по същество "тест за съответствие".

Всъщност GKI съвместимостта означава, че устройството преминава тестовете VTS и CTS-on-GSI+GKI с Generic System Image (GSI) и GKI ядрото, инсталирано чрез флашване на GKI зареждащо изображение в зареждащия дял и GSI системно изображение в системата преграда. Vendor Test Suite или VTS е автоматизиран тест, който всички устройства трябва да преминат, за да се считат за съвместими с Project Treble. Пакетът за тестове за съвместимост или CTS е необходим за достъп до пакета от приложения на Google.

Устройствата могат да се доставят с различно продуктово ядро ​​и могат да използват зареждаеми модули, които GKI не предоставя. Обаче както продуктовото, така и ядрото на GKI трябва да зареждат модули от едни и същи дялове vendor_boot и vendor. Следователно всички продуктови ядра трябва да имат един и същ двоичен модулен интерфейс на ядрото (KMI).

Горната диаграма показва какво Google иска да направи и обяснява как възнамерява да постигне това. Модулите Generic Kernel и GKI ще бъдат част от AOSP, а GKI може да комуникира с рамката на Android и слоя за хардуерна абстракция (HAL), които доставчикът може да внедри. Специфичният патентован код, който продавачът иска в ядрото (например драйвери за камера), вместо това ще бъде вкаран в модул на доставчика, който става разширение на GKI чрез KMI.

Как GKI може да помогне за решаването на проблема с фрагментацията на Android

Google положи много работа, за да рационализира процеса на разработка на смартфони. Всеки OEM иска собствена идентичност на марката и всеки OEM иска да може да притежава своите устройства. За разлика от програмата Android One, смартфоните с Android могат почти да бъдат каквито пожелаят, стига да се придържат към набора от правила, които Google определя, за да получат GMS лиценз. В миналото обаче Google не е направил много, за да управлява разработката на устройства с Android промени като Project Treble, Mainline и сега GKI е много по-скорошен в Android история.

Но ще помогне ли? Би трябвало да стане, въпреки че вероятно ще бъде многогодишна афера, която ще даде видими плодове по-късно. Това ще важи само за устройства, които стартират с Android 12, което означава, че ще видим устройства, които нямат GKI за години напред. Това беше и критика към Project Treble, когато беше обявено, въпреки че очевидно всички устройства, пуснати в днешно време, го поддържат. Тези неща отнемат време и докато Google бавно навлиза в управлението на Android, процесът на разработка е улеснен за всички OEM производители в екосистемата на Android, дори ако някои от тях предпочитат да запазят пълен контрол върху ядрото на Linux, което се използва на Android смартфони.