Как A/B дяловете и безпроблемните актуализации влияят върху разработката по избор на XDA

Когато пуснахме Android Nougat, ни накара да говорим за него всякакви нови функции. За начало получихме наскоро актуализиран потребителски интерфейс заедно с дългоочакваните възможности за много прозорци и поддръжка на Vulkan Graphics API. Но едно допълнение под капака прелетя над главите на повечето потребители. Android Nougat представи „Безпроблемни актуализации“ на устройства, които поддържат A/B дялове. По-голямата част от съществуващите устройства с Android (с изключение на новите Google Pixel и Google Pixel XL) нямаха A/B дялове по това време и следователно не можеха да се възползват от безпроблемните актуализации. Основната предпоставка на тази функция е, че устройството има втори набор от система, зареждане, доставчик и други важни дялове и когато получите OTA актуализация актуализацията се извършва във фонов режим, докато вторият набор от дялове се коригират, което ви позволява да рестартирате безпроблемно в актуализирана софтуерна компилация. Ако актуализацията е неуспешна, ще бъдете върнати към работеща компилация, което означава, че компаниите ще имат по-малко главоболия и потребителите ще бъдат по-добре защитени.

Поддържането на безпроблемни актуализации не е изискване за ново устройство с Android, за разлика от Project Treble. Поради това по-голямата част от новите устройства с Android не поддържат функцията. Досега поддържаме списък с всички поддържани устройстваи е ясно, че тази функция не се поддържа широко. Това е жалко, защото A/B дяловете носят много предимства както за обикновените потребители, така и за опитните потребители. Функцията обаче има малко лоша репутация в общността на ентусиастите, защото се смята, че затруднява разработването на Android и флашването на персонализирани модификации. Това всъщност не е така, така че искахме да демистифицираме безпроблемните актуализации и да обясним как A/B дяловете влияят върху персонализираното разработване на XDA.

Много благодаря на XDA Senior Member npjohnson, а сътрудник на LineageOS и поддържащ на Motorola Moto Z2 Force, който ни помогна да проверим фактите в тази статия.

---

Дялове на устройство с Android

Дялът е просто отделен раздел от вътрешната памет на телефона, където се съхраняват данни. Какъв вид данни се съхраняват на всеки дял зависи от хардуера, операционната система и много други фактори. Буутлоудърът ще има един, системата (Android OS) ще има един, потребителските данни ще имат един... и така нататък. Когато видите хората да говорят за "/system" и "/cache", те имат предвид дадените имена за тези дялове. OnePlus 6, например, има 72 прегради. Това звучи много, но OnePlus 6 е едно от устройствата, които поддържат безпроблемни актуализации, което означава, че много от тези дялове са просто дубликати един на друг.

Частичен изход на дяловете на OnePlus 6. Някои A/B дялове са подчертани за демонстрационни цели.

Има много дялове на едно устройство, за които никога няма да се притеснявате като потребител. Много от тези дялове никога не се модифицират при мигане на потребителски ROM, ядра, възстановяване или модификации като Magisk или Xposed. Много от тези дялове или ще бъдат неизползвани за нашите цели, или са твърде опасни за докосване, освен ако не знаете какво правите (XLOADER и OEMINFO на Huawei/Honor устройства идват на ум.) За огромното мнозинство от потребителите на Android дяловете, с които се занимаваме най-вече, са система, стартиране, възстановяване, потребителски данни и наскоро доставчик и vbmeta. Ето кратко обяснение на предназначението на всеки дял:

• система - съдържа операционната система Android, системните библиотеки, системните приложения и други системни носители като зареждащи анимации, стокови тапети, мелодии и др.
• boot - държи ядрото, ramdisk, а на A/B устройства също и възстановяването
• възстановяване - задържа възстановяването, където TWRP най-често се флашва само на A-устройства (A/B устройствата нямат специален дял за възстановяване)
• потребителски данни - съдържа всичките ви данни за приложението, системата и вътрешната памет
• доставчик - съдържа специфични за платформата и устройството HAL, файловете, необходими на операционната система Android, за да комуникира с основния хардуер
• vbmeta - дялът за Android Verified Boot 2.0, който проверява целостта на процеса на зареждане

