Без изворног кода, како програмери добијају хардверске компоненте као што су камере које раде у прилагођеним РОМ-овима? Одговор је БЛОБ, подметач и пуно отклањања грешака.
Са издавањем Андроид Орео-а и многих уређаја као што су Ксиаоми Редми Ноте 3, Гоогле Некус 5 и други га незванично добијају, вероватно је поштено запитати се зашто исте функције (углавном камера) имају тенденцију да буду покварене када програмери преносе РОМ заснован на Андроид Опен Соурце Пројецт-у (АОСП). Вероватно сте видели КСДА форумске теме РОМ-ова са дугачком листом покварених функција на врху. „Шта функционише“, праћено листом радних функција, а испод тога икона „Шта не функционише? Ти ми реци!" су два популарна рефрена на нашим форумима који су практично постали мем на местима као што су Реддит и Твиттер.
Зашто је толика функционалност покварена кад год програмер покуша да пренесе АОСП РОМ на свој уређај? Основни одговор је да пошто се функције мењају у различитим верзијама Андроид-а, стари драјвери уређаја упаковани као БЛОБ-ови неће радити са новијим верзијама Андроид-а, па чак ни само са стандардним АОСП-ом. Да би то превазишли, програмери користе оно што се зове „шим“, али процес који је укључен је тежак, временски интензиван и понекад веома тежак за отклањање грешака.
У овом чланку ћемо описати како функционишу подлошци, посебно у погледу правилног рада камере на АОСП базираним РОМ-овима. Користићемо ОнеПлус 3Т као пример. Имајте на уму да су потешкоће у функционисању ових функција веома специфичне за уређај.
ОнеПлус 3Т ради ОкигенОС. Иако су ОнеПлус телефони познати по својој прилагођености развоју, програмери доста раде иза кулиса како би направили стабилне портове АОСП-а.
Шта је подметач или БЛОБ?
Да бисмо чак и почели да разумемо део онога што програмери раде, прво морамо да објаснимо неколико ствари. Иако је Андроид ОС отвореног кода (са разлогом се зове Андроид Опен Соурце Пројецт), софтвер (без кернела) који се испоручује на хиљадама Андроид уређаја није. Програмери немају приступ изворном коду Самсунг Екпериенце, ЕМУИ, ОкигенОС, или било коју другу верзију Андроида независних произвођача.
Сада, програмери који преносе залихе АОСП на уређај који није Гоогле-ов вероватно не маре за изворни код ових Андроид скинова јер они неће бити модификовање и прављење ових РОМ-ова. То би било тачно, ако не због једног великог, великог разлога: углавном делова неопходних да би камера исправно радила тхе камера ХАЛ (Слој хардверске апстракције), су такође затворен извор.
Проблем са поседовањем не само ХАЛ камере већ и РОМ затвореног кода је тај што ће програмери који раде на преношењу АОСП-а на свој уређај бити радећи на слепо. ОЕМ РОМ са затвореним извором може добро да се повеже са ХАЛ камером јер ОЕМ има приступ ХАЛ извору камере. ХАЛ камере је оно што омогућава РОМ-у да „разговара“ са хардвером камере – без њега камера не би била функционална. Замислите камеру ХАЛ као волан и педале аутомобила. Волан/педале омогућавају контролу унутрашњих компоненти возила обезбеђујући спољни интерфејс за возача (РОМ) да користи унутрашње компоненте.
Како хардвер камере постаје све сложенији ( појава двоструких камера, на пример), поседовање приступа ХАЛ извору камере учинило би пренос АОСП РОМ-а са функционалном камером много лакшим подухватом.
Међутим, произвођачи оригиналне опреме не пружају приступ ХАЛ извору камере из различитих разлога. Прво, ако немају сва власничка права на камеру ХАЛ (као што је када инкорпорирају интелектуалну својину других компанија), онда не могу да дистрибуирају извор. Друго, пуштање ХАЛ извора камере може угрозити њихову сопствену интелектуалну својину. Коначно, компаније немају законску обавезу да обезбеде овај изворни код (за разлику од изворног кода кернела који јесу обавезан за пуштање под ГПЛ), тако да немају подстицај да га ослободе. Дакле, без приступа ХАЛ извору камере, како тачно програмери натерају камеру да ради на АОСП РОМ-овима? Одговор је БЛОБ, подметач и пуно и пуно отклањања грешака.
Уређај БЛОБ (Бинари Ларге ОБјецт) садржи унапред упаковане бинарне датотеке које су компајлирани облик софтвера. У овом случају, извор ХАЛ камере компајлира ОЕМ и испоручује се на уређаје као бинарне датотеке. Када програмери говоре о БЛОБ-овима, они се односе на оне бинарне датотеке које се испоручују на живим уређајима које су у стању да издвоје. Сада је тема „камера БЛОБс“. дуго мучи ОнеПлус већ много месеци, али истина је да су програмери увек имали приступ БЛОБ-овима камере. Тхе камера ХАЛ изворни код је златна карта за програмере овде, додуше, али то хоће никада, никада не бити пуштен због правне опасности то би ставило компаније као што је ОнеПлус.
Стога, програмери који желе да унесу АОСП на уређај остају само са БЛОБ-овима ХАЛ-а камере за које немају приступ изворном коду. Ретко, ако икад, програмер може да упари свој АОСП РОМ код са камером ХАЛ БЛОБ и очекује да она функционише, тако да како би премостили јаз између ова два, програмери креирају оно што се зове „схим.”
„Заглавити“ значи „заглавити (нешто) или попунити простор“. Ово је ефективно оно што програмер ради када писање подлошка—они додају код како би омогућили БЛОБ-у да се повеже са АОСП изворним кодом на којем раде са. Подлошке се користе да би БЛОБ-ови свих различитих врста функционисали са АОСП-ом, али обично БЛОБ камере захтева највише светлуцања. Као што смо раније споменули, шимовање је потребно не само за пренос новијих верзија Андроид-а на уређај (као нпр. сви ти незванични Андроид Орео РОМ-ови), али такође потребни када се преноси АОСП исте верзије Андроид-а на то уређај.
Препоручено читање: Од продавнице до полице: детаљна капитулација зашто су МСМ8974 уређаји искључени из Ноугат-а
ОнеПлус 2 је, на пример, добио свој последње званично велико ажурирање ОС-а у облику Андроида 6.0 Марсхмаллов. Уређај, међутим, заправо има потпуно функционални прилагођени РОМ-ови засновани на АОСП-у заснован на Андроид Ноугат-у, а то је захваљујући напорном раду програмера и њихових схим-ова. Разложићемо неке примере подметача, али прво морамо да разговарамо о томе како тачно функционишу подметачи.
Како ради шимминг?
Пошто програмери немају приступ ХАЛ или ОЕМ РОМ извору камере (и само унапред компајлираним бинарним датотекама), не могу знати које функције камера ХАЛ очекује. Због тога често постоји неусклађеност између назива функције коју камера ХАЛ тражи и стварног назива функције у АОСП коду са којим програмер ради.
Да би решио овај проблем, програмер једноставно креира нову функцију која користи исто име функцију коју камера ХАЛ БЛОБ очекује, али ова нова функција само извршава оно што програмер жели то до. Ова нова функција која делује као посредник између БЛОБ-а и АОСП-а је подметач. Овај конкретни сценарио у којем БЛОБ не успева да пронађе функцију коју тражи је један од најчешћих где је потребна подлошка.
Можда ће ствари имати мало више смисла са хипотетичким примером који укључује ОнеПлус 3Т. Направићемо пример користећи ОкигенОС и ОнеПлус камеру. Ако користимо БЛОБ-ове камере преузете из ОкигенОС Ноугат-а за ОнеПлус 3Т да направимо Ноугат РОМ заснован на АОСП-у, можемо наићи на проблеме. То је зато што ће БЛОБ-ови камере (које је првобитно саставио ОЕМ) моћи да упућују на све функције које су му потребне унутар ОкигенОС-а, али пошто компајлирани АОСП РОМ можда нема те функције или их је можда компајлирао под другим именом (што доводи до неслагања између симбола функције), постојаће грешка. Ово се може поправити креирањем нове функције унутар АОСП РОМ-а са именом које БЛОБ очекује — наш схим.
Симболи у програмском контексту се користе за упућивање на специфичне функције у коду. Симболи су неопходни јер се позиција функције може променити када се код уређује, и тако да би се избегло тврдо кодирање референце на функције, компајлер креира табелу симбола које друге функције могу да користе да увек упућују на десно функција. Када промените име функције пре компајлирања, мења се и њен симбол, тако да се у суштини све промене који ОЕМ направи за камеру ХАЛ извор пре компилације ће захтевати од програмера да креирају нови схим.
Објашњење које смо до сада понудили чини да звучи као да је стварање подметача лако. Промена неколико имена функција ту и тамо не звучи превише тешко, зар не? Да је бар тако лако. Реалност подметача укључује више од само преименовања функција. Разговарали смо са КСДА признатим програмером Султанкда који је био у могућности да нам пружи пример једног од најтежих подметача на којима је радио.
Шимминг - није тако лако као што звучи
За оне који нису упознати са ОнеПлус 3Т, предња камера је у почетку била прилично покварена Прилагођени РОМ-ови засновани на АОСП-у. За почетак, покушај снимања било које слике преко 8МП би резултирао црасхинг. У свом покушају да реши ово питање, Султанкда је направио неколико подлошке да омогућите да предња камера ОнеПлус 3Т ради исправно.
Шим #1 - Промена назива пакета камере
Да би спречио да се предња камера сруши сваки пут када корисник сними слику преко 8МП, Султанкда је натерао камеру ХАЛ да идентификује све камере као ОнеПлус камеру. Ово је учињено зато што је ОнеПлус одлучио да посвети помоћну функцију одређеним апликацијама (isOnePlusCamera, isFacebookCamera, итд.) из неког разлога. Султанкда је ово поправио тако што је подесио камеру ХАЛ-ом тако да указује на нову функцију која увек враћа „труе“ као да корисник користи ОнеПлус камеру — чак и када то није случај.
Шим #2 - Онемогућите КуадраЦфа
За свој следећи схим, морао је да онемогући КуадраЦфа, што је вероватно власничка Куалцомм технологија која се односи на камеру. Кажемо вероватно зато што ни ја ни Султанкда нисмо тачно сигурни шта је КуадраЦфа, али Султанкда зна да је покварио предњу камеру кад год је била омогућена.
Приметио је да ће се КуадраЦфа некако омогућити, али није био сигуран зашто и како то ради. Решавање овога захтевало је прилично неконвенционалну модификацију са његове стране. У конвенционалном подлошку, функција схим, када се компајлира, обезбеђује симбол који недостаје који БЛОБ тражи. У овом случају, БЛОБ је већ имао симболе који су му били потребни — оне који су вероватно представљали функције које су покретале КуадраЦфа.
Стога је морао да замени симболе које користи камера ХАЛ и да их у суштини учини да „недостају“ тако да његов подлошке би обезбедиле оне „недостајуће“ симболе. Једини начин да се то уради је преко хексадецимално уређивање саме камере ХАЛ. Хек уређивање је у основи прегледавање гомиле неорганизованих глупости у облику бинарних података како би се пронашла игла у пласту сена — било функција или стринг који желите да уредите.
Хексадецимално уређивање функције је знатно теже него хексадецимално уређивање стринга, али на срећу, Султанкда је успео да избегне хексадецимално уређивање функција иза КуадраЦфа. хексадецимално уређивање имена симбола да поништи те симболе.
Подложак #3 - Исправка судара са јаким светлом
Следеће, Султанкда је идентификовао да би снимање слике са предње камере у условима јаког осветљења изазвало пад камере. Да би репродуковао ову грешку на свом уређају, Султанкда заправо укључио функцију батеријске лампе на свом ОнеПлус Оне и упалио светло испред предње камере ОнеПлус 3Т како би се срушио и произвео употребљиве дневнике! Када је открио која функција је узроковала пад, направио је подлошку да би приморао уређај да користи режим слабог осветљења све време за предњу камеру.
Подметач #4 – Слике предње камере ниске резолуције
Након што је поправио пад јаког светла са претходним подлошком, Султанкда је открио још једну грешку која је заправо настала као директан резултат те подлошке: слике са предње камере ниске резолуције. Уместо да сликате у резолуцији коју захтева корисник (нпр. 16МП), резултујућа слика би била снимљена на 4МП.
Решавање овога захтевало је да подеси функције handleSuperResolution и isSuperResolution да увек враћа труе, али САМО када је предња камера активна (јер би се у супротном камера срушила приликом снимања слика са задњег сензора).
Научена лекција - Шимминг може бити тежак
Султанкда признаје да подлошке које је морао да направи да би предња камера ОнеПлус 3Т радила не представљају типичан пример подметача. Прилично је поносан на своју подлошку с обзиром на њену сложеност и ретку потребу да се хек уређује сам БЛОБ. Али овај пример само показује колико тешко може бити да се хардвер камере ради на одређеним уређајима.
Нека ваше авантуре са подметачем камере буду мање болне од мојих. -Султанкда
Дневници, евиденције и још евиденције. Без доследног начина да се репродукује пад и без евиденције, програмери немају много наде да ће пронаћи извор проблема. Чак и ако открију шта узрокује проблем, то није увек једноставно решење. Цео процес проналажења и гњечења ових грешака може потрајати данима или недељама и разлог је зашто је поправљање камере на АОСП РОМ-овима један од тежих задатака.
Ако ваш уређај има АОСП РОМ портован на њега са потпуно функционалним хардвером, надамо се да можете почети да цените борбу кроз коју су ти програмери можда прошли да би вам их донели Карактеристике. Цените их на њиховом раду, јер није лако. То је много посла који велика већина корисника неће ни приметити, јер талентовани програмери на нашим форумима брину о многим невидљивим деловима Андроид-а.
Желели бисмо да се посебно захвалимо Султанкди за многе доприносе које је предложио приликом израде овог чланка.