Forráskód nélkül hogyan tudják a fejlesztők az egyedi ROM-okban működő hardverkomponenseket, például kamerákat? A válasz egy BLOB, alátét és sok hibakeresés.
Az Android Oreo és számos eszköz, például a Xiaomi Redmi Note 3, Google Nexus 5 és mások nem hivatalosan kapják meg, valószínűleg jogos elgondolkodni azon, hogy ugyanazok a funkciók (főleg a kamera) miért törnek meg, amikor a fejlesztők egy Android Open Source Project (AOSP) alapú ROM-ot portolnak. Valószínűleg láttad a ROM-ok XDA-fórumának szálait, amelyek tetején a meghibásodott funkciók hosszú listája található. „Mi működik”, majd a működő funkciók listája, majd lent az ikonikus „Mi nem működik? Mondd meg Te!" két népszerű refrén a fórumainkon, amelyek gyakorlatilag mémekké váltak olyan helyeken, mint a Reddit és a Twitter.
Miért tönkremegy annyi funkció, amikor a fejlesztő AOSP ROM-ot próbál portolni az eszközére? Az alapvető válasz az, hogy mivel a funkciók az Android különböző verzióiban változnak, a BLOB-ként csomagolt régi eszközillesztők nem működnek az Android újabb verzióival, vagy akár csak a készlet AOSP-vel. Ennek leküzdésére a fejlesztők az úgynevezett „kiegyenlítőt” használják, de a folyamat bonyolult, időigényes, és néha nagyon nehéz a hibakeresés.
Ebben a cikkben felvázoljuk az alátétek működését, különös tekintettel a kamera megfelelő működésére az AOSP-alapú ROM-okon. Példaként a OnePlus 3T-t fogjuk használni. Vegye figyelembe, hogy ezeknek a funkcióknak a működésének nehézségei erősen eszközspecifikusak.
OnePlus 3T, amelyen az OxygenOS fut. Bár a OnePlus telefonok egyéni fejlesztésbarát tulajdonságaikról ismertek, a fejlesztők rengeteg munkát végeznek a színfalak mögött, hogy stabil AOSP portokat hozzanak létre.
Mi az az alátét vagy a BLOB?
Ahhoz, hogy a fejlesztők tevékenységének egy részét is megértsük, először el kell magyaráznunk néhány dolgot. Bár az Android operációs rendszer nyílt forráskódú (amit valamiért Android Open Source Projectnek hívnak), a több ezer Android-eszközön szállított szoftver (kernel nélkül) nem az. A fejlesztők nem férnek hozzá a forráskódhoz Samsung élmény, EMUI, OxygenOS, vagy az Android bármely más, harmadik féltől származó változata.
A fejlesztők, akik az AOSP-t egy nem Google-eszközre hordozzák, valószínűleg nem törődnek ezen Android skinek forráskódjával, mivel nem is fognak módosítani és felépíteni ezeket a ROM-okat. Ez igaz lenne, ha nem egy nagy-nagy okból: elsősorban a kamera megfelelő működéséhez szükséges alkatrészek miatt a kamera HAL (Hardveres absztrakciós réteg), vannak zárt forrásból is.
A probléma azzal, hogy nem csak a kamera HAL-ja, hanem a ROM zárt forráskódja is az, hogy a fejlesztők, akik az AOSP-nek az eszközükre történő portolásán dolgoznak, dolgozó vak. A zárt forráskódú OEM ROM remekül tud csatlakozni a kamera HAL-jához, mivel az OEM hozzáfér a kamera HAL forrásához. A kamera HAL lehetővé teszi, hogy a ROM „beszéljen” a kamera hardverével – enélkül a kamera nem működne. Gondoljon a HAL kamerára úgy, mint az autó kormányára és pedáljaira. A kormánykerék/pedálok lehetővé teszik a jármű belső alkatrészeinek vezérlését azáltal, hogy külső interfészt (ROM) biztosítanak a vezető számára a belső alkatrészek használatához.
Ahogy a fényképezőgép hardvere egyre összetettebbé válik (a a kettős kamera megjelenésepéldául), a kamera HAL-forrásához való hozzáférés sokkal könnyebbé tenné az AOSP ROM áthelyezését működőképes kamerával.
Az eredeti gyártók azonban különböző okok miatt nem biztosítanak hozzáférést a kamera HAL-forrásához. Először is, ha nem rendelkeznek a kamera HAL összes tulajdonjogával (például amikor más cégektől származó szellemi tulajdont építenek be), akkor nem terjeszthetik a forrást. Másodszor, a kamera HAL forrásának kiadása veszélyeztetheti saját szellemi tulajdonukat. Végül, a vállalatokat nem terheli jogi kötelezettség a forráskód megadására (ellentétben a kernel forráskódjával, amely ők köteles kiadni a GPL értelmében), így nem motiválják őket kiadni. Tehát a kamera HAL-forrásához való hozzáférés nélkül pontosan hogyan tudják a fejlesztők működésre bírni a kamerát AOSP ROM-okon? A válasz egy BLOB, alátét és sok-sok hibakeresés.
Eszköz FOLT (Binary Large OBject) előre csomagolt binárisokat tartalmaz, amelyek a szoftverek lefordított formája. Ebben az esetben a kamera HAL-forrását az OEM állítja össze, és bináris fájlként szállítja az eszközökre. Amikor a fejlesztők a BLOB-okról beszélnek, akkor azokra a binárisokra hivatkoznak, amelyeket élő eszközökön szállítanak, és amelyeket képesek kivonni. Most megvan a „kamera BLOB” témája régóta gyötörte a OnePlus-t sok hónapig, de az igazság az, hogy a fejlesztők mindig is hozzáfértek a kamera BLOB-okhoz. A kamera HAL forráskódja az arany jegy az itteni fejlesztőknek ugyan, de ez lesz soha, de soha nem szabadul a jogi veszély miatt olyan cégeket helyezne be, mint a OnePlus.
Így az AOSP-t eszközre hozni kívánó fejlesztőknek csak a kamera HAL BLOB-jai maradnak, amelyek forráskódjához nem férnek hozzá. A fejlesztők ritkán és egyáltalán nem tudják párosítani az AOSP ROM kódját a HAL BLOB kamerával, és elvárni, hogy működjön, ezért a kettő közötti szakadék áthidalása érdekében a fejlesztők létrehoznak egy úgynevezett "alátétlemez.”
A "kiegyenlítés" annyit jelent, mint "kiékelni (valamit) vagy kitölteni egy helyet". Valójában ezt teszi a fejlesztő, mikor alátét írása – kódot adnak hozzá, hogy lehetővé tegyék a BLOB számára az interfészeket az általuk használt AOSP forráskóddal val vel. Az alátéteket arra használják, hogy mindenféle BLOB-ot működjenek az AOSP-vel, de általában ez a kamera BLOB, amely a legtöbb illesztést igényli. Amint azt korábban említettük, az alátétezés nem csak az Android újabb verzióinak eszközre történő hordozásához szükséges (pl. mindazokat a nem hivatalos Android Oreo ROM-okat), de akkor is szükség van rá, ha ugyanazon Android verzió AOSP-jét portolják rá eszköz.
Ajánlott irodalom: Az üzlettől a polcig: mélyreható magyarázat arról, hogy miért zárják ki az MSM8974-es eszközöket a Nugátból
A OnePlus 2 például megkapta utolsó hivatalos jelentős operációs rendszer frissítés Android 6.0 Marshmallow formájában. A készülék azonban valójában rendelkezik teljesen működő egyedi AOSP-alapú ROM-ok Android Nougat alapú, és ez a fejlesztők és alátétjeik kemény munkájának köszönhető. Le fogunk bontani néhány példát az alátétekre, de először beszélnünk kell arról, hogyan működnek pontosan az alátétek.
Hogyan működik a simítás?
Mivel a fejlesztők nem férnek hozzá a kamera HAL vagy OEM ROM forrásához (és csak az előre lefordított binárisokhoz), nem tudhatják, milyen funkciókat vár el a kamera HAL. Emiatt gyakran nem egyezik a kamera HAL által keresett funkció neve és a fejlesztő által használt AOSP-kódban szereplő funkció tényleges neve.
A probléma megoldása érdekében a fejlesztő egyszerűen létrehoz egy új függvényt, amely ugyanazt a nevet használja funkció, amit a kamera HAL BLOB elvár, de ez az új funkció csak azt hajtja végre, amit a fejlesztő akar azt. Ez az új funkció, amely közvetítőként működik a BLOB és az AOSP között, az alátét. Ez a konkrét forgatókönyv, amelyben a BLOB nem találja meg a keresett funkciót, az egyik leggyakoribb olyan eset, amikor alátétre van szükség.
Talán a dolgok egy kicsit értelmesebbek lesznek egy hipotetikus példával, amely magában foglalja a OnePlus 3T-t. Létrehozunk egy példát az OxygenOS és a OnePlus kamera használatával. Ha az OxygenOS Nougatból vett kamera BLOB-okat használunk a OnePlus 3T-hez AOSP alapú Nougat ROM készítéséhez, problémákba ütközhetünk. Ennek az az oka, hogy a kamera BLOB-ok (amelyeket eredetileg az OEM állított össze) képesek lesznek hivatkozni az összes szükséges funkcióra az OxygenOS-en belül, de mivel a Előfordulhat, hogy a lefordított AOSP ROM nem rendelkezik ezekkel a funkciókkal, vagy más néven fordította le őket (ez a funkciószimbólumok közötti eltéréshez vezet), hiba. Ez megoldható, ha az AOSP ROM-on belül létrehozunk egy új függvényt a BLOB által elvárt névvel – a mi alátétünkkel.
A programozási kontextusban a szimbólumok a kódban meghatározott funkciókra utalnak. A szimbólumokra azért van szükség, mert a kód szerkesztése során a függvény pozíciója változhat, és így elkerülhető a kemény kódolás függvényekre való hivatkozások esetén a fordító létrehoz egy szimbólumtáblázatot, amelyet más függvények használhatnak, hogy mindig a jobbra hivatkozzanak. funkció. Ha fordítás előtt megváltoztatod egy függvény nevét, akkor a szimbóluma is megváltozik, tehát gyakorlatilag bármilyen változás amelyet az OEM készít a kamerához a HAL forráshoz a fordítás előtt, a fejlesztőknek újat kell létrehozniuk alátétlemez.
Az általunk eddig felkínált magyarázat alapján úgy tűnik, hogy az alátéteket könnyű létrehozni. Néhány funkciónév megváltoztatása itt-ott nem hangzik túl nehéznek, igaz? Ha ez ilyen egyszerű lenne. Az alátétek valósága nem csupán a funkciók átnevezését foglalja magában. Beszélgettünk az XDA elismert fejlesztőjével, Sultanxdával, aki példát tudott mutatni az egyik nehezebb alátétre, amelyen dolgozott.
Shimming – Nem olyan egyszerű, mint amilyennek hangzik
Azok számára, akik nem ismerik a OnePlus 3T-t, az előlapi kamera kezdetben meglehetősen elromlott. AOSP-alapú egyedi ROM-ok. Először is, ha bármilyen 8 MP-nél nagyobb képet próbálnak készíteni, az azt eredményezné összeomlik. A probléma megoldására tett kísérlete során Sultanxda számos dolgot tett alátéteket hogy a OnePlus 3T előlapi kamera megfelelően működjön.
1. alátét – A kameracsomag nevének megváltoztatása
Annak érdekében, hogy megakadályozza az előlapi kamera összeomlását, amikor a felhasználó 8 MP-nél nagyobb képet készített, a Sultanxda arra kényszerítette a HAL kamerát, hogy az összes kamerát OnePlus kameraként azonosítsa. Ez azért van így, mert a OnePlus úgy döntött, hogy segítő funkciót szentel bizonyos alkalmazásoknak (isOnePlusCamera, isFacebookCamerastb.) valamilyen okból. A Sultanxda ezt a kamera HAL alátétlemezével javította, így az egy új funkcióra mutat, amely mindig „igaz” értéket ad vissza, mintha a felhasználó a OnePlus kamerát használná – még akkor is, ha nem.
2. alátét – QuadraCfa letiltása
A következő alátéthez le kellett tiltania a QuadraCfát, amely feltehetően egy szabadalmaztatott Qualcomm technológia, amely a kamerához kapcsolódik. Valószínűleg azért mondjuk, mert sem jómagam, sem a Sultanxda nem vagyunk teljesen biztosak abban, hogy mi is az a QuadraCfa, de a Sultanxda tudja, hogy minden alkalommal, amikor engedélyezték, eltörte az előlapi kamerát.
Megfigyelte, hogy a QuadraCfa valahogy képessé teszi magát, de nem tudta, miért és hogyan teszi ezt. Ennek megoldása meglehetősen szokatlan módosítást igényelt a részéről. Hagyományos alátétnél az alátét funkció, amikor lefordítják, a hiányzó szimbólumot adja, amelyet a BLOB keres. Ebben az esetben a BLOB már rendelkezett a szükséges szimbólumokkal – azokkal, amelyek feltehetően a QuadraCfát elindító funkciókat képviselték.
Ezért felül kellett írnia a HAL kamera által használt szimbólumokat, és lényegében „hiányzóvá” kellett tennie azokat, így övé Az alátétek biztosítanák a „hiányzó” szimbólumokat. Ennek egyetlen módja a keresztül maga a kamera HAL hex szerkesztése. A hexadecimális szerkesztés alapvetően egy csomó rendezetlen halandzsát keres bináris adatok formájában, hogy egy tűt találjon a szénakazalban – akár egy függvényt, akár egy karakterláncot, amelyet szerkeszteni szeretne.
Egy függvény hexadecimális szerkesztése lényegesen nehezebb, mint egy karakterlánc hexadecimális szerkesztése, de szerencsére a Sultanxda elkerülte a QuadraCfa mögötti függvények hexadecimális szerkesztését. hexadecimálisan szerkeszti a szimbólumneveket, hogy érvénytelenítse ezeket a szimbólumokat.
3. alátét – Bright Light Crash Fix
A következő lépésben a Sultanxda megállapította, hogy ha erős fényviszonyok mellett készít képet az előlapi kameráról, akkor a kamera összeomlik. Annak érdekében, hogy ezt a hibát saját eszközén reprodukálja, a Sultanxda valójában bekapcsolta a OnePlus One zseblámpa funkcióját, és megvilágította a OnePlus 3T előlapi kamerája előtt annak érdekében, hogy összeomoljon és használható rönköket állítson elő! Miután felfedezte, hogy melyik funkció okozta az összeomlást, létrehozott egy alátétet, amely arra kényszerítette az eszközt, hogy az előlapi kamerához mindig gyenge fényviszonyokat használjon.
4. alátét – Alacsony felbontású előlapi kameraképek
Miután kijavította az erős fény összeomlását az előző alátéttel, a Sultanxda egy másik hibát fedezett fel, amely valójában ennek az alátétnek az eredményeként keletkezett: az alacsony felbontású előlapi kameraképeket. Ahelyett, hogy a felhasználó által kért felbontásban készítené a képeket (pl. 16 MP), a kapott kép 4 MP-ben készülne.
Ennek megoldása megkövetelte, hogy a funkciókat alátegye handleSuperResolution és isSuperResolution hogy mindig igaz legyen, de CSAK akkor, ha az elülső kamera aktív (mert különben a kamera összeomlana, amikor a hátsó érzékelőről készít képeket).
Megtanult lecke – A csillogás nehéz lehet
Sultanxda elismeri, hogy az alátétlemezek, amelyeket a OnePlus 3T előlapi kamera működéséhez kellett készítenie, nem az Ön tipikus példája az alátétnek. Eléggé büszke az alátétre, tekintettel annak összetettségére és arra a ritka szükségszerűségre, hogy magát a BLOB-ot hexal szerkeszteni kell. Ez a példa azonban csak azt mutatja be, milyen nehéz lehet a kamera hardverét bizonyos eszközökön működőképessé tenni.
Legyenek kevésbé fájdalmasak a fényképezőgép alátétkalandjai, mint az enyémek. -Sultanxda
Naplók, naplók és további naplók. Az összeomlás következetes reprodukálási módja és naplók nélkül a fejlesztőknek nem sok reményük van megtalálni a probléma forrását. Még ha megtalálják is a probléma okát, ez nem mindig egyszerű megoldás. A hibák felkutatásának és kiküszöbölésének teljes folyamata napokig vagy hetekig tarthat, és ez az oka annak, hogy a kamera javítása AOSP ROM-okon az egyik legnehezebb feladat.
Ha az eszközön egy AOSP ROM van portolva, teljesen működő hardverrel, remélhetőleg elkezdheti értékeljük azt a küzdelmet, amelyen ezek a fejlesztők keresztülmentek, hogy elhozhassák azokat jellemzők. Értékeld őket a munkájukért, mert nem könnyű. Rengeteg munka, amit a felhasználók túlnyomó többsége észre sem vesz, hiszen fórumainkon tehetséges fejlesztők gondoskodnak az Android sok még nem látott részéről.
Külön köszönetet szeretnénk mondani Sultanxdának azért a sok hozzájárulásért, amelyet e cikk elkészítéséhez javasolt.