OEM производителите на устройства могат да променят своите схеми на дялове, за да използват каквото пожелаят оформление. Например Huawei разделя дяла за зареждане на ramdisk_recovery и ядро. Има и много допълнителни дялове, които могат да съдържат други системни приложения като cust, product и oem, и докато те са безопасни за модифициране, като цяло не се препоръчва, ако искате да улесните себе си да се върнете на склад. И така, каква роля играят A/B дяловете?

---

Схемата за A/B разделяне

Как работят актуализациите на устройства с безпроблемни актуализации

Много простото изображение, което направих по-долу, илюстрира как се обработва актуализация на устройство с поддръжка на A/B дял. Илюстрираният дял е системният дял, въпреки че други дялове като boot и vendor също могат да бъдат актуализирани с всяка дадена OTA актуализация от OEM. Този процес на актуализиране се случва не само с основни актуализации на версията на Android, но и с актуализации на корекции за сигурност.

1. Започваме с два системни дяла, system_a и system_b, и двата на една и съща версия на Android.
2. Ако приемем, че system_a е активен, OTA актуализацията ще коригира system_b, неактивния дял, във фонов режим.
3. system_a е настроен на неактивен и system_b след това става активен, след като потребителят се рестартира.
4. Сега неактивният дял, system_a, ще бъде актуализиран, когато бъде пусната следващата OTA актуализация.

Какви са предимствата на този процес на актуализиране?

1. Ако актуализацията е неуспешна, устройството ще се върне към работната компилация на другия слот.
2. Вашите данни се запазват напълно непокътнати, дори ако актуализацията е прекъсната, тъй като има само един дял (потребителски данни), който съдържа вашите данни.
3. Поточно предаване на актуализация: Ако вашият дял с данни е пълен, тогава актуализацията може да бъде изтеглена и поточно предавана към неактивния слот. Това е доста удобна функция и означава, че не е нужно да губите временно хранилище за вашите актуализации. Ето защо няма дял на кеша на A/B устройства, тъй като те вече не са необходими.

Какво влияние оказва A/B схемата за разделяне върху паметта на дадено устройство?

Фактът, че безпроблемните актуализации водят до куп дублирани дялове, означава ли, че губите куп място за съхранение? Въобще не. Google казва, че устройствата с безпроблемна поддръжка за актуализация трябва да бъдат свалени само с около няколкостотин мегабайта благодарение на премахването на дяловете /cache и /recovery. Премахването на двата балансира разходите за добавяне на втори набор от дялове. Според Google A/B системното изображение на Pixel е наполовина по-малко от A-само системното изображение. По-голямата част от допълнителното използване на хранилище всъщност идва от добавянето на втори дял на доставчика. Това има смисъл, тъй като дялът на доставчика съдържа всички собствени двоични файлове, използвани от производителите на оригинално оборудване (част от Project Treble), така че се очаква да заема доста място. Въпреки че Google не препоръчва A/B разделяне на устройства с 4 GB място за съхранение (тъй като това е почти 10% от общото налично място за съхранение), те го препоръчват на устройства с 8 GB и повече.

Ето разбивка на пространството за съхранение, използвано на Google Pixel със и без A/B дялове.

Какво стана с дяла за възстановяване?

Основното Linux ядро ​​на устройства с Android е това, което позволява на Android да разпознава и използва правилно хардуера на смартфон. На устройства с Android само за A обикновено имате две версии на ядрото: Едната е опакована вътре в дяла за възстановяване, докато другата е в дяла за зареждане. На A/B устройства, поддържащи безпроблемни актуализации, възстановяването вече е вътре в изображението за зареждане заедно с ядрото. Основната функция на възстановяването беше да инсталира актуализации, но тъй като това се обработва от самата система (update_engine), докато Android се зарежда, специалният дял за възстановяване вече не е необходим.

