Без изходния код, как разработчиците получават хардуерни компоненти като камери, работещи в персонализирани ROM? Отговорът е BLOB, shim и много отстраняване на грешки.
С пускането на Android Oreo и много устройства като Xiaomi Redmi Note 3, Google Nexus 5 и други го получават неофициално, вероятно е справедливо да се зачудим защо едни и същи функции (най-вече камерата) са склонни да се повреждат, когато разработчиците пренасят ROM, базиран на Android Open Source Project (AOSP). Вероятно сте виждали нишки на XDA форум за ROM с дълъг списък от повредени функции отгоре. „Какво работи“, последвано от списък с работещи функции, след това по-долу емблематичното „Какво не работи? Ти ми кажи!" са два популярни рефрена в нашите форуми, които на практика са се превърнали в мем на места като Reddit и Twitter.
Защо толкова много функционалност се нарушава, когато разработчик се опита да пренесе AOSP ROM на своето устройство? Основният отговор е, че тъй като функциите се променят в различните версии на Android, старите драйвери на устройства, пакетирани като BLOB, няма да работят с по-нови версии на Android или дори само със стандартен AOSP. За да преодолеят това, разработчиците използват това, което се нарича „shim“, но участващият процес е труден, отнема време и понякога е много труден за отстраняване на грешки.
В тази статия ще очертаем как работят подложките, особено по отношение на правилното функциониране на камерата на базирани на AOSP ROM. Ще използваме OnePlus 3T като пример. Имайте предвид, че трудността, свързана с работата на тези функции, е силно специфична за устройството.
OnePlus 3T с OxygenOS. Въпреки че телефоните OnePlus са известни със своята персонализирана разработка, има много работа, която разработчиците вършат зад кулисите, за да направят стабилни портове на AOSP.
Какво е shim или BLOB?
За да започнем дори да разбираме част от това, което разработчиците правят, първо трябва да обясним няколко неща. Въпреки че операционната система Android е с отворен код (няма причина се нарича Android Open Source Project), софтуерът (без ядрото), доставян на хиляди устройства с Android, не е такъв. Разработчиците нямат достъп до изходния код на Samsung Experience, EMUI, OxygenOS, или някоя от другите разновидности на Android на трети страни.
Сега разработчиците, които пренасят стандартен AOSP към устройство, различно от Google, вероятно не се интересуват от изходния код на тези кожи на Android, тъй като те няма да бъдат модифициране и изграждане на тези ROM. Това би било вярно, ако не беше поради една голяма, голяма причина: главно частите, необходими за правилното функциониране на камерата на камера HAL (Слой на хардуерна абстракция), са също затворен код.
Проблемът с наличието не само на HAL на камерата, но и на ROM със затворен код е, че разработчиците, които работят по пренасянето на AOSP на своите устройства, ще бъдат работа на сляпо. OEM ROM със затворен код може да взаимодейства добре с HAL на камерата, защото OEM има достъп до HAL източника на камерата. HAL на камерата е това, което позволява на ROM да „разговаря“ с хардуера на камерата – без него камерата нямаше да функционира. Мислете за камерата HAL като за волан и педали на колата. Воланът/педалите позволяват контрол на вътрешните компоненти на превозното средство чрез предоставяне на външен интерфейс за водача (ROM), за да използва вътрешните компоненти.
Тъй като хардуерът на камерата става все по-сложен (the появата на двойни камери, например), достъпът до HAL източника на камерата би направил пренасянето на AOSP ROM с функционална камера много по-лесно начинание.
Производителите на оригинално оборудване обаче не предоставят достъп до HAL източника на камерата по различни причини. Първо, ако нямат всички права на собственост върху HAL на камерата (като например когато включват интелектуална собственост от други компании), тогава те не могат да разпространяват източника. Второ, освобождаването на HAL източника на камерата може да застраши собствената им интелектуална собственост. И накрая, компаниите нямат правно задължение да предоставят този изходен код (за разлика от изходния код на ядрото, какъвто са задължен да пусне съгласно GPL), следователно те нямат стимул да го пуснат. И така, без достъп до HAL източника на камерата, как точно разработчиците карат камерата да работи на AOSP ROM? Отговорът е BLOB, shim и много, много отстраняване на грешки.
Уред BLOB (Binary Large OBject) съдържа предварително опаковани двоични файлове, които са компилираната форма на софтуер. В този случай HAL източникът на камерата се компилира от OEM и се доставя на устройства като двоични файлове. Когато разработчиците говорят за BLOB, те имат предвид тези двоични файлове, които се доставят на живи устройства, които те могат да извлекат. Сега, темата за "camera BLOBs" има дълго измъчван OnePlus в продължение на много месеци, но истината е, че разработчиците винаги са имали достъп до камерите BLOB. The HAL изходният код на камерата е златният билет за разработчиците тук обаче, но това ще стане никога, никога да не бъде освободен поради правната опасност, в която би изложила компании като OnePlus.
По този начин разработчиците, които искат да внедрят AOSP в устройство, остават само с BLOB на камерата HAL, за която нямат достъп до изходния код. Рядко, ако изобщо, разработчик може да сдвои своя AOSP ROM код с камерата HAL BLOB и да очаква той да работи, така че, за да преодолеят празнината между двете, разработчиците създават това, което се нарича „подложка.”
Да „отминеш“ означава да „вклиниш (нещо) или да запълниш пространство“. Това на практика прави разработчикът, когато писане на подложка - те добавят код, за да позволят на BLOB да взаимодейства с изходния код на AOSP, с който работят с. Подложките се използват, за да накарат BLOB от различни видове да работят с AOSP, но обикновено камерата BLOB е тази, която изисква най-много блясъци. Както споменахме преди, shimming се изисква не само за пренасяне на по-нови версии на Android на устройство (като напр. всички тези неофициални Android Oreo ROM), но също така са необходими при пренасяне на AOSP на същата версия на Android върху това устройство.
Препоръчителна литература: От магазина до рафта: Задълбочена капитулация защо устройствата MSM8974 са изключени от Nougat
OnePlus 2, например, получи своето последната официална основна актуализация на ОС под формата на Android 6.0 Marshmallow. Устройството обаче всъщност има напълно работещи потребителски базирани на AOSP ROM базиран на Android Nougat и това е благодарение на упоритата работа на разработчиците и техните подложки. Ще разбием някои примери за подложки, но първо трябва да поговорим как точно работят подложките.
Как работи shiming?
Тъй като разработчиците нямат достъп до източника на HAL или OEM ROM на камерата (и само предварително компилираните двоични файлове), те не могат да знаят какви функции очаква HAL на камерата. Поради това често има несъответствие между името на функцията, която HAL на камерата търси, и действителното име на функцията в AOSP кода, с който разработчикът работи.
За да разреши този проблем, разработчикът просто създава нова функция, която използва същото име на функция, която камерата HAL BLOB очаква, но тази нова функция просто изпълнява това, което разработчикът иска то да. Тази нова функция, която действа като посредник между BLOB и AOSP, е подложката. Този конкретен сценарий, при който BLOB не успява да намери функцията, която търси, е един от най-често срещаните, при които е необходима подложка.
Може би нещата ще имат малко повече смисъл с хипотетичен пример, включващ OnePlus 3T. Ще създадем пример с помощта на OxygenOS и камерата OnePlus. Ако използваме BLOB файлове на камерата, взети от OxygenOS Nougat за OnePlus 3T, за да изградим Nougat ROM, базиран на AOSP, може да срещнем проблеми. Това е така, защото BLOB файловете на камерата (които първоначално са били компилирани от OEM) ще могат да препращат към всички функции, от които се нуждае в рамките на OxygenOS, но тъй като компилираният AOSP ROM може да няма тези функции или да ги е компилирал под различно име (което води до несъответствие между функционалните символи), ще има грешка. Това може да бъде коригирано чрез създаване на нова функция в рамките на AOSP ROM с името, което BLOB очаква - нашата подложка.
Символите в програмен контекст се използват за обозначаване на специфични функции в кода. Символите са необходими, защото позицията на функция може да се промени, когато кодът се редактира, и така, за да се избегне твърдото кодиране препратки към функции, компилаторът създава таблица със символи, които другите функции могат да използват, за да препращат винаги отдясно функция. Когато промените името на функция преди компилиране, нейният символ също се променя, така че по принцип всички промени който OEM прави на камерата HAL източник преди компилация, ще изисква от разработчиците да създадат нов подложка.
Обяснението, което предложихме досега, звучи така, сякаш създаването на подложки е лесно. Промяната на няколко имена на функции тук и там не звучи твърде трудно, нали? Само ако беше толкова лесно. Реалността на подложките включва повече от просто преименуване на функции. Говорихме с XDA Recognized Developer Sultanxda, който успя да ни даде пример за една от по-трудните подложки, върху които е работил.
Шиминг - не е толкова лесно, колкото звучи
За тези, които не са запознати с OnePlus 3T, предната камера беше доста счупена първоначално на Базирани на AOSP потребителски ROM. Като начало, опитът да направите снимка над 8MP ще доведе до трясък. В опита си да разреши този проблем, Sultanxda направи няколко подложки за да може предната камера на OnePlus 3T да работи правилно.
Shim #1 - Промяна на името на пакета на камерата
За да спре предната камера от срив, когато потребителят направи снимка над 8MP, Sultanxda принуди камерата HAL да идентифицира всички камери като камерата на OnePlus. Това се прави, защото OnePlus реши да посвети помощна функция на определени приложения (isOnePlusCamera, isFacebookCameraи т.н.) по някаква причина. Sultanxda поправи това, като шири HAL на камерата, така че да сочи към нова функция, която винаги връща „истина“, сякаш потребителят използва камерата на OnePlus – дори когато не е.
Shim #2 - Деактивирайте QuadraCfa
За следващата си подложка той трябваше да деактивира QuadraCfa, което вероятно е патентована технология на Qualcomm, свързана с камерата. Казваме вероятно, защото нито аз, нито Sultanxda сме сигурни какво е QuadraCfa, но Sultanxda знае, че е счупил предната камера, когато е била активирана.
Той забеляза, че QuadraCfa по някакъв начин ще се активира, но не беше сигурен защо или как го прави. Решаването на това изисква доста нетрадиционна модификация от негова страна. В конвенционален shim функцията shim, когато се компилира, предоставя липсващия символ, който BLOB търси. В този случай BLOB вече имаше символите, от които се нуждаеше - тези, които предполагаемо представляваха функциите, които стартираха QuadraCfa.
По този начин той трябваше да замени символите, използвани от камерата HAL и по същество да ги направи „липсващи“, така че неговият подложките биха предоставили тези „липсващи“ символи. Единственият начин да направите това е чрез hex редактиране на самата камера HAL. Шестнадесетичното редактиране е основно преглеждане на куп неорганизирани безсмислици под формата на двоични данни, за да се намери игла в купа сено - или функция, или низ, който искате да редактирате.
Шестнадесетичното редактиране на функция е значително по-трудно от шестнадесетичното редактиране на низ, но за щастие Sultanxda успя да избегне необходимостта от шестнадесетично редактиране на функциите зад QuadraCfa, като вместо това шестнадесетично редактиране на имената на символите, за да анулира тези символи.
Shim #3 - Поправка на срив на ярка светлина
След това Sultanxda установи, че правенето на снимка от предната камера при условия на ярко осветление ще доведе до срив на камерата. За да възпроизведе тази грешка на собственото си устройство, Sultanxda всъщност включи функцията за фенерче на своя OnePlus One и освети светлината пред предната камера на OnePlus 3T за да го накара да се срине и да създаде използваеми регистрационни файлове! След като откри каква функция причинява срива, той създаде подложка, за да принуди устройството да използва режим на слаба светлина през цялото време за предната камера.
Shim #4 - Снимки с предна камера с ниска разделителна способност
След като поправи срива на ярката светлина с предишния shim, Sultanxda откри друг бъг, който всъщност възникна като пряк резултат от този shim: снимки с предна камера с ниска разделителна способност. Вместо да правите снимки с желаната от потребителя резолюция (напр. 16MP), получената снимка ще бъде направена на 4MP.
Решаването на това изискваше той да изпълни функциите handleSuperResolution и isSuperResolution винаги да връща true, но САМО когато предната камера е активна (защото в противен случай камерата ще се срине, когато прави снимки от задния сензор).
Научен урок – подреждането може да бъде трудно
Sultanxda признава, че подложките, които е трябвало да създаде, за да работи предната камера на OnePlus 3T, не представляват типичния пример за подложка. Той доста се гордее със своята подложка предвид нейната сложност и рядката необходимост от шестнадесетично редактиране на самия BLOB. Но този пример просто показва колко трудно може да бъде да накарате хардуера на камерата да работи на определени устройства.
Нека твоите приключения с подложката на камерата бъдат по-малко болезнени от моите. -Султанджа
Цепеници, трупи и още трупи. Без последователен начин за възпроизвеждане на срив и без регистрационни файлове разработчиците нямат голяма надежда да намерят източника на проблема. Дори и да открият какво причинява проблема, това не винаги е лесно решение. Целият процес на намиране и отстраняване на тези грешки може да отнеме дни или седмици и е причината, поради която коригирането на камерата на AOSP ROM е една от по-трудните задачи.
Ако вашето устройство има пренесен към него AOSP ROM с напълно функциониращ хардуер, надяваме се, можете да започнете оценявам борбата, през която може да са преминали тези разработчици, за да ви ги донесат Характеристика. Оценете ги за труда им, защото не е лесен. Това е много работа, която по-голямата част от потребителите дори няма да забележат, тъй като талантливи разработчици в нашите форуми се грижат за многото невидими части на Android.
Бихме искали да благодарим специално на Sultanxda за многото приноси, които предложи при направата на тази статия.