Динамічні оновлення системи в Android Q: Як Project Treble покращить майбутні версії Android

Разом з випуском Android 8.0 Oreo компанія Google представила Проект Treble: суттєва зміна архітектури способу зв’язку між інфраструктурою ОС Android і HAL постачальника та ядром Linux. Treble — це велика ініціатива, спрямована на скорочення версії платформи Android і фрагментація виправлення безпеки, і всі пристрої під брендом Android, які запускаються з Android Pie, повинні підтримувати Project Treble. Виробники комплектного обладнання та постачальники перевіряють сумісність з високими частотами, завантажуючи Generic System Image (GSI) — чисту стандартну збірку Android від AOSP — і передаючи Набір тестів постачальника (VTS) і Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). GSI виявився корисним не тільки в тому, що дозволив розробникам програмного забезпечення, які працюють на OEM-виробників, тестувати сумісність з високими частотами, але також відкрив двері для

велика спільнота призначених для користувача ПЗУ на XDA. Для випуску Android Q Google хоче зробити GSI корисними для іншої групи: розробників програм.

З першого стабільного випуску та вихідного коду будь-якої версії платформи Android зазвичай відбувається в серпні, розробникам, які хочуть протестувати наступну версію Android на реальному пристрої, як правило, потрібен доступ до смартфона Google, якщо вони не хочуть чекати, поки оновлення досягне їх власного обладнання. Однак Google працював з OEM-виробниками, щоб створити Бета-версія Android P на кількох пристроях минулого року, і цього року вони продовжили це з Бета-версія Android Q. Окрім офіційної бета-версії Android Q, Google цього року також випустив офіційна Q beta GSI тож будь-який розробник із пристроєм, сумісним із Project Treble, може інсталювати останню версію Q, не чекаючи місяцями, поки збірка надійде на їхні пристрої. Цей новий спосіб тестування наступної версії Android дає розробникам більше можливостей і, отже, більше часу для тестування своїх програм серйозні зміни в Android.

На жаль, нинішній метод о встановлення GSI може бути важко. Це вимагає розблокування завантажувача, що означає видалення всіх даних користувача та/або анулювання гарантії, і встановлення зображення через протокол швидкого завантаження. Це не швидкий і простий процес для розробника програми, якщо його пристрій навіть дозволяє розблокувати завантажувач. Ось чому, для останні кілька місяців, Google працював над новим способом завантаження GSI. Введіть нову функцію під назвою Dynamic System Update або DSU.

(Раніше ця функція була розроблена під назвами «Live Image», «Dynamic Android» і «Android on Tap», тож не дивуйтеся, якщо через кілька тижнів чи місяців Google назве її якось інакше.)

Динамічні оновлення системи в Android Q

Мета функції DSU — дозволити розробнику завантажитися в GSI, не втручаючись у поточну інсталяцію. Це означає, що завантажувач не потрібно розблоковувати, а дані користувача не потрібно стирати. Процес інсталяції також значно спрощений, оскільки Google надав інтерфейс командного рядка через ADB і програму, якою можна керувати за допомогою намірів. Ось як виглядає завантаження GSI за допомогою DSU:

У цьому відео* Google Pixel 3 XL під керуванням Android Q beta 3 перезавантажується в GSI. У цьому середовищі розробник програми може встановити та перевірити свою програму на сумісність з Q API. Після завершення тестування вони можуть просто перезавантажити на пристрої звичайне програмне забезпечення Q beta 3. Ви фактично подвійно завантажуєте GSI, тож можете безпечно тестувати свою програму!

*Ми записали це відео на Google I/O 2019, коли DSU ще не було загальнодоступним, тому збірка Q beta 3 на знятому Pixel 3 XL була дещо змінена Google, щоб включити підтримку DSU. Пристрої під керуванням Q beta 4 і новіших версій мають право підтримувати DSU, якщо вони відповідають наведеним нижче вимогам.

Вимоги до динамічних оновлень системи

Запустити та запустити те, що по суті є подвійним завантаженням, було непростим завданням для Google. Необхідно було внести серйозні зміни в спосіб керування розділами на Pixel 3, тестовому стенді Google для DSU. Таким чином, перша основна вимога для підтримки DSU полягає в тому, що пристрій підтримує динамічні розділи. Динамічні розділи включають один реальний розділ сховища, який розділений на логічні розділи зі змінним розміром, як-от система, постачальник, odm, oem, продукт тощо. Під час інсталяції GSI простір резервується для нових системних розділів і розділів даних користувача шляхом взяття невикористаних блоків із існуючого розділу даних користувача. Оскільки розмір цих нових розділів може становити кілька гігабайт, підтримка DSU має сенс лише з логікою розділів, інакше пристрою потрібно буде назавжди зарезервувати кілька гігабайт пам’яті для GSI установки.

Інші вимоги включають ramdisk, який вирішує, чи завантажуватись із розділу відновлення, системи чи логічного розділу, а також розділ метаданих для зберігання метаданих GSI. Загалом, будівельними блоками для підтримки DSU є вимоги до запуску Android Q, за словами керівника Project Treble Іліяна Мальчева. Ми не впевнені, чи все яка потрібна для підтримки DSU, є вимогою запуску Android Q, але ми можемо припустити, що більшість, якщо не всі пристрої, які запускаються з Android Q може підтримувати DSU, навіть якщо Google наразі цього не вимагає. Наразі лише Pixel 3, Pixel 3 XL, Pixel 3a та Pixel 3a XL мають динамічні розділи, і з цих пристроїв лише Pixel 3 та Pixel 3 XL підтримують DSU в Android Q beta 4. Хоча підтримка DSU не потрібна, Google сподівається, що виробники обладнання все одно ввімкнуть цю функцію, оскільки вона спрощує безпечне тестування на сумісність з високими частотами. Наприклад, розробник програмного забезпечення OEM може поставити GSI на SD-карті щоб вони могли швидко завантажуватися на кількох пристроях, щоб перевірити сумісність із високими частотами.