За да инсталираме персонализирано възстановяване на A/B устройства, трябва да модифицираме дяла за зареждане и да заменим стандартното възстановяване с нашето собствено. Ето защо, за да инсталирате TWRP, трябва да използвате команда fastboot, за да заредите първо персонализирано изображение за зареждане и тогава флашнете инсталационния скрипт на TWRP, тъй като fastboot не може да закърпи дялове - само флашнете върху тях изцяло. Технически бихте могли предварително да коригирате съществуващото си изображение за стартиране с TWRP и след това да го флашнете чрез fastboot, но това е повече проблем, отколкото си струва. Скриптът за инсталиране на TWRP коригира дяловете boot_a и boot_b, за да инсталира TWRP.

Забавен факт: Android update_engine, който се справя с безпроблемните актуализации, е основно извлечен направо от Chrome OS. Едва наскоро са низове, съдържащи „Chrome OS“, премахнати от регистрационния файл на update_engine, за да се избегне объркване за всеки, който се случи да провери logcat.

Моят смартфон с Android поддържа ли A/B дялове за безпроблемни актуализации?

Докато ние поддържайте списък на всички устройства които го подкрепят, можете също лесно да проверите себе си.

---

Как безпроблемните актуализации влияят върху персонализираното разработване?

Потребителско възприемане на A/B дялове

Смятани от много потребители за пречка за разработването на персонализиран софтуер, безпроблемните актуализации всъщност са благодат за разработчиците. Причината A/B устройствата да се възприемат като имат лоша поддръжка за разработка се свежда до цената на първите A/B устройства. В края на краищата, устройствата Google Pixel бяха едни от първите, които поддържаха безпроблемни актуализации и в сравнение със смартфоните Nexus от миналото бяха сравнително скъпи. Освен това, благодарение на безбройните подобрения, които Google направи в операционната система Android, която направи персонализирани ROM и модификации, които са по-малко популярни на устройствата на Google, смартфоните Google Pixel не се наложиха почти толкова добре в нашите форуми, колкото Nexus смартфони. Комбинация от външни фактори доведе до намаляване на персонализираната разработка на смартфоните Google Pixel, въпреки че повечето потребители избраха да обвинят вместо това поддръжката на A/B дялове. Сравнете наличността на персонализирана разработка на устройства като Google Pixel с устройства като Xiaomi Mi A1 на нашите форуми.

В допълнение, липсата на разбиране за това как A/B дяловете променят начина, по който потребителите трябва да инсталират персонализирани ROM, ядра, възстановяване и модификации, доведе до непопулярност на поддръжката на A/B дялове. Тъй като възстановяването сега живее вътре в изображението за зареждане, мигащите модификации в грешен ред, като Magisk или Xposed, могат да причинят конфликти и да доведат до цикъл на зареждане. Редът, в който флашвате тези модове, може да бъде важен, но в случай на персонализирани ROM не трябва да се притеснявате към кой слот флашвате. Противно на общоприетото схващане, инсталационният скрипт за повечето потребителски ROM не флашва и в двата слота. Най-вече не е нужно да се притеснявате за това, тъй като не трябва да разменяте слотовете ръчно.

Как разработчиците разглеждат A/B дялове

Когато изграждат ROM, разработчиците могат да използват и двата дяла, за да тестват отделни компилации. Ако някой не работи, те могат просто да се върнат обратно към работния дял и да възстановят своя ROM. Разработчиците могат също да тестват за регресии, като просто инсталират актуализация, превключат активния дял и сравняват двата, без да се налага да изтриват данни. Ето как екипът на LineageOS гледа на поддръжката на A/B дялове:

„Много от общността на Android критикуваха A/B като „трудно за поддръжка“ и „неудобно за разработчици“, когато всъщност е правилно внедрено по-лесен за поддръжка и също толкова удобен за разработчици." - jrizzoli, Журнал на промените в LineageOS 19

Първоначалната трудност с A/B поддръжката за разработчиците дойде от модифицирането на техните съществуващи инструменти за поддръжка на тези устройства. Разработчикът на Magisk, topjohnwu, добави официална поддръжка за Google Pixel година след това пуснат - не защото беше трудно, а по-скоро защото му отне една година, за да получи устройството работя върху. Поддръжка на TWRP дойде доста бързо на A/B устройства, след като водещият разработчик, Dees_Troy, се справи с него. LineageOS 15.1 сега поддържа A/B устройства, след като доброволците намериха време да поправят своя addon.d скрипт.

