Android 10 DSU може дозволити вам спробувати оновлення OTA без зобов’язань

click fraud protection

Ви коли-небудь хотіли спробувати оновлення без фактичного оновлення? DSU в Android 10 призначений для цього, але наразі він обмежений. Це може скоро змінитися.

ОС Android і фрагментація рівня безпеки є величезною проблемою, для боротьби з якою Google докладає багато інженерних зусиль. За останні два роки Google оголосив про дві великі ініціативи, спрямовані на прискорення розгортання оновлень: Проект Treble і Проект Mainline. Останнє було оголошено лише в травні цього року Google I/O 2019, і він підтримується лише на пристроях, які запускаються з Android 10. Перший, однак, існує з тих пір Google I/O 2017, тому ми побачили, наскільки це вплинуло на оновлення Android з Android 9 Pie і Android 10.

Окрім зменшення фрагментації, Google також хоче, щоб Project Treble був корисним для розробників програм. Тому й оприлюднили Динамічні оновлення системи (DSU) в Android 10, щоб дозволити розробникам спробувати базову версію нового оновлення ОС без розблокування завантажувача чи стирання даних. Бачачи потенціал DSU, Google не зупиняється на досягнутому — вони розширюють його корисність, дозволяючи OTA-оновлення від OEM-виробників встановлювати так само, як і GSI.

Це багато жаргону, але уявіть, що це станеться в майбутньому: OEM випускає телефон з Android 10 і запускає програму бета-тестування для Android 11. Вам цікаво випробувати цю бета-версію, щоб побачити нові функції, але ви не хочете ризикувати стабільністю поточного щоденного драйвера. Замість того, щоб запускати бета-версію оновлення та сподіватися, що воно цілком стабільне, чому б тимчасово не встановити його через потік DSU? Якщо вам це не подобається, просто перезавантажте систему, і ваші налаштування повернеться до нормального стану. Якщо вам це подобається, ви можете «зобов’язатися» оновити.

Я не знаю, як ви, але це була б бажана зміна в Android, яка зробить бета-тестування приємнішим. Вам більше не доведеться брати участь у бета-оновленні лише для того, щоб побачити, що це таке для вас. Я впевнений, що багато хто з вас чекає бета-версії Android 10 для свого пристрою, але вам може бути незручно встановлювати її відразу. Зі змінами, внесеними до DSU, це більше не буде проблемою.

Динамічне оновлення системи в Android 10+ – що зміниться

Лука Стефані, друг порталу XDA і a Визнаний розробник, повідомив нам про а новий комміт об’єднано в AOSP під назвою «монтувати кілька розділів DSU, якщо вони присутні». Комміт вносить зміни до таблиці файлової системи (fstab) і процес ініціалізації, щоб зробити так, щоб розділи DSU, крім системи, наразі включаючи продукт і постачальника, могли бути змонтовані під час завантаження процес.

Новий код у fstab для додавання підтримки для завантаження зображень product_gsi та vendor_gsi замість існуючих розділів продукту та постачальника відповідно. У коментарі зазначається, що DSU можуть бути підписані OEM, але в іншому випадку підтримують офіційні GSI Google.

Наразі DSU призначений лише для завантаження Generic System Image (GSI) — образу системи barebone, скомпільованого з AOSP, тож ви можете протестувати нові API та інші зміни в останньому оновленні Android. Однак із цією зміною DSU також прийматиме зображення продуктів і постачальників. Перший містить програми, бібліотеки та інші файли для пристрою, а другий містить двійкові файли для пристрою. Project Treble зробив так, що ви можете завантажувати пристрій за допомогою образу системи без файлів, що стосуються пристрою, тож тепер дозволяти завантаження продукту та постачальника, здається, не має особливого сенсу.

Однак інженер Google чітко каже, що ця зміна полягає в тому, щоб «дозволити виробникам обладнання встановлювати OTA-пакети на /data, а потім використовувати [потік] DSU для монтування product.img, system.img, [і] vendor.img з /data." Це означає, що замість того, щоб перезаписувати поточну інсталяцію новим пакетом OTA, OTA можна тимчасово завантажити через ДДУ. Після пробного оновлення OTA «користувач може вирішити, чи хоче він «закріпити» ці зображення в /super чи ні». Ця остання частина про «внесення» змін все ще триває, оскільки один інженер Google зазначає, що «наразі ми не плануємо створювати розділи DSU постійний у контексті DSU." Потім він заявляє, як це можна було б реалізувати, але ця реалізація "виходить за межі" цього поточний патч.

Є деякі терміни та поняття, які ми повинні пояснити тут, оскільки Google любить змінювати схему розділів у кожній версії Android. Для початку я рекомендую прочитати мою попередню статтю про Динамічні оновлення системи для широкого огляду того, як це працює, але, підсумовуючи, він використовує концепцію «динамічного розділу», одного реального розділу сховища (так званого «супер» розділ), який ділиться на логічні розділи зі змінним розміром (включно з системою, постачальником, продуктом і системним розширенням), щоб тимчасово встановити GSI. Під час встановлення GSI DSU створює простір для нової системи та образів даних користувача, змінюючи розмір існуючого розділу даних користувача. Будівельними блоками для підтримки DSU (динамічні розділи, RAM-диск і контрольні точки для резервного копіювання даних) є вимоги до запуску для Android 10, тому будь-який пристрій, який запускається з новою версією ОС Android, повинен підтримувати DSU. DSU не є рішенням подвійного завантаження для користувальницьких ПЗУ, які деякі з вас шукають, оскільки можна встановити лише образи, які відповідають ключам Android Verified Boot (AVB). Однак завдяки цій новій зміні це може виявитися набагато кориснішим у майбутньому.

Окрім динамічних розділів, Google також представив концепцію «віртуального A/B» в Android 10. Це в основному реалізація подвійні A/B перегородки раніше, але з логічними розділами. Розділи A/B містять копії важливих розділів, щоб забезпечити безперебійне та безпечне оновлення. Використання «віртуального A/B» — це те, як один інженер Google передбачає «закріплення» розділів DSU на розділи з поточної інсталяції; як і в поточному процесі оновлення A/B OTA, можливо, зміни з нових зображень вносяться до неактивного розділу.

Ці зміни все ще знаходяться на стадії розробки, тому може знадобитися деякий час, перш ніж Google або OEM-виробники їх використають. ми ймовірно, не буде жодних реалізацій цього, доки Android 11 R не буде випущено наступним рік. Незважаючи на це, немає жодної гарантії, що виробники обладнання навіть приймуть цю функцію для своїх OTA-оновлень. З огляду на те, наскільки це здається корисним для бета-тестування, я припускаю, що Google уже працює із зацікавленими OEM-виробниками, щоб увімкнути цю функцію для майбутніх оновлень. Особисто я в захваті від можливості спробувати нові оновлення Android перш ніж купувати, а як щодо вас?