Kaamerad kohandatud ROM-ides: kuidas arendajad panevad riistvara töötama ilma lähtekoodita

Kuidas saavad arendajad ilma lähtekoodita riistvarakomponendid, nagu kaamerad, töötama kohandatud ROM-ides? Vastus on BLOB, shim ja palju silumist.

Android Oreo ja paljude seadmete, näiteks Xiaomi Redmi Note 3, Google Nexus 5 ja teised saavad seda mitteametlikult, on ilmselt õiglane küsida, miks kipuvad samad funktsioonid (peamiselt kaamera) katki minema, kui arendajad portivad Androidi avatud lähtekoodiga projektil (AOSP) põhineva ROM-i. Olete ilmselt näinud XDA foorumi ROM-ide lõime, mille ülaosas on pikk nimekiri katkilistest funktsioonidest. "Mis töötab", millele järgneb tööfunktsioonide loend, seejärel ikooniline "Mis ei tööta? Sina ütle mulle!" on meie foorumites kaks populaarset refrääni, millest on praktiliselt saanud meem sellistes kohtades nagu Reddit ja Twitter.

Miks läheb nii palju funktsioone katki, kui arendaja proovib oma seadmesse portida AOSP ROM-i? Põhiline vastus on see, et kuna funktsioonid Androidi erinevates versioonides muutuvad, ei tööta BLOB-idena pakendatud vanad seadmedraiverid Androidi uuemate versioonidega ega isegi ainult varu AOSP-ga. Sellest ülesaamiseks kasutavad arendajad nn "seib", kuid see protsess on keeruline, aeganõudev ja mõnikord väga raske siluda.

Selles artiklis kirjeldame, kuidas seibid töötavad, eriti mis puudutab kaamera korralikku töötamist AOSP-põhistel ROMidel. Näitena kasutame OnePlus 3T. Pange tähele, et nende funktsioonide tööle panemisega kaasnevad raskused on väga seadmespetsiifilised.

OnePlus 3T, milles töötab OxygenOS. Kuigi OnePlusi telefonid on tuntud oma kohandatud arendussõbralikkuse poolest, teevad arendajad AOSP stabiilsete portide loomiseks kulisside taga palju tööd.


Mis on vaheplaat või BLOB?

Selleks, et hakata isegi aru saama sellest, mida arendajad teevad, peame kõigepealt selgitama mõnda asja. Kuigi Android OS on avatud lähtekoodiga (seda kutsutakse mingil põhjusel Androidi avatud lähtekoodiga projektiks), ei ole tuhandetes Android-seadmetes tarnitav tarkvara (tuumadeta) mitte. Arendajatel pole juurdepääsu lähtekoodile Samsungi kogemus, EMUI, OxygenOSvõi mõni muu Androidi kolmanda osapoole maitse.

Tõenäoliselt ei hooli arendajad, kes teisaldavad varu AOSP-d mitte-Google'i seadmesse, nende Android-skinade lähtekoodist, kuna need ei hakka olema nende ROMide muutmine ja ehitamine. See oleks tõsi, kui mitte ühel suurel, suurel põhjusel: peamiselt osad, mis on vajalikud kaamera korralikult töötamiseks a kaamera HAL (Riistvara abstraktsioonikiht), on ka suletud lähtekoodiga.

Mitte ainult kaamera HAL-i, vaid ka suletud lähtekoodiga ROM-i probleem seisneb selles, et arendajad, kes töötavad AOSP oma seadmesse portimisega, on töötav pime. Suletud lähtekoodiga OEM-i ROM saab kaamera HAL-iga hästi liidestada, kuna originaalseadmete tootjal on juurdepääs kaamera HAL-i allikale. Kaamera HAL võimaldab ROM-il kaamera riistvaraga "vestelda" - ilma selleta ei töötaks kaamera. Mõelge kaamerale HAL kui auto roolile ja pedaalidele. Rool/pedaalid võimaldavad juhtida sõiduki sisemisi komponente, pakkudes juhile välist liidest (ROM) sisemiste komponentide kasutamiseks.

Kaamera arhitektuuri kujutav graafik. Allikas: Google