Как да актуализирате A/B устройство, което има персонализирано възстановяване, ядро ​​или други модификации

Персонализирани ROM

Мигането на актуализации на устройство с персонализиран ROM означава, че ще трябва да внимавате кой слот също флашвате, нали? Не точно. TWRP всъщност ще се справи с много от това вместо вас и по подразбиране е неактивен слот за мигане на персонализиран ROM. Ако вашият активен слот е A и флашвате персонализиран ROM, вие всъщност флашвате към слот B. Когато рестартирате, активният слот вече е B. Разработчиците могат да променят инсталационния скрипт и да флашват към двата слота, за да улеснят крайния потребител, въпреки че повечето персонализирани скриптове за инсталиране на ROM в момента флашват само към един слот. И накрая, персонализираните ROM могат да внедрят A/B актуализатор в своя ROM, така че потребителите дори не трябва да се забъркват с ръчно мигащи актуализации – най-новата LineageOS 15.1 включва инструмент за актуализиране на Lineage и XDA Senior Member САЩ-RedDragon направи а общ A/B актуализатор които други разработчици могат да използват.

Стокови ROM-ове

Но не е ли проблематично, ако устройството ви работи със стандартния ROM с различни модификации и искате да инсталирате актуализация, без да губите всички тези модификации? Може да е, ако не знаете правилните стъпки за инсталиране на актуализация. На OnePlus 6, например, не можете да флашнете инкрементален OTA на вашето модифицирано устройство, защото инкременталният OTA ще се опита да закърпи вашето модифицирано изображение за зареждане. По този начин най-вероятно ще се окажете с цикъл на зареждане и затова трябва да флашнете пълната актуализация на ROM, за да презапишете напълно вашето модифицирано изображение за зареждане. Ето общите стъпки, които трябва да предприемете, за да инсталирате актуализация на OxygenOS на вашия OnePlus 6, като същевременно запазите TWRP, Magisk и по избор персонализирано ядро.

1. Изтеглено най-новото пълен ROM цип
2. Флашнете пълния ROM zip при възстановяване
3. (По избор) Флаш персонализирано ядро
4. Flash TWRP инсталатор
5. Рестартирайте направо обратно към възстановяване
6. Flash Magisk

На устройствата Google Pixel можете флаш фабричното изображение без изтриване на данни, след това стартирайте TWRP, инсталирайте TWRP чрез инсталационния скрипт, след което инсталирайте Magisk.

Извличане на актуализация за флашване на отделни изображения на дялове

Актуализиращите файлове за много A/B устройства са малко по-различни в сравнение с A-само устройствата. Те вече не са просто zip файл, съдържащ много изображения (с изключение на фабричните изображения на Google и Razer), вместо това те са под формата на файл payload.bin. Можете да извлечете този файл и да флашнете всяка част ръчно, но за това е необходим специален инструмент. Ако се интересувате да научите как да го направите на OnePlus 6, Xiaomi Mi A1 и много други A/B устройства, прочетете нататък.

Настройка за извличане на payload.bin

1. Уверете се, че имате Python 3.6 инсталиран.
2. Изтеглете payload_dumper.py и update_metadata_pb2.py тук.
3. Разархивирайте вашия OTA zip файл и поставете payload.bin в същата папка като тези файлове.
4. Отворете PowerShell, командния ред или терминал в зависимост от вашата операционна система.
5. Въведете следната команда: python -m pip install protobuf
6. Когато това приключи, въведете тази команда: python payload_dumper.py payload.bin
7. Това ще започне да извлича изображенията във файла payload.bin в текущата папка, в която се намирате.

Можете да флашнете всяко от тези изображения отделно сега чрез fastboot, ако желаете. Следващият раздел ви показва как да направите това.

Използване на fastboot за флаш изображения на устройство, което поддържа безпроблемни актуализации

