Bez izvornog koda, kako programeri dobivaju hardverske komponente kao što su kamere koje rade u prilagođenim ROM-ovima? Odgovor je BLOB, shim i puno otklanjanja pogrešaka.
Izlaskom Androida Oreo i mnogih uređaja poput Xiaomi Redmi Note 3, Google Nexus 5 i drugi ga neslužbeno primaju, vjerojatno je pošteno zapitati se zašto iste značajke (uglavnom kamera) imaju tendenciju da budu pokvarene kada programeri prenose ROM temeljen na Android Open Source Project (AOSP). Vjerojatno ste vidjeli teme ROM-ova na XDA forumu s dugim popisom pokvarenih značajki na vrhu. "Što radi" nakon čega slijedi popis značajki koje rade, a zatim dolje ispod toga ikonično "Što ne radi? Reci ti meni!" dva su popularna refrena na našim forumima koji su praktički postali meme na mjestima kao što su Reddit i Twitter.
Zašto se toliko funkcionalnosti pokvari kad god programer pokuša prenijeti AOSP ROM na svoj uređaj? Osnovni odgovor je da, budući da se funkcije mijenjaju u različitim verzijama Androida, stari upravljački programi uređaja upakirani kao BLOB-ovi neće raditi s novijim verzijama Androida, pa čak ni samo sa standardnim AOSP-om. Kako bi to prevladali, programeri koriste ono što se zove "shim", ali proces koji je uključen je lukav, vremenski intenzivan i ponekad ga je vrlo teško ispraviti.
U ovom ćemo članku opisati kako rade podloške, posebno u pogledu ispravnog rada kamere na ROM-ovima koji se temelje na AOSP-u. Koristit ćemo OnePlus 3T kao primjer. Imajte na umu da su poteškoće uključene u pokretanje ovih značajki uvelike specifične za uređaj.
OnePlus 3T pokreće OxygenOS. Iako su OnePlus telefoni poznati po prilagođenom razvoju, razvojni programeri rade mnogo iza kulisa kako bi napravili stabilne portove AOSP-a.
Što je shim ili BLOB?
Da bismo uopće počeli razumjeti dio onoga što programeri rade, prvo moramo objasniti nekoliko stvari. Iako je Android OS otvorenog koda (s razlogom se zove Android Open Source Project), softver (bez kernela) isporučen na tisuće Android uređaja nije. Programeri nemaju pristup izvornom kodu Samsung iskustvo, EMUI, OxygenOS, ili bilo koju drugu verziju Androida treće strane.
Sada, razvojni programeri koji prenose standardni AOSP na uređaj koji nije Google vjerojatno ne mare za izvorni kod ovih Android skinova jer oni neće biti modificiranje i izgradnja ovih ROM-ova. To bi bilo točno, da nije iz jednog velikog, velikog razloga: uglavnom zbog dijelova koji su potrebni da bi kamera ispravno radila the kamera HAL (Hardware Abstraction Layer), su također zatvoreni izvor.
Problem s zatvorenim kodom ne samo HAL-a kamere nego i ROM-a je u tome što će programeri koji rade na prijenosu AOSP-a na svoje uređaje biti rad na slijepo. OEM ROM zatvorenog koda može se dobro povezati s HAL-om kamere jer OEM ima pristup HAL izvoru kamere. HAL kamere je ono što omogućuje ROM-u da "razgovara" s hardverom kamere—bez njega kamera ne bi radila. Zamislite kameru HAL kao upravljač i pedale automobila. Upravljač/pedale omogućuju kontrolu nad unutarnjim komponentama vozila osiguravajući vanjsko sučelje za vozača (ROM) za korištenje unutarnjih komponenti.
Kako hardver kamere postaje sve složeniji (the dolazak dvostrukih kamera, na primjer), pristup izvoru HAL kamere učinio bi prijenos AOSP ROM-a s funkcionalnom kamerom mnogo lakšim pothvatom.
Međutim, proizvođači originalne opreme ne daju pristup HAL izvoru kamere iz raznih razloga. Prvo, ako nemaju sva vlasnička prava na kameru HAL (kao kada ugrađuju intelektualno vlasništvo drugih tvrtki), tada ne mogu distribuirati izvor. Drugo, objavljivanje HAL izvora kamere može ugroziti njihovo vlastito intelektualno vlasništvo. Konačno, tvrtke nemaju zakonsku obvezu pružiti ovaj izvorni kod (za razliku od izvornog koda kernela, što jesu obvezan izdati prema GPL-u), stoga nemaju poticaja da ga objave. Dakle, bez pristupa HAL izvoru kamere, kako točno programeri mogu natjerati kameru da radi na AOSP ROM-ovima? Odgovor je BLOB, shim i puno, puno otklanjanja pogrešaka.
Uređaj BLOB (Binary Large OBject) sadrži unaprijed zapakirane binarne datoteke koje su kompajlirani oblik softvera. U ovom slučaju HAL izvor kamere kompilira OEM i isporučuje ga na uređaje kao binarne datoteke. Kada programeri govore o BLOB-ovima, misle na one binarne datoteke koje se isporučuju na živim uređajima koje mogu izdvojiti. Sada, tema "camera BLOBs" ima dugo mučeni OnePlus mjesecima, ali istina je da su programeri uvijek imali pristup BLOB-ovima kamera. The kamera HAL izvorni kod je zlatna karta za programere ovdje, ali to će nikada, nikada ne biti pušten zbog zakonske opasnosti u koju bi doveo tvrtke poput OnePlusa.
Stoga programeri koji žele unijeti AOSP na uređaj ostaju samo s BLOB-ovima HAL-a kamere za koje nemaju pristup izvornom kodu. Rijetko, ako ikada, razvojni programer može upariti svoj AOSP ROM kod s kamerom HAL BLOB i očekivati da će raditi, pa kako bi premostili jaz između njih dvoje, programeri stvaraju ono što se naziva "podloška.”
"Shimati" znači "zaglaviti (nešto) ili ispuniti prostor." To je zapravo ono što programer radi kada pisanje shima—oni dodaju kod kako bi BLOB-u omogućili povezivanje s AOSP izvornim kodom na kojem rade s. Podloške se koriste kako bi BLOB-ovi svih različitih vrsta radili s AOSP-om, ali obično je BLOB kamera taj koji zahtijeva najviše podmetanja. Kao što smo već spomenuli, šimiranje je potrebno ne samo za prijenos novijih verzija Androida na uređaj (kao što je svi oni neslužbeni Android Oreo ROM-ovi), ali također potrebni prilikom prijenosa AOSP-a iste verzije Androida na taj uređaj.
Preporučena literatura: Od trgovine do police: detaljna kapitulacija o tome zašto su uređaji MSM8974 isključeni iz Nougata
OnePlus 2 je, primjerice, dobio svoje zadnje službeno veliko ažuriranje OS-a u obliku Androida 6.0 Marshmallow. Uređaj, međutim, zapravo ima potpuno radni prilagođeni ROM-ovi temeljeni na AOSP-u temeljen na Androidu Nougat, a to je zahvaljujući napornom radu programera i njihovih podmetača. Razdvojit ćemo neke primjere podložaka, ali prvo moramo razgovarati o tome kako točno podlošci rade.
Kako radi shiming?
Budući da programeri nemaju pristup izvoru HAL-a ili OEM ROM-a kamere (i samo unaprijed kompajliranim binarnim datotekama), ne mogu znati koje funkcije HAL kamere očekuje. Zbog toga često postoji neslaganje između naziva funkcije koju HAL kamere traži i stvarnog naziva funkcije u AOSP kodu s kojim programer radi.
Kako bi riješio ovaj problem, programer jednostavno stvara novu funkciju koja koristi isti naziv funkcije funkciju koju kamera HAL BLOB očekuje, ali ova nova funkcija samo izvršava ono što programer želi to za. Ova nova funkcija koja djeluje kao posrednik između BLOB-a i AOSP-a je podloška. Ovaj određeni scenarij u kojem BLOB ne uspijeva pronaći funkciju koju traži jedan je od najčešćih u kojima je potrebna podloška.
Možda će stvari imati malo više smisla uz hipotetski primjer koji uključuje OnePlus 3T. Napravit ćemo primjer koristeći OxygenOS i OnePlus kameru. Ako koristimo BLOB-ove kamere preuzete iz OxygenOS Nougat za OnePlus 3T za izradu Nougat ROM-a temeljenog na AOSP-u, mogli bismo naići na probleme. To je zato što će BLOB-ovi kamere (koje je izvorno sastavio OEM) moći referencirati sve funkcije koje su mu potrebne unutar OxygenOS-a, ali budući da prevedeni AOSP ROM možda nema te funkcije ili ih je možda preveo pod drugim imenom (što dovodi do nepodudarnosti između funkcijskih simbola), bit će greška. To se može popraviti stvaranjem nove funkcije unutar AOSP ROM-a s imenom koje BLOB očekuje—naša podloška.
Simboli u kontekstu programiranja koriste se za označavanje specifičnih funkcija u kodu. Simboli su potrebni jer se položaj funkcije može promijeniti kada se kod uređuje, pa kako bi se izbjeglo tvrdo kodiranje reference na funkcije, prevodilac stvara tablicu simbola koje druge funkcije mogu koristiti da uvijek upućuju na desnu stranu funkcija. Kada promijenite naziv funkcije prije kompajliranja, mijenja se i njezin simbol, dakle u osnovi sve promjene koji OEM napravi kameri HAL izvor prije kompilacije zahtijevat će od programera da stvore novi podloška.
Objašnjenje koje smo do sada ponudili zvuči kao da je stvaranje podmetača jednostavno. Promjena imena nekoliko funkcija tu i tamo ne zvuči previše teško, zar ne? Kad bi barem bilo tako jednostavno. Stvarnost podmetanja uključuje više od pukog preimenovanja funkcija. Razgovarali smo s XDA priznatim programerom Sultanxdom koji nam je mogao dati primjer jednog od težih shimova na kojima je radio.
Šivanje - nije tako lako kao što zvuči
Za one koji nisu upoznati s OnePlus 3T, prednja kamera je u početku bila prilično pokvarena. Prilagođeni ROM-ovi temeljeni na AOSP-u. Za početak, pokušaj snimanja bilo koje slike veće od 8 MP rezultirao bi rušenje. U svom pokušaju da riješi ovo pitanje, Sultanxda je napravio nekoliko podloške kako bi prednja kamera OnePlus 3T ispravno radila.
Shim #1 - Promjena naziva paketa kamere
Kako bi spriječio da se prednja kamera sruši kad god korisnik snimi sliku veću od 8 MP, Sultanxda je prisilila kameru HAL da sve kamere identificira kao OnePlus kameru. To je učinjeno jer je OnePlus odlučio posvetiti pomoćnu funkciju određenim aplikacijama (isOnePlusCamera, isFacebookCamera, itd.) iz nekog razloga. Sultanxda je to popravila tako što je shimirala kameru HAL tako da pokazuje na novu funkciju koja uvijek vraća "true" kao da korisnik koristi OnePlus kameru - čak i kada ne koristi.
Shim #2 - Onemogući QuadraCfa
Za svoj sljedeći shim, morao je onemogućiti QuadraCfa, što je vjerojatno vlasnička Qualcommova tehnologija koja se odnosi na kameru. Kažemo vjerojatno jer ni ja ni Sultanxda nismo točno sigurni što je QuadraCfa, ali Sultanxda zna da je pokvario prednju kameru kad god je bila uključena.
Primijetio je da će se QuadraCfa nekako omogućiti, ali nije bio siguran zašto ili kako to radi. Rješavanje ovoga zahtijevalo je prilično nekonvencionalnu modifikaciju s njegove strane. U konvencionalnom shimu, funkcija shima, kada se kompilira, daje simbol koji nedostaje i koji BLOB traži. U ovom slučaju, BLOB je već imao simbole koji su mu bili potrebni - one koji su vjerojatno predstavljali funkcije koje su pokretale QuadraCfa.
Stoga je trebao nadjačati simbole koje koristi kamera HAL i u biti učiniti da "nedostaju" tako njegov podloške bi dale te simbole koji "nedostaju". Jedini način da to učinite je putem hex uređivanje same kamere HAL. Hex uređivanje je u osnovi pregledavanje hrpe neorganiziranih besmislica u obliku binarnih podataka kako bi se pronašla igla u plastu sijena—bilo funkcija ili niz koji želite urediti.
Heksadecimalno uređivanje funkcije znatno je teže nego heksadecimalno uređivanje niza, ali na sreću, Sultanxda je uspjela izbjeći heksadecimalno uređivanje funkcija iza QuadraCfa umjesto heksadecimalno uređivanje naziva simbola kako bi se ti simboli poništili.
Shim #3 - Bright Light Crash Fix
Sljedeće, Sultanxda je identificirao da bi snimanje slike s prednje kamere u uvjetima jakog osvjetljenja uzrokovalo pad kamere. Kako bi reproducirao ovu grešku na vlastitom uređaju, Sultanxda zapravo uključio funkciju svjetiljke na svom OnePlus One i osvijetlio prednju kameru OnePlus 3T kako bi se srušio i proizveo korisne zapise! Nakon što je otkrio koja je funkcija uzrokovala pad, stvorio je podlošku kako bi natjerao uređaj da cijelo vrijeme koristi način slabog osvjetljenja za prednju kameru.
Shim #4 - Slike niske rezolucije s prednje kamere
Nakon što je popravio pad jakog svjetla s prethodnim shimom, Sultanxda je otkrio još jedan bug koji je zapravo nastao kao izravna posljedica tog shima: slike niske rezolucije s prednje kamere. Umjesto snimanja fotografija u razlučivosti koju korisnik zahtijeva (npr. 16MP), rezultirajuća slika bila bi snimljena na 4MP.
Rješavanje ovoga zahtijevalo je da on podmetne funkcije handleSuperResolution i isSuperResolution da uvijek vrati true, ali SAMO kada je prednja kamera aktivna (jer bi se inače kamera srušila prilikom snimanja slika sa stražnjeg senzora).
Naučena lekcija - podmetanje može biti teško
Sultanxda priznaje da podloške koje je morao izraditi kako bi prednja kamera OnePlus 3T radila ne predstavljaju tipičan primjer podloška. Prilično je ponosan na svoj shim s obzirom na njegovu složenost i rijetku potrebu za heksadecimalnim uređivanjem samog BLOB-a. Ali ovaj primjer samo pokazuje koliko teško može biti natjerati hardver kamere da radi na određenim uređajima.
Neka tvoje pustolovine s šivanjem fotoaparata budu manje bolne od mojih. -Sultanija
Cjepanice, cjepanice i još cjepanica. Bez dosljednog načina reproduciranja rušenja i bez zapisa, razvojni programeri nemaju mnogo nade da će pronaći izvor problema. Čak i ako pronađu što uzrokuje problem, to nije uvijek jednostavno rješenje. Cijeli proces pronalaženja i uklanjanja ovih grešaka može trajati danima ili tjednima i razlog je zašto je popravljanje kamere na AOSP ROM-ovima jedan od težih zadataka.
Ako vaš uređaj ima AOSP ROM prenesen na njega s potpuno funkcionalnim hardverom, nadamo se da možete početi cijenite borbu kroz koju su ti programeri možda prošli kako bi vam ih donijeli značajke. Cijenite ih za njihov rad, jer nije lako. To je puno posla koji velika većina korisnika neće niti primijetiti, budući da se talentirani programeri na našim forumima brinu o mnogim neviđenim dijelovima Androida.
Željeli bismo posebno zahvaliti Sultanxdi za mnoge doprinose koje je predložio u izradi ovog članka.