Kaamera riistvara muutub üha keerukamaks ( kahe kaamera tulekNäiteks kaamera HAL-i allikale juurdepääsu omamine muudab AOSP ROM-i portimise funktsionaalse kaameraga palju lihtsamaks.

Kuid originaalseadmete tootjad ei võimalda erinevatel põhjustel juurdepääsu kaamera HAL-i allikale. Esiteks, kui neil ei ole kõiki kaamera HAL-i omandiõigusi (nt kui nad hõlmavad teiste ettevõtete intellektuaalomandit), ei saa nad allikat levitada. Teiseks võib kaamera HAL-i allika vabastamine seada ohtu nende endi intellektuaalomandi. Lõpuks ei ole ettevõtetel juriidilist kohustust seda lähtekoodi esitada (erinevalt tuuma lähtekoodist, mis nad on GPL-i alusel välja andma), seega pole neil motivatsiooni seda vabastada. Nii et ilma juurdepääsuta kaamera HAL-i allikale, kuidas saavad arendajad kaamera AOSP ROMidel tööle panna? Vastus on BLOB, shim ja palju-palju silumist.

Seade BLOB (Binary Large OBject) sisaldab eelpakendatud binaarfaile, mis on tarkvara kompileeritud vorm. Sel juhul kompileerib kaamera HAL-i allika OEM ja tarnib see seadmetesse kahendfailidena. Kui arendajad räägivad BLOB-idest, viitavad nad neile reaalajas seadmetele tarnitavatele kahendfailidele, mida nad saavad ekstraheerida. Nüüd on teemal "kaamera BLOBid". kaua vaevanud OnePlus mitu kuud, kuid tõsiasi on see, et arendajatel on alati olnud juurdepääs kaamera BLOB-idele. The kaamera HAL lähtekood on kuldne pilet siinsetele arendajatele küll, aga see on nii mitte kunagi, mitte kunagi vabastada juriidilise ohu tõttu seaks see sellised ettevõtted nagu OnePlus.

Seega jäävad arendajatele, kes soovivad AOSP-d seadmesse tuua, ainult kaamera HAL-i BLOB-id, mille lähtekoodile neil pole juurdepääsu. Harva ja harva saab arendaja siduda oma AOSP ROM-koodi kaameraga HAL BLOB ja eeldada, et see töötab, nii et nende kahe vahelise lõhe ületamiseks loovad arendajad nn.shim.”

"Sihima" tähendab "(millegi) kiilumist või tühiku täitmist." See on tegelikult see, mida arendaja millal ja millal teeb shim kirjutamine – nad lisavad koodi, mis võimaldab BLOBil liidestuda AOSP lähtekoodiga, mida nad töötavad koos. Vaheplaate kasutatakse selleks, et AOSP-ga töötaks kõikvõimalikud BLOB-id, kuid tavaliselt nõuab kõige rohkem värvimist just kaamera BLOB. Nagu me varem mainisime, ei ole shimmimine vajalik mitte ainult Androidi uuemate versioonide seadmesse portimiseks (nt kõik need mitteametlikud Android Oreo ROM-id), kuid neid on vaja ka sama Androidi versiooni AOSP-i teisaldamisel sellele seade.

Soovitatav lugemine: Poest riiulile: põhjalik ülevaade sellest, miks MSM8974 seadmed on Nougatist välja jäetud

Näiteks OnePlus 2 sai selle viimane ametlik suur OS-i värskendus Android 6.0 Marshmallow kujul. Seadmel aga tegelikult on täielikult töötavad kohandatud AOSP-põhised ROM-id põhineb Android Nougatil ja seda tänu arendajate ja nende vaheseinte raskele tööle. Toome lahti mõned vaheseibide näited, kuid kõigepealt peame rääkima, kuidas seibid täpselt töötavad.


Kuidas shimming töötab?

Kuna arendajatel pole juurdepääsu kaamera HAL-i või OEM-ROM-i allikale (ja ainult eelkompileeritud kahendfailidele), ei saa nad teada, milliseid funktsioone kaamera HAL ootab. Seetõttu esineb sageli mittevastavus kaamera HAL-i otsitava funktsiooni nime ja funktsiooni tegeliku nime vahel AOSP-koodis, millega arendaja töötab.

Selle probleemi lahendamiseks loob arendaja lihtsalt uue funktsiooni, mis kasutab sama nime funktsioon, mida kaamera HAL BLOB ootab, kuid see uus funktsioon täidab lihtsalt seda, mida arendaja soovib selle juurde. See uus funktsioon, mis toimib vahendajana BLOBi ja AOSP vahel, on vahesein. See konkreetne stsenaarium, kus BLOB ei leia otsitavat funktsiooni, on üks levinumaid stsenaariume, mille puhul on vaja seibi.

Väga lihtne MS värviskeem, mis näitab, kus vaheseib on vaja.

Võib-olla on OnePlus 3T-ga seotud hüpoteetilise näitega asjad natuke mõttekamad. Loome näite, kasutades OxygenOS-i ja OnePlusi kaamerat. Kui kasutame AOSP-põhise Nougat ROM-i loomiseks OnePlus 3T jaoks OxygenOS Nougatist võetud kaamera BLOB-sid, võib meil tekkida probleeme. Seda seetõttu, et kaamera BLOB-id (mille algselt koostas OEM) saavad viidata kõigile OxygenOS-is vajalikele funktsioonidele, kuid kuna kompileeritud AOSP ROM-il ei pruugi neid funktsioone olla või see võib olla kompileeritud teise nime all (see toob kaasa funktsioonisümbolite mittevastavuse), tekib viga. Seda saab parandada, luues AOSP ROM-is uue funktsiooni nimega, mida BLOB ootab – meie shim.

Programmeerimiskontekstis olevaid sümboleid kasutatakse koodis konkreetsetele funktsioonidele viitamiseks. Sümbolid on vajalikud, kuna funktsiooni asukoht võib koodi redigeerimisel muutuda ja seega kõvakodeerimise vältimiseks funktsioonide viidete korral loob kompilaator sümbolite tabeli, mida teised funktsioonid saavad kasutada alati õigele viitamiseks funktsiooni. Kui muudate funktsiooni nime enne kompileerimist, muutub ka selle sümbol, seega põhimõtteliselt kõik muudatused mille OEM teeb enne kompileerimist kaamerale HAL-allika, peavad arendajad looma uue shim.

Sümbolitabeli vaatamine punkriga. Allikas: Aprioriit

Siiani pakutud selgituse põhjal tundub, et vaheseibide loomine on lihtne. Mõne funktsiooni nime muutmine siin-seal ei kõla liiga raskelt, eks? Kui see vaid nii lihtne oleks. Seibide tegelikkus hõlmab enamat kui lihtsalt funktsioonide ümbernimetamist. Rääkisime XDA tunnustatud arendaja Sultanxdaga, kes suutis meile tuua näite ühest keerulisemast seibist, mille kallal ta on töötanud.


Shimming – mitte nii lihtne, kui see kõlab

Neile, kes OnePlus 3T-ga ei tundnud, oli esikaamera alguses üsna katki. AOSP-põhised kohandatud ROM-id. Alustuseks võib katse teha mis tahes pilti eraldusvõimega üle 8 MP krahh. Püüdes seda probleemi lahendada, tegi Sultanxda mitu seibid et OnePlus 3T esikaamera korralikult töötaks.

Seib nr 1 – kaamerapaketi nime muutmine

Et vältida esikaamera kokkujooksmist, kui kasutaja pildistas üle 8 MP, sundis Sultanxda kaamerat HAL tuvastama kõik kaamerad OnePlusi kaamerana. Seda tehakse seetõttu, et OnePlus otsustas pühendada teatud rakendustele abifunktsiooni (isOnePlusCamera, isFacebookCamerajne) mingil põhjusel. Sultanxda parandas selle, muutes kaamera HAL-i, nii et see osutab uuele funktsioonile, mis tagastab alati "tõene", nagu kasutaja kasutaks OnePlusi kaamerat, isegi kui ta seda ei tee.

Seis nr 2 – keelake QuadraCfa

Järgmise aluse jaoks pidi ta keelama QuadraCfa, mis on arvatavasti kaameraga seotud patenteeritud Qualcommi tehnoloogia. Me ütleme arvatavasti seetõttu, et ei mina ega Sultanxda pole täpselt kindel, mis QuadraCfa on, kuid Sultanxda teab, et see lõhkus esikaamera alati, kui see sisse lülitati.

Ta täheldas, et QuadraCfa lubab end kuidagi, kuid ta ei olnud kindel, miks või kuidas see seda teeb. Selle lahendamine nõudis temalt üsna ebatavalist modifikatsiooni. Tavalises vahekihis annab vaheseibi funktsioon koostamisel puuduva sümboli, mida BLOB otsib. Sel juhul olid BLOBil juba vajalikud sümbolid – need, mis arvatavasti esindasid funktsioone, mis käivitasid QuadraCfa.

Õnnista Hexi toimetajat. Kasutatud programm Sultanxda.

Seega oli tal vaja kaamera HAL-i kasutatavad sümbolid alistada ja need sisuliselt "puuduvad" teha. tema vaheplaadid annaksid need "puuduvad" sümbolid. Ainus viis seda teha on kaudu hex monteerimine kaamera HAL ise. Kuueteistkümnendtöötlus on põhimõtteliselt binaarandmete kujul olevate organiseerimata jamade otsimine, et leida heinakuhjast nõel – kas funktsioon või string, mida soovite redigeerida.

Funktsiooni hex-redigeerimine on oluliselt keerulisem kui stringi kuueteistkümnend-redigeerimine, kuid õnneks suutis Sultanxda vältida QuadraCfa taga olevate funktsioonide hex-redigeerimist. hex redigeerimine sümbolite nimesid, et need sümbolid tühistada.

Seib nr 3 – Bright Light Crash Fix

Järgmisena tuvastas Sultanxda, et eredas valguses esikaameraga pildistamine põhjustab kaamera kokkuvarisemise. Selle vea taasesitamiseks oma seadmes teeb Sultanxda tegelikult lülitas sisse oma OnePlus One'i taskulambi funktsiooni ja pani valgust OnePlus 3T esikaamera ette et see kokku jookseks ja kasutatavaid palke tootma! Kui ta avastas, mis funktsioon krahhi põhjustas, lõi ta aluse, et sundida seadet esikaamera jaoks kogu aeg hämaras režiimi kasutama.

Seis nr 4 – madala eraldusvõimega esikaamera pildid

Pärast ereda valguse krahhi parandamist eelmise seibiga avastas Sultanxda veel ühe vea, mis tegelikult tekkis selle vaheseibi otsese tulemusena: madala eraldusvõimega esikaamera pildid. Selle asemel, et pildistada kasutaja soovitud eraldusvõimega (nt. 16 MP), saadud pilt tehakse 4 MP.

Selle lahendamine nõudis funktsioonide muutmist handleSuperResolution ja isSuperResolution et tagastada alati tõene, kuid AINULT siis, kui esikaamera on aktiivne (sest vastasel juhul jookseb kaamera tagumise sensori abil pildistades kokku).


Õppetund – närimine võib olla raske

Sultanxda tunnistab, et vaheplaadid, mille ta pidi OnePlus 3T esikaamera tööle panemiseks looma, ei kujuta endast tüüpilist vaheseibi näidet. Ta on oma vahetüki üle üsna uhke, arvestades selle keerukust ja haruldast vajadust BLOBi ennast kuus korda redigeerida. Kuid see näide lihtsalt näitab, kui keeruline võib olla kaamera riistvara teatud seadmetes tööle panna.

Olgu teie kaameraseiklused vähem valusad kui minu omad. -Sultanxda

Palgid, palgid ja muud palgid. Ilma järjepideva krahhi reprodutseerimise ja logideta pole arendajatel suurt lootust probleemi allikat leida. Isegi kui nad leiavad, mis probleemi põhjustab, ei ole see alati lihtne lahendus. Kogu nende vigade leidmise ja kõrvaldamise protsess võib kesta päevi või nädalaid ning see on põhjus, miks kaamera parandamine AOSP ROMidel on üks keerulisemaid ülesandeid.

Kui teie seadmesse on porditud AOSP ROM koos täielikult toimiva riistvaraga, saate loodetavasti alustada hindan võitlust, mille need arendajad võisid nende teieni toomise nimel läbi elada Funktsioonid. Hinda neid nende töö eest, sest see pole lihtne. See on palju tööd, mida enamik kasutajaid isegi ei märka, kuna andekad arendajad meie foorumites hoolitsevad Androidi paljude seninägematute osade eest.

Soovime Sultanxdat eriliselt tänada paljude panuste eest, mida ta selle artikli koostamisel soovitas.