Има редица команди, които са ексклузивни за A/B системни устройства за дялове. Можете да промените активния си слот и флаш на конкретни слотове. Ако имате Project Treble-съвместимо устройство и искате да научите как флаш генерични системни изображения, трябва да сте запознати с тези команди. Разгледайте таблицата по-долу.

(Забележка: На A/B устройства можете или да посочите дял в конкретен слот, към който да мигате, или можете да оставите суфикса на слота и той ще мига към текущия активен слот. Например, можете да замените "дял" в командата за флаш със "система", "система_a" или "система_b.")

---

Няколко думи за Project Treble и безпроблемните актуализации

Често срещано погрешно схващане е, че поддръжката на Project Treble и поддръжката на A/B дялове са свързани помежду си, но това всъщност не е така. Наличието на едното не предполага другото. Motorola Moto Z2 Force използва A/B схема за разделяне, но не поддържа Treble. От друга страна, Honor 9 Lite поддържа Project Treble, но е устройство само за A.

---

Често задавани въпроси/Резюме

• Какви са предимствата на A/B разделянето?
  • A/B разделянето ви позволява да актуализирате своя Android смартфон, докато го използвате, като просто рестартирате, когато сте готови да стартирате новата версия. Той също така действа като защита срещу тухли - ако актуализацията се обърка, ще се върнете към работещата инсталация.
• Наличието на A/B разделяне пречи ли на развитието?
  • Въпреки че на разработчиците им отне малко време да се адаптират, отговорът е почти не. Всъщност това може да помогне на разработчиците, тъй като те могат да стартират двойно своя персонализиран ROM със старата версия и нова версия за тестване, за да проверят за регресии.
• Как A/B дяловете влияят на модификации като персонализирани ядра, Magisk или Xposed?
  • Трябва да внимавате, когато ги инсталирате, но в момента няма проблеми. Magisk официално поддържа устройства с безпроблемни актуализации и докато флашвате нещата в правилния ред, не би трябвало да имате проблеми. Уверете се, че сте флашнали персонализираното ядро, преди да флашнете другите си модове, и трябва да сте готови.
• Мога ли да флашна два различни ROM-а на всеки дял и двойно зареждане?
  • На теория да. Въпреки това възникват проблеми поради дяла със споделени данни, така че не се препоръчва.
• Наличието на A/B схема за дялове означава ли, че имам намалено място за съхранение?
  • не! Google казва, че устройствата, които поддържат безпроблемни актуализации, жертват само няколкостотин мегабайта място за съхранение, за да го поддържат. Ползите надвишават тези разходи.
• Устройството ми поддържа A/B дялове, означава ли това, че мога да използвам Generic System Image на Project Treble?
  • Не е задължително. Поддръжката на Project Treble и A/B не са свързани. Motorola Moto Z2 Force не поддържа Project Treble, но поддържа A/B схемата за разделяне.
• Устройството ми поддържа Project Treble, означава ли това, че имам A/B схема за разделяне?
  • Това не винаги е така. Honor 9 Lite е отличен пример, тъй като поддържа Project Treble, но няма A/B схема за разделяне.
• Защо трябва първо да стартирам TWRP с fastboot и след това да го флашна?
  • Това се дължи на начина на работа на fastboot и на факта, че дялът за възстановяване вече не съществува. Възстановяването се поставя вътре в дяла за зареждане, така че трябва да променим както boot_a, така и boot_b. Не можете да закърпите дял в fastboot, само флашнете върху него. На теория бихте могли да направите предварително подправено изображение за зареждане и след това да го флашнете вместо това.
• Има ли някакви опасности с A/B прегради? Как защитата от връщане се отразява на нещата?
  • Google се опита да направи всичко възможно това да не е проблем, но в случая с Motorola Moto Z2 Force, имаше известни случаи на устройство, което реактивира по-стария слот след надграждане до Android Орео. Това означаваше, че защитата от връщане се включи и собствениците на устройства можеха да спасят своя смартфон само с EDL възстановяване. Google казва, че защитата от връщане се задейства само след първото зареждане, така че слотът трябва да функционира напълно след актуализация, преди да можете повече да понижавате.