Загальний образ ядра Google має на меті вирішити проблему фрагментації в Android, хоча це складна тема. Ось як це працює.
Google роками працює над зменшенням фрагментації на Android, хоча частково причиною цього є невід’ємна природа Android і двосічний меч вибору та свободи. У космосі працює незліченна кількість OEM-виробників, і всі вони хочуть робити власні модифікації для власних пристроїв. Проблема полягає в тому, що, схоже, оновлення ОС Android поширюються повільно, але насправді Google не може багато чого зробити, щоб змусити OEM-виробників оновлювати свої пристрої. Таким чином, наступне найкраще, що Google може зробити, це зробити процес оновлення максимально простим і легким.
Полегшення болю оновлення Android
Першою великою ініціативою в довгостроковому проекті Google щодо зменшення тягаря розробки було Проект Treble. Проект Treble, анонсований разом з Android 8.0 Oreo у 2017 році, модульував Android, відокремивши фреймворк ОС від реалізації постачальника (HAL та форк ядра Linux для конкретного пристрою). Це полегшило OEM-виробникам Android перебазування своїх ОС на основі останньої версії AOSP, оскільки вони могли завантажувати останню версію без необхідності оновлювати код від постачальників. У результаті OEM-виробники зможуть підготувати свої користувацькі форки Android швидше, ніж раніше, і, відповідно, швидше розгортати основні оновлення ОС.
Наступним кроком у планах Google було оптимізувати доставку оновлень для ключових компонентів Android. Таку ініціативу назвав Google Проект Mainline коли він представив його разом з Android 10 у 2019 році. Google по суті взяв під контроль ключові компоненти ОС і заборонив OEM-виробникам їх модифікувати. Потім вони налаштували механізм доставки через Google Play, щоб вони могли віддалено розгортати оновлення для цих ключових компонентів, не чекаючи, поки OEM-виробники самі застосують виправлення. Mainline значно покращив швидкість отримання пристроїв оновлених версій важливих компонентів ОС, у свою чергу покращивши безпеку екосистеми 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. Qualcomm як SoC постачальник розповсюджує розгалужену версію ядра Linux серед OEM/ODM-виробників, і ці компанії потім додають зміни до пристрою під час доставки пристроїв. Саме це додає кілька рівнів фрагментації. Крім того, Qualcomm вносить зміни в структуру AOSP, щоб оптимізувати Android для кожної мобільної платформи компанії Snapdragon. Qualcomm приватно розповсюджує модифіковане ядро Linux, фреймворк AOSP та інші програмні інструменти своїм партнерам як частину пакета підтримки плати або BSP. CAF – це місце, де Qualcomm публічно публікує ці зміни ядра Linux і зміни структури AOSP.
Цей випуск CAF може бути корисним для розробників спеціальних ПЗУ, які бажають використовувати його як відправну точку, а не чистий AOSP, тому іноді ви бачите ПЗУ на основі CAF на наших форумах. Пам’ятаєте Snapdragon 625, який роками використовувався для багатьох смартфонів середнього класу? Це було запущено з ядром Linux 3.18, і лише наприкінці 2018 року (через два роки після запуску чіпсета) Qualcomm оновила вихідні коди ядра та опублікувала їх на CAF для msm8953 (назва чіпсета Snapdragon 625), що забезпечує підтримку ядра Linux 4.9. Проблема в тому, що більшість OEM-виробників не буде оновлювати телефони до нової версії ядра Linux, особливо телефони середнього класу через два роки після випуску чіпа звільнений. Щоправда, таке серйозне оновлення ядра трапляється дуже рідко, але справа в тому, що воно має сталося, тому це не просто неможливий сценарій.
Загалом, нинішня фрагментація в Android, м’яко кажучи, безлад. Останні спроби Google виправити цю фрагментацію відбулися у формі Generic Kernel Image або GKI.
Представляємо загальний образ ядра
Щоб усунути цю фрагментацію, Google працював над загальним образом ядра Android (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. Набір тестів на сумісність (Compatibility Test Suite, 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 смартфони.