Безпека для динамічних оновлень системи

Оскільки DSU по суті представляє другу операційну систему, Google має переконатися, що ця нова інсталяція не може бути підроблена, щоб порушити цілісність пристрою. Таким чином, Для інсталяції GSI застосовуються ті самі базові засоби захисту, що й оригінальна інсталяція: Політики Android Verified Boot і SELinux. Крім того, лише програми з підписом INSTALL_DYNAMIC_SYSTEM|привілейованим дозволом можуть ініціювати GSI інсталяції, тоді як програми з дозволом підпису MANAGE_DYNAMIC_SYSTEM можуть увімкнути/вимкнути або стирати GSI установка. Це означає, що лише надійні програми системного рівня можуть працювати з DSU.

Щоб переконатися, що оригінальні дані користувача захищені, Google додав додатковий механізм захисту в Android Q. під назвою "КПП," ця функція захищає від знищення даних користувача шляхом відновлення вихідного стану розділів із контрольними точками. Проте контрольні точки корисні не лише для DSU. Вони також використовуються для захисту від несправностей Проект Mainline Модуль APEX і A/B Оновлення OTA. (Пристрої з A/B розділами вже має захист від відкату, але ці відкоти вимагають відновлення заводських налаштувань, а контрольні точки даних користувача — ні.)

Встановлення GSI

Якщо ваш пристрій підтримує DSU, як серія Pixel 3, то встановити GSI легко. Спершу потрібно переконатися, що позначку функції Dynamic System увімкнено одним із двох способів:

1. Якщо ви використовуєте збірку userdebug, увімкніть прапор settings_dynamic_android у меню «Параметри» > «Система» > «Параметри розробника» > «Прапорці функцій».
2. Якщо ви використовуєте користувальницьку збірку, виконайте таку команду оболонки adb:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Потім завантажте останню бета-версію Android Q GSI з Google або OEM вашого пристрою. (DSU дозволяє встановлювати лише GSI, підписані Google або OEM.) Після завантаження використовуйте simg2img щоб перетворити розріджене зображення на необроблене зображення. Використовуйте gzip, щоб запакувати необроблене зображення, а потім скопіюйте отриманий архів у місце на пристрої зовнішня пам’ять (наприклад, /data/media/0/Download) або фактичний зовнішній носій пам’яті (наприклад, фізична SD-карта картка). Нарешті, запустіть програму DynamicSystemInstallationService з правильним наміром розпочати встановлення:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

Після натискання перезавантаження ви завантажитеся в GSI. Зручність використання пристрою в GSI залежить від того, наскільки добре OEM вашого пристрою реалізував Treble (точніше, наскільки мало вони порушили Treble сумісність.) Деякі пристрої працюватимуть краще з GSI, ніж інші, але загалом не розраховуйте використовувати цю установку як щоденну водій. Ви маєте перевірити свою програму, а потім вийти, перезавантаживши її. Якщо ви хочете залишитися в установці GSI для подальшого тестування, ви можете скористатися gsi_tool команда оболонки.

Повні інструкції зі встановлення GSI для DSU можна знайти тут. Помилки можна надсилати на Google Issue Tracker,Reddit, або Переповнення стека.

Причина динамічних оновлень системи

Коли я спілкувався з Іліаном Мальчевим на Google I/O, він повторив те, що Хун-Ін Тянь з команди Treble сказав про ранній доступ до GSI на Листопадовий саміт розробників Android. Google зробив DSU для отримати відгук від якомога ширшої аудиторії. Метою є покращення якості GSI, що в свою чергу покращує якість майбутньої версії Android оскільки GSI є найчистішою формою Android. Наразі Google є єдиною компанією, яка перевіряє сумісність наступної версії GSI (наприклад, наскільки добре працює образ системи Android Q на основі Android P реалізацію від постачальника), але в міру того, як більше людей перешивають GSI і надсилають відгуки, OEM-виробники можуть виправляти порушення сумісності Treble, щоб GSI працювати ще краще в майбутнє. Іліян каже, що OEM-виробники та постачальники, такі як Qualcomm, сильно зацікавлені у повторному використанні образів постачальників із попереднього випуску Android із системним образом наступної версії. Такі ініціативи, як DSU, допомагають Google і виробникам комплектного обладнання заповнити прогалину в охопленні автоматизованих тестів, таких як VTS і CTS-on-GSI. Таким чином, Google отримує більше бета-тестерів для надання відгуків про наступний випуск Android, а також чує про порушення сумісності з високими частотами, щоб OEM-виробники могли покращити свою роботу.

Додавання динамічних оновлень системи в Android Q вітається, але це не буде рішення подвійного завантаження, на яке деякі з вас сподіваються. Як згадувалося раніше, можна встановити лише системні образи, підписані Google або OEM-виробниками. Коли я запитав Іліяна про можливість розширення DSU для підтримки екосистеми альтернативного Android він сказав, що технічно це можливо, оскільки DSU — це просто канал для доставки системи зображення. Будь-який OEM може використовувати його як завгодно за умови, що кінцевий результат сумісний з Android. Google не створив тут альтернативи системі OTA, і DSU не призначений для використання для справжнього подвійного завантаження. Незважаючи на це, робота Google над Treble робить Android більш модульним, тому я не здивуюся, якщо власне подвійне завантаження стане реальністю.