Miten kehittäjät saavat laitteistokomponentit, kuten kamerat, toimimaan mukautetuissa ROM-levyissä ilman lähdekoodia? Vastaus on BLOB, välilevy ja paljon virheenkorjausta.
Android Oreon ja monien laitteiden, kuten Xiaomi Redmi Note 3, Google Nexus 5 ja muut saavat sen epävirallisesti, on luultavasti kohtuullista ihmetellä, miksi samat ominaisuudet (useimmiten kamera) hajoavat, kun kehittäjät ottavat käyttöön Android Open Source Project (AOSP) -pohjaisen ROM-levyn. Olet luultavasti nähnyt ROM-levyjen XDA-foorumin säikeitä, joissa on pitkä luettelo rikkinäisistä ominaisuuksista ylhäällä. "Mikä toimii" ja sen jälkeen luettelo toimivista ominaisuuksista, sitten alapuolella ikoninen "Mikä ei toimi? Kerro sinä minulle!" ovat kaksi suosittua pidättäytymistä foorumeillamme, joista on käytännössä tullut meemejä Redditissä ja Twitterissä.
Miksi niin monet toiminnot katkeavat aina, kun kehittäjä yrittää siirtää AOSP-ROM-muistin laitteelleen? Perusvastaus on, että koska toiminnot vaihtelevat Androidin eri versioissa, vanhat BLOB: iksi pakatut laiteohjaimet eivät toimi Androidin uudemmissa versioissa tai edes vain varastossa olevan AOSP: n kanssa. Tämän voittamiseksi kehittäjät käyttävät niin kutsuttua "välilevyä", mutta siihen liittyvä prosessi on hankala, aikaa vievä ja joskus erittäin vaikea korjata.
Tässä artikkelissa hahmotellaan, kuinka välilevyt toimivat, erityisesti mitä tulee kameran toimimiseen oikein AOSP-pohjaisilla ROM-levyillä. Käytämme OnePlus 3T: tä esimerkkinä. Huomaa, että näiden ominaisuuksien toimimiseen liittyvät vaikeudet ovat erittäin laitekohtaisia.
OnePlus 3T, jossa on OxygenOS. Vaikka OnePlus-puhelimet tunnetaan mukautetusta kehitysystävällisyydestään, kehittäjät tekevät paljon työtä kulissien takana luodakseen vakaat AOSP-portit.
Mikä on välilevy tai BLOB?
Jotta voisimme edes ymmärtää osaa siitä, mitä kehittäjät tekevät, meidän on ensin selitettävä muutamia asioita. Vaikka Android-käyttöjärjestelmä on avoimen lähdekoodin (se tunnetaan syystä Android Open Source Project -projektiksi), tuhansiin Android-laitteisiin toimitettu ohjelmisto (ilman ydintä) ei ole sitä. Kehittäjät eivät pääse käsiksi lähdekoodiin Samsung-kokemus, EMUI, OxygenOS, tai mikä tahansa muu kolmannen osapuolen Android-versio.
Nyt kehittäjät, jotka siirtävät AOSP-osakkeen muuhun kuin Google-laitteeseen, eivät todennäköisesti välitä näiden Android-skinien lähdekoodista, koska ne eivät aio olla muokkaamalla ja rakentamalla näitä ROM-levyjä. Se olisi totta, ellei yhdestä suuresta syystä: pääasiassa tarvittavista osista, jotta kamera toimii kunnolla the kamera HAL (Hardware Abstraction Layer), ovat myös suljettu lähde.
Kameran HAL: n lisäksi myös suljetun ROM-lähteen ongelmana on, että kehittäjät, jotka työskentelevät AOSP: n siirtämisessä laitteeseensa työskentelevä sokea. Suljetun lähdekoodin OEM-ROM voi liittää kameran HAL: iin hienosti, koska OEM: llä on pääsy kameran HAL-lähteeseen. Kameran HAL mahdollistaa ROM: n "puhumisen" kameralaitteiston kanssa – ilman sitä kamera ei toimi. Ajattele kameraa HAL auton ohjauspyöränä ja polkimena. Ohjauspyörä/polkimet mahdollistavat ajoneuvon sisäisten osien ohjaamisen tarjoamalla kuljettajalle ulkoisen liitännän (ROM) käyttääkseen sisäisiä osia.
Kun kameralaitteistosta tulee yhä monimutkaisempi ( kaksoiskameran tuloesimerkiksi), pääsy kameran HAL-lähteeseen tekisi AOSP-ROM-muistin siirtämisestä toimivan kameran kanssa paljon helpompaa.
OEM-valmistajat eivät kuitenkaan tarjoa pääsyä kameran HAL-lähteeseen useista syistä. Ensinnäkin, jos heillä ei ole kaikkia omistusoikeuksia kameran HAL: iin (esimerkiksi kun ne sisältävät muiden yritysten immateriaaliomaisuutta), he eivät voi levittää lähdettä. Toiseksi kameran HAL-lähteen vapauttaminen voi vaarantaa heidän oman immateriaaliomaisuutensa. Lopuksi, yrityksillä ei ole laillista velvoitetta toimittaa tätä lähdekoodia (toisin kuin ytimen lähdekoodi, jota ne ovat velvollinen julkaisemaan GPL: n mukaisesti), joten heillä ei ole kannustinta julkaista sitä. Joten ilman pääsyä kameran HAL-lähteeseen, kuinka kehittäjät saavat kameran toimimaan AOSP-ROM-levyillä? Vastaus on BLOB, välilevy ja paljon, paljon virheenkorjausta.
Laite MÖYKKY (Binary Large OBject) sisältää valmiiksi pakatut binaarit, jotka ovat ohjelmistojen käännetty muoto. Tässä tapauksessa OEM kääntää kameran HAL-lähteen ja toimittaa sen laitteisiin binäärinä. Kun kehittäjät puhuvat BLOBista, he viittaavat niihin binääriin, jotka toimitetaan live-laitteille ja jotka he voivat purkaa. Nyt aiheena "kameran BLOBs" on pitkään vaivannut OnePlus monta kuukautta, mutta totuus on, että kehittäjillä on aina ollut pääsy kameran BLOBiin. The kameran HAL-lähdekoodi on kultainen lippu kehittäjille täällä, mutta se tulee ei koskaan, koskaan vapauteta oikeudellisen vaaran vuoksi se laittaisi OnePlusin kaltaiset yritykset mukaan.
Näin ollen kehittäjille, jotka haluavat tuoda AOSP: n laitteelle, jää vain kameran HAL-BLOB-tiedostot, joiden lähdekoodiin heillä ei ole pääsyä. Harvoin jos koskaan kehittäjä voi yhdistää AOSP-ROM-koodinsa kameraan HAL BLOB ja odottaa sen toimivan, joten näiden kahden välisen kuilun kuromiseksi kehittäjät luovat niin sanotun "välilevy.”
"Tyhjentäminen" tarkoittaa "kiilaamista (jotain) tai täyttämistä". Tämä on käytännössä sitä, mitä kehittäjä tekee milloin välilevyn kirjoittaminen – ne lisäävät koodia, jotta BLOB voi liittyä heidän käyttämänsä AOSP-lähdekoodiin kanssa. Välilevyjä käytetään saamaan kaikenlaiset BLOBit toimimaan AOSP: n kanssa, mutta yleensä kameran BLOB vaatii eniten säätöä. Kuten aiemmin mainitsimme, välilevyjä ei vaadita vain uudempien Android-versioiden siirtämiseen laitteeseen (esim. kaikki nuo epäviralliset Android Oreo ROM -levyt), mutta niitä tarvitaan myös siirrettäessä saman Android-version AOSP: tä siihen laite.
Suositeltavaa luettavaa: Kaupasta hyllyyn: perusteellinen kuvaus siitä, miksi MSM8974-laitteet on jätetty Nougatin ulkopuolelle
Esimerkiksi OnePlus 2 sai sen viimeinen virallinen suuri käyttöjärjestelmän päivitys Android 6.0 Marshmallow: n muodossa. Laitteessa kuitenkin on täysin toimivat mukautetut AOSP-pohjaiset ROM-levyt perustuu Android Nougatiin, ja se johtuu kehittäjien ja heidän välilevyinsä kovasta työstä. Puramme joitain esimerkkejä välilevyistä, mutta ensin meidän on puhuttava siitä, kuinka välilevyt tarkalleen toimivat.
Miten shimming toimii?
Koska kehittäjillä ei ole pääsyä kameran HAL- tai OEM-ROM-lähteeseen (ja vain esikäännettyihin binääriin), he eivät voi tietää, mitä toimintoja kamera HAL odottaa. Tästä johtuen kameran HAL etsimän toiminnon nimen ja funktion todellisen nimen välillä on usein epäsuhta AOSP-koodissa, jota kehittäjä työskentelee.
Tämän ongelman ratkaisemiseksi kehittäjä luo yksinkertaisesti uuden toiminnon, joka käyttää samaa nimeä toiminto, jota kamera HAL BLOB odottaa, mutta tämä uusi toiminto vain suorittaa sen, mitä kehittäjä haluaa sen. Tämä uusi toiminto, joka toimii välittäjänä BLOB: n ja AOSP: n välillä, on välilevy. Tämä skenaario, jossa BLOB ei löydä etsimäänsä toimintoa, on yksi yleisimmistä, joissa välilevyä tarvitaan.
Ehkä asiat ovat hieman järkevämpiä hypoteettisella esimerkillä, joka koskee OnePlus 3T: tä. Luomme esimerkin käyttämällä OxygenOS: ää ja OnePlus-kameraa. Jos käytämme OxygenOS Nougatista otettuja kameran BLOB-tiedostoja OnePlus 3T: lle AOSP-pohjaisen Nougat ROMin rakentamiseen, saatamme kohdata ongelmia. Tämä johtuu siitä, että kameran BLOB-tiedostot (jotka alun perin on koonnut OEM) voivat viitata kaikkiin OxygenOS: n tarvitsemiin toimintoihin, mutta koska käännetyssä AOSP ROMissa ei ehkä ole näitä toimintoja tai se on saattanut kääntää ne eri nimellä (jolloin funktiosymbolien välillä on ristiriita), tulee virhe. Tämä voidaan korjata luomalla uusi toiminto AOSP-ROM-muistiin BLOBin odottamalla nimellä – meidän välilevymme.
Ohjelmointikontekstissa olevia symboleja käytetään viittaamaan tiettyihin toimintoihin koodissa. Symbolit ovat välttämättömiä, koska funktion sijainti voi muuttua koodia muokatessa ja näin välttääksesi kovakoodauksen funktioihin viitattaessa kääntäjä luo symbolitaulukon, jonka avulla muut funktiot voivat viitata aina oikeaan toiminto. Kun muutat funktion nimeä ennen kääntämistä, myös sen symboli muuttuu, eli periaatteessa kaikki muutokset jonka OEM tekee kameralle HAL-lähdettä ennen kääntämistä, kehittäjien on luotava uusi välilevy.
Tähän mennessä tarjoamamme selitys saa kuulostaa siltä, että välilevyjen luominen on helppoa. Muutaman funktion nimen muuttaminen siellä täällä ei kuulosta liian vaikealta, eikö? Kunpa se olisikin niin helppoa. Välilevyjen todellisuus sisältää enemmän kuin vain toimintojen uudelleennimeämisen. Keskustelimme XDA Recognized Developer Sultanxdan kanssa, joka pystyi tarjoamaan meille esimerkin yhdestä vaikeimmista välilevyistä, jonka parissa hän on työskennellyt.
Shimming - Ei niin helppoa kuin miltä se kuulostaa
Niille, jotka eivät tunne OnePlus 3T: tä, etukamera oli melko rikki alun perin AOSP-pohjaiset mukautetut ROM-levyt. Aluksi minkä tahansa yli 8 megapikselin kuvan ottaminen johtaisi siihen kaatuu. Yrittessään ratkaista tämän ongelman Sultanxda teki useita välilevyt jotta OnePlus 3T -etukamera toimii kunnolla.
Välilevy #1 - Kamerapaketin nimen muuttaminen
Sultanxda pakotti kameran HAL: n tunnistamaan kaikki kamerat OnePlus-kameraksi estääkseen etukameraa kaatumasta aina, kun käyttäjä otti kuvan yli 8 megapikseliä. Tämä tapahtuu, koska OnePlus päätti omistaa aputoiminnon tietyille sovelluksille (isOnePlusCamera, isFacebookCamerajne.) jostain syystä. Sultanxda korjasi tämän säätämällä kameran HAL-levyä siten, että se osoittaa uuteen toimintoon, joka palauttaa aina "true" ikään kuin käyttäjä käyttäisi OnePlus-kameraa, vaikka hän ei olisi.
Välilevy #2 - Poista QuadraCfa käytöstä
Seuraavaa välilevyä varten hänen täytyi poistaa käytöstä QuadraCfa, joka on oletettavasti patentoitu Qualcomm-tekniikka, joka liittyy kameraan. Sanomme oletettavasti, koska en minä tai Sultanxda ole täysin varma, mikä QuadraCfa on, mutta Sultanxda tietää, että se rikkoi etukameran aina, kun se otettiin käyttöön.
Hän havaitsi, että QuadraCfa jotenkin mahdollistaisi itsensä, mutta hän ei ollut varma miksi tai miten se teki niin. Tämän ratkaiseminen vaati häneltä melko epätavanomaista muutosta. Perinteisessä välilevyssä välilevytoiminto, kun se on käännetty, tarjoaa puuttuvan symbolin, jota BLOB etsii. Tässä tapauksessa BLOB: lla oli jo tarvittavat symbolit – ne, jotka oletettavasti edustivat QuadraCfan käynnistäviä toimintoja.
Siten hänen täytyi ohittaa kameran HAL käyttämät symbolit ja pohjimmiltaan tehdä niistä "puuttuva" hänen välilevyt tarjoaisivat ne "puuttuvat" symbolit. Ainoa tapa tehdä se on kautta hex editoi itse kameran HAL. Hex-editointi on pohjimmiltaan binääritietojen muodossa olevien järjestäytymättömien höpinöiden etsimistä löytääkseen neulan heinäsuovasta – joko funktion tai merkkijonon, jota haluat muokata.
Funktion heksadesimaatio on huomattavasti vaikeampaa kuin merkkijonon muokkaus, mutta onneksi Sultanxda pystyi välttämään QuadraCfan takana olevien funktioiden heksamuokkauksen sen sijaan hex-muokkaus symbolien nimien mitätöimiseksi.
Välilevy nro 3 - Kirkkaan valon törmäyskorjaus
Seuraavaksi Sultanxda havaitsi, että kuvan ottaminen etukamerasta kirkkaassa valaistuksessa aiheuttaisi kameran kaatumisen. Toistaakseen tämän vian omalla laitteellaan Sultanxda itse asiassa sytytti OnePlus Onen taskulampputoiminnon ja loisti valon OnePlus 3T: n etukameran edessä jotta se kaatuu ja tuottaa käyttökelpoisia tukia! Kun hän havaitsi, mikä toiminto aiheutti törmäyksen, hän loi välilevyn pakottaakseen laitteen käyttämään hämärätilaa koko ajan etukameraa varten.
Välilevy #4 - Matalaresoluutioiset etukamerakuvat
Korjattuaan kirkkaan valon törmäyksen edellisellä välilevyllä, Sultanxda havaitsi toisen virheen, joka itse asiassa syntyi välittömänä seurauksena: matalaresoluutioiset etukamerakuvat. Sen sijaan, että otat kuvia käyttäjän pyytämällä resoluutiolla (esim. 16 MP), tuloksena oleva kuva otettaisiin 4 MP: llä.
Tämän ratkaiseminen edellytti toimintojen säätöä handleSuperResolution ja isSuperResolution palauttaa aina tosi, mutta VAIN kun etukamera on aktiivinen (koska muuten kamera kaatuisi otettaessa kuvia takakennoilta).
Oppitunti - Shimming voi olla vaikeaa
Sultanxda myöntää, että välilevyt, jotka hänen piti luoda saadakseen OnePlus 3T -etukameran toimimaan, eivät edusta tyypillistä esimerkkiäsi. Hän on melko ylpeä välilevystään, kun otetaan huomioon sen monimutkaisuus ja harvinainen tarve hex editoida itse BLOBia. Mutta tämä esimerkki osoittaa vain, kuinka vaikeaa voi olla saada kameralaitteisto toimimaan tietyissä laitteissa.
Olkoot kameran välilevyseikkailut vähemmän tuskallisia kuin minun. -Sultanxda
Lokit, lokit ja lisää lokeja. Ilman johdonmukaista tapaa toistaa kaatuminen ja ilman lokeja kehittäjillä ei ole juurikaan toivoa löytää ongelman lähdettä. Vaikka he löytäisivätkin ongelman syyn, se ei aina ole suoraviivainen ratkaisu. Näiden virheiden löytäminen ja poistaminen voi kestää päiviä tai viikkoja, ja siksi kameran korjaaminen AOSP-ROM-levyille on yksi vaikeimmista tehtävistä.
Jos laitteellesi on siirretty AOSP-ROM täysin toimivalla laitteistolla, voit toivottavasti aloittaa arvosta sitä kamppailua, jonka nämä kehittäjät ovat saattaneet käydä läpi saadakseen ne sinulle ominaisuudet. Arvosta heitä heidän työstään, koska se ei ole helppoa. Se on paljon työtä, jota suurin osa käyttäjistä ei edes huomaa, koska lahjakkaat kehittäjät foorumeillamme huolehtivat Androidin monista näkymättömistä osista.
Haluamme kiittää erityisesti Sultanxdaa monista hänen ehdotuksistaan tämän artikkelin laatimisessa.