Kā izstrādātāji bez pirmkoda iegūst aparatūras komponentus, piemēram, kameras, kas darbojas pielāgotos ROM? Atbilde ir BLOB, starplikas un daudz atkļūdošanas.
Izlaižot Android Oreo un daudzas ierīces, piemēram, Xiaomi Redmi Note 3, Google Nexus 5 un citi to neoficiāli saņem, iespējams, ir godīgi brīnīties, kāpēc tās pašas funkcijas (galvenokārt kamera) mēdz sabojāt, kad izstrādātāji portē Android atvērtā pirmkoda projektu (AOSP) balstītu ROM. Jūs, iespējams, esat redzējis XDA foruma ROM pavedienus ar garu bojāto funkciju sarakstu augšpusē. “Kas darbojas”, kam seko darba funkciju saraksts, pēc tam zem tā ikoniskais “Kas nedarbojas? Tu pasaki man!" ir divi populāri atturēšanās gadījumi mūsu forumos, kas praktiski ir kļuvuši par mēmiem tādās vietās kā Reddit un Twitter.
Kāpēc tik daudz funkcionalitātes tiek sabojātas ikreiz, kad izstrādātājs mēģina savā ierīcē portēt AOSP ROM? Galvenā atbilde ir tāda, ka, tā kā dažādās Android versijās funkcijas mainās, vecie ierīču draiveri, kas iepakoti kā BLOB, nedarbosies ar jaunākām Android versijām vai pat tikai ar AOSP. Lai to pārvarētu, izstrādātāji izmanto tā saukto “shim”, taču iesaistītais process ir sarežģīts, laikietilpīgs un dažreiz ļoti grūti atkļūdojams.
Šajā rakstā mēs izklāstīsim, kā darbojas starplikas, jo īpaši attiecībā uz kameras pareizu darbību uz AOSP balstītajos ROM. Kā piemēru mēs izmantosim OnePlus 3T. Ņemiet vērā, ka grūtības, kas saistītas ar šo funkciju iedarbināšanu, ir ļoti atkarīgas no ierīces.
OnePlus 3T, kurā darbojas OxygenOS. Lai gan OnePlus tālruņi ir pazīstami ar savu pielāgoto izstrādes draudzīgumu, izstrādātāji aizkulisēs veic daudz darba, lai izveidotu stabilus AOSP portus.
Kas ir starplikas vai BLOB?
Lai pat sāktu saprast daļu no izstrādātāju darbības, mums vispirms ir jāpaskaidro dažas lietas. Lai gan Android operētājsistēma ir atvērtā koda (kā iemesla dēļ to sauc par Android Open Source Project), programmatūra (bez kodola), kas tiek piegādāta tūkstošiem Android ierīču, tā nav. Izstrādātājiem nav piekļuves avota kodam Samsung pieredze, EMUI, OxygenOS, vai jebkuru citu trešo pušu Android versiju.
Tagad izstrādātājiem, kas pārnēsā AOSP krājumus uz ierīci, kas nav Google, visticamāk, nerūp šo Android apvalku pirmkods, jo tie vairs nebūs modificējot un veidojot šos ROM. Tā būtu taisnība, ja ne viena liela, liela iemesla dēļ: galvenokārt daļas, kas nepieciešamas, lai kamera darbotos pareizi uz kamera HAL (Aparatūras abstrakcijas slānis), ir arī slēgts avots.
Ne tikai kameras HAL, bet arī ROM slēgtā avota problēma ir tāda, ka izstrādātāji, kas strādā pie AOSP pārnešanas savā ierīcē, būs strādā akls. Slēgtā avota OEM ROM var lieliski saskarties ar kameras HAL, jo OEM ir piekļuve kameras HAL avotam. Kamera HAL ļauj ROM “sarunāties” ar kameras aparatūru — bez tās kamera nedarbotos. Padomājiet par kameru HAL kā par automašīnas stūri un pedāļiem. Stūre/pedāļi ļauj kontrolēt transportlīdzekļa iekšējās sastāvdaļas, nodrošinot vadītājam ārēju interfeisu (ROM), lai varētu izmantot iekšējos komponentus.
Tā kā kameras aparatūra kļūst arvien sarežģītāka ( divu kameru parādīšanāsPiemēram), ja ir piekļuve kameras HAL avotam, AOSP ROM pārnešana ar funkcionālu kameru būtu daudz vienkāršāka.
Tomēr oriģinālo iekārtu ražotāji dažādu iemeslu dēļ nenodrošina piekļuvi kameras HAL avotam. Pirmkārt, ja viņiem nav visu īpašumtiesību uz kameru HAL (piemēram, ja tie ietver intelektuālo īpašumu no citiem uzņēmumiem), viņi nevar izplatīt avotu. Otrkārt, kameras HAL avota atbrīvošana var apdraudēt viņu pašu intelektuālo īpašumu. Visbeidzot, uzņēmumiem nav juridiska pienākuma nodrošināt šo pirmkodu (atšķirībā no kodola pirmkoda, kas tie ir ir pienākums atbrīvot saskaņā ar GPL), tāpēc viņiem nav motivācijas to atbrīvot. Tātad, ja nav piekļuves kameras HAL avotam, kā tieši izstrādātāji panāk, ka kamera darbojas ar AOSP ROM? Atbilde ir BLOB, starplikas un daudz, daudz atkļūdošanas.
Ierīce BLOB (Binary Large OBject) satur iepriekš iepakotus bināros failus, kas ir programmatūras kompilētā forma. Šajā gadījumā kameras HAL avotu apkopo OEM un nosūta ierīcēs kā bināros failus. Kad izstrādātāji runā par BLOB, viņi atsaucas uz tiem binārajiem failiem, kas tiek piegādāti dzīvajās ierīcēs un kurus viņi var iegūt. Tagad ir aktuāla tēma “kameru lāses”. ilgi nomocīts OnePlus daudzus mēnešus, taču patiesība ir tāda, ka izstrādātājiem vienmēr ir bijusi piekļuve kameru BLOB. The kameras HAL pirmkods ir zelta biļete izstrādātājiem šeit, lai gan, bet tas būs nekad, nekad netiktu atbrīvots juridiska apdraudējuma dēļ tas liktu iesaistīties tādiem uzņēmumiem kā OnePlus.
Tādējādi izstrādātājiem, kuri vēlas ievietot AOSP ierīcē, tiek atstāti tikai kameras HAL BLOB, kuru pirmkodam nav piekļuves. Reti, ja vispār, izstrādātājs var savienot pārī savu AOSP ROM kodu ar kameru HAL BLOB un sagaidīt, ka tas darbosies, tāpēc, lai pārvarētu plaisu starp abiem, izstrādātāji izveido tā saukto “shim.”
"Shim" nozīmē "ieķīlēt (kaut ko) vai aizpildīt vietu". Tas ir tas, ko izstrādātājs dara, kad rakstot starpliku — viņi pievieno kodu, lai BLOB varētu saskarties ar AOSP avota kodu, kuru viņi strādā ar. Starplikas tiek izmantotas, lai visu veidu BLOB darbotos ar AOSP, taču parasti tieši kameras BLOB ir nepieciešams vislielākais spīdums. Kā jau minējām iepriekš, shiming ir nepieciešama ne tikai jaunāku Android versiju pārnešanai ierīcē (piemēram, visus šos neoficiālos Android Oreo ROM), bet arī tie ir nepieciešami, pārnēsājot tās pašas Android versijas AOSP uz šo ierīci.
Ieteicamā literatūra: No veikala uz plauktu: padziļināta kapitulācija par to, kāpēc MSM8974 ierīces ir izslēgtas no Nugas
Piemēram, OnePlus 2 to saņēma pēdējais oficiālais lielais OS atjauninājums Android 6.0 Marshmallow formātā. Tomēr ierīcei patiesībā ir pilnībā funkcionējoši pielāgoti uz AOSP balstīti ROM pamatā ir Android Nougat, un tas ir pateicoties izstrādātāju smagajam darbam un viņu starplikām. Mēs noskaidrosim dažus starplikas piemērus, taču vispirms mums ir jārunā par to, kā tieši starplikas darbojas.
Kā darbojas shimming?
Tā kā izstrādātājiem nav piekļuves kameras HAL vai OEM ROM avotam (un tikai iepriekš kompilētajiem binārajiem failiem), viņi nevar zināt, kādas funkcijas sagaida kamera HAL. Šī iemesla dēļ kameras HAL meklētās funkcijas nosaukums bieži neatbilst funkcijas faktiskajam nosaukumam AOSP kodā, ar kuru izstrādātājs strādā.
Lai atrisinātu šo problēmu, izstrādātājs vienkārši izveido jaunu funkciju, kas izmanto tādu pašu nosaukumu funkcija, ko kamera sagaida HAL BLOB, taču šī jaunā funkcija tikai izpilda to, ko vēlas izstrādātājs to uz. Šī jaunā funkcija, kas darbojas kā starpnieks starp BLOB un AOSP, ir starplikas. Šis konkrētais scenārijs, kurā BLOB nevar atrast meklēto funkciju, ir viens no visizplatītākajiem scenārijiem, kur nepieciešams starplikas.
Varbūt lietas kļūs nedaudz jēgākas, izmantojot hipotētisku piemēru, kas saistīts ar OnePlus 3T. Mēs izveidosim piemēru, izmantojot OxygenOS un OnePlus kameru. Ja izmantosim kameras BLOB, kas ņemtas no OxygenOS Nougat priekš OnePlus 3T, lai izveidotu AOSP balstītu Nougat ROM, var rasties problēmas. Tas ir tāpēc, ka kameras BLOB (kurus sākotnēji apkopoja OEM) varēs atsaukties uz visām tai nepieciešamajām funkcijām OxygenOS, taču, tā kā kompilētajā AOSP ROM var nebūt šo funkciju vai tās var būt kompilētas ar citu nosaukumu (tādējādi izraisot funkciju simbolu neatbilstību), būs kļūda. To var novērst, izveidojot jaunu funkciju AOSP ROM ar nosaukumu, ko sagaida BLOB — mūsu shim.
Simboli programmēšanas kontekstā tiek izmantoti, lai norādītu uz konkrētām funkcijām kodā. Simboli ir nepieciešami, jo funkcijas pozīcija var mainīties, kad kods tiek rediģēts, un tāpēc, lai izvairītos no cietā kodēšanas atsauces uz funkcijām, kompilators izveido simbolu tabulu, ko citas funkcijas var izmantot, lai vienmēr atsauktos uz labo funkciju. Mainot funkcijas nosaukumu pirms kompilēšanas, mainās arī tās simbols, tātad būtībā visas izmaiņas ko OEM izgatavo kamerai HAL pirms kompilācijas, izstrādātājiem būs jāizveido jauns shim.
Līdz šim piedāvātais skaidrojums liek domāt, ka starplikas ir viegli izveidot. Dažu funkciju nosaukumu maiņa šeit un tur neizklausās pārāk grūti, vai ne? Ja tikai tas būtu tik vienkārši. Starplikas realitāte ietver vairāk nekā tikai funkciju pārdēvēšanu. Mēs runājām ar XDA atzīto izstrādātāju Sultanxda, kurš varēja mums sniegt piemēru vienai no grūtākajām starplikām, pie kuras viņš ir strādājis.
Shimming — nav tik vienkārši, kā izklausās
Tiem, kas nav pazīstami ar OnePlus 3T, priekšējā kamera sākotnēji bija salūzusi. Uz AOSP balstīti pielāgoti ROM. Pirmkārt, mēģinājums uzņemt attēlus, kas pārsniedz 8 MP, izraisītu avārijā. Mēģinot atrisināt šo problēmu, Sultanxda veica vairākus starplikas lai OnePlus 3T priekšējā kamera darbotos pareizi.
1. starplikas — kameras pakotnes nosaukuma maiņa
Lai novērstu priekšējās kameras avāriju, kad lietotājs uzņem attēlu, kas pārsniedz 8 MP, Sultanxda piespieda kameru HAL identificēt visas kameras kā OnePlus kameru. Tas tiek darīts, jo OnePlus nolēma atsevišķām lietojumprogrammām veltīt palīgfunkciju (isOnePlusCamera, isFacebookCamerau.c.) kāda iemesla dēļ. Sultanxda to novērsa, aizbīdot kameru HAL, lai tā norādītu uz jaunu funkciju, kas vienmēr atgriež “true” tā, it kā lietotājs izmantotu OnePlus kameru, pat ja viņš to neizmanto.
2. starplikas — atspējot QuadraCfa
Nākamajai starplikai viņam bija jāatspējo QuadraCfa, kas, iespējams, ir patentēta Qualcomm tehnoloģija, kas saistīta ar kameru. Mēs sakām, iespējams, tāpēc, ka ne es, ne Sultanxda nav īsti pārliecināts, kas ir QuadraCfa, taču Sultanxda zina, ka tā salauza priekšējo kameru, kad tā tika iespējota.
Viņš novēroja, ka QuadraCfa kaut kādā veidā aktivizēsies, taču viņš nebija pārliecināts, kāpēc un kā tas to dara. Lai to atrisinātu, no viņa puses bija nepieciešamas diezgan netradicionālas izmaiņas. Parastajā starplikā starplikas funkcija, kad tā ir apkopota, nodrošina trūkstošo simbolu, ko BLOB meklē. Šajā gadījumā BLOB jau bija nepieciešamie simboli — tie, kas, iespējams, apzīmēja funkcijas, kuras uzsāka QuadraCfa.
Tādējādi viņam vajadzēja ignorēt kameras HAL izmantotos simbolus un būtībā padarīt tos “trūkstošus”, lai viņa starplikas nodrošinātu tos "trūkstošos" simbolus. Vienīgais veids, kā to izdarīt, ir caur hex rediģēt pašu kameru HAL. Hex rediģēšana būtībā ir neorganizētu ķibeļu meklēšana bināro datu veidā, lai siena kaudzē atrastu adatu — vai nu funkciju, vai virkni, kuru vēlaties rediģēt.
Funkcijas hex rediģēšana ir daudz sarežģītāka nekā virknes heksadecimālā rediģēšana, taču, par laimi, Sultanxda varēja izvairīties no heksadecimālas rediģēšanas aiz QuadraCfa esošās funkcijas. hex rediģējot simbolu nosaukumus, lai šos simbolus anulētu.
3. plāksne — spilgtas gaismas avārijas labojums
Pēc tam Sultanxda konstatēja, ka, uzņemot attēlu no priekšpuses kameras spilgtā apgaismojumā, kamera varētu avarēt. Lai reproducētu šo kļūdu savā ierīcē, Sultanxda faktiski ieslēdza sava OnePlus One zibspuldzes funkciju un apgaismoja OnePlus 3T priekšējās kameras priekšā. lai tas avarētu un ražotu izmantojamus baļķus! Kad viņš atklāja, kura funkcija izraisīja avāriju, viņš izveidoja starpliku, lai piespiestu ierīci visu laiku izmantot vāja apgaismojuma režīmu priekšējai kamerai.
4. starplikas — zemas izšķirtspējas priekšpuses kameras attēli
Pēc spilgtās gaismas avārijas novēršanas ar iepriekšējo starpliku Sultanxda atklāja vēl vienu kļūdu, kas faktiski radās tieši šīs starplikas dēļ: zemas izšķirtspējas priekšējās kameras attēli. Tā vietā, lai fotografētu ar lietotāja pieprasīto izšķirtspēju (piem., 16MP), iegūtais attēls tiktu uzņemts ar 4MP.
Lai to atrisinātu, viņam bija jāfinansē funkcijas handleSuperResolution un isSuperResolution lai vienmēr atgrieztos patiesā, bet TIKAI tad, ja ir aktīva priekšējā kamera (jo pretējā gadījumā kamera avarēs, uzņemot attēlus no aizmugures sensora).
Gūta mācība — slīdēšana var būt sarežģīta
Sultanxda atzīst, ka starplikas, kas viņam bija jāizveido, lai OnePlus 3T priekšējā kamera darbotos, nav tipisks starplikas piemērs. Viņš diezgan lepojas ar savu starpliku, ņemot vērā tā sarežģītību un reto vajadzību hex rediģēt pašu BLOB. Bet šis piemērs tikai parāda, cik grūti var būt kameras aparatūras darbība noteiktās ierīcēs.
Lai jūsu piedzīvojumi ar kameru ir mazāk sāpīgi nekā manējie. -Sultanksda
Baļķi, baļķi un citi baļķi. Bez konsekventa veida avārijas atkārtošanai un bez žurnāliem izstrādātājiem ir maz cerību atrast problēmas avotu. Pat ja viņi atrod problēmas cēloni, tas ne vienmēr ir vienkāršs risinājums. Viss šo kļūdu atrašanas un novēršanas process var ilgt vairākas dienas vai nedēļas, un tas ir iemesls, kāpēc kameras labošana AOSP ROM ir viens no grūtākajiem uzdevumiem.
Ja jūsu ierīcei ir portēts AOSP ROM ar pilnībā funkcionējošu aparatūru, cerams, ka varat sākt novērtējam šo izstrādātāju cīņu, lai tos jums piedāvātu Iespējas. Novērtējiet viņus par viņu darbu, jo tas nav viegli. Tas ir liels darbs, ko lielākā daļa lietotāju pat nepamanīs, jo talantīgi izstrādātāji mūsu forumos rūpējas par daudzajām vēl neredzētajām Android daļām.
Mēs vēlamies īpaši pateikties Sultanxda par daudzajiem ieguldījumiem, ko viņš ieteica šī raksta tapšanā.