Uden kildekode, hvordan får udviklere hardwarekomponenter såsom kameraer til at fungere i tilpassede ROM'er? Svaret er en BLOB, shim og masser af fejlfinding.
Med udgivelsen af Android Oreo og mange enheder som f.eks Xiaomi Redmi Note 3, Google Nexus 5 og andre, der uofficielt modtager det, er det nok rimeligt at undre sig over, hvorfor de samme funktioner (for det meste kameraet) har tendens til at blive ødelagt, når udviklere porterer en Android Open Source Project (AOSP) baseret ROM. Du har sikkert set XDA-forumtråde af ROM'er med en lang liste af ødelagte funktioner øverst. "Hvad virker" efterfulgt af en liste over fungerende funktioner, så nedenunder det ikoniske "Hvad virker ikke? Du fortæller mig!" er to populære refrains på vores fora, der praktisk talt er blevet et meme på steder som Reddit og Twitter.
Hvorfor går så meget funktionalitet i stykker, når en udvikler forsøger at overføre en AOSP ROM til deres enhed? Det grundlæggende svar er, at fordi funktioner ændrer sig på tværs af forskellige versioner af Android, vil gamle enhedsdrivere pakket som BLOB'er ikke fungere med nyere versioner af Android, eller endda bare med standard AOSP. For at overvinde det gør udviklere brug af det, der kaldes et "shim", men den involverede proces er vanskelig, tidskrævende og nogle gange meget svær at fejlfinde.
I denne artikel vil vi skitsere, hvordan shims fungerer, især med hensyn til at få kameraet til at fungere korrekt på AOSP-baserede ROM'er. Vi vil bruge OnePlus 3T som eksempel. Bemærk, at vanskeligheden ved at få disse funktioner til at fungere er meget enhedsspecifik.
OnePlus 3T kører OxygenOS. Selvom OnePlus-telefoner er kendt for deres tilpassede udviklingsvenlighed, er der meget arbejde, som udviklere gør bag kulisserne for at lave stabile porte af AOSP.
Hvad er en shim eller en BLOB?
For overhovedet at begynde at forstå en del af, hvad udviklere laver, skal vi først forklare et par ting. Selvom Android OS er open source (det kaldes Android Open Source Project af en grund), er softwaren (uden kernen), der leveres på tusindvis af Android-enheder, det ikke. Udviklere har ikke adgang til kildekoden til Samsung oplevelse, EMUI, OxygenOS, eller nogen af de andre tredjepartsvarianter af Android.
Nu er udviklere, der overfører lager AOSP til en ikke-Google-enhed, sandsynligvis ligeglade med kildekoden til disse Android-skin, da de ikke bliver at ændre og bygge disse ROM'er. Det ville være sandt, hvis ikke for én stor, stor grund: de dele, der er nødvendige for at få kameraet til at fungere ordentligt, hovedsagelig det kamera HAL (Hardware Abstraktionslag), er også lukket kilde.
Problemet med ikke kun at have kameraets HAL, men også ROM'en lukket kilde, er, at udviklere, der arbejder på at overføre AOSP til deres enhed, arbejder blindt. Den lukkede kilde OEM ROM er i stand til at interface med kameraets HAL fint, fordi OEM har adgang til kameraets HAL kilde. Kameraets HAL er det, der tillader ROM'en at "tale til" kamerahardwaren - uden den ville kameraet være ikke-funktionelt. Tænk på kameraet HAL som bilens rat og pedaler. Rattet/pedalerne giver mulighed for kontrol af køretøjets interne komponenter ved at give føreren en ekstern grænseflade (ROM'en) til at gøre brug af de interne komponenter.
Efterhånden som kamerahardware bliver mere og mere kompleks (den fremkomsten af dobbeltkameraer, for eksempel), at have adgang til kameraets HAL-kilde ville gøre portering af en AOSP ROM med et funktionelt kamera til en meget lettere bestræbelse.
OEM'er giver dog ikke adgang til kameraets HAL-kilde af forskellige årsager. For det første, hvis de ikke har alle ejerskabsrettighederne til kamera-HAL (såsom når de inkorporerer intellektuel ejendom fra andre virksomheder), så kan de ikke distribuere kilden. For det andet kan frigivelse af kameraets HAL-kilde bringe deres egen intellektuelle ejendom i fare. Endelig er virksomheder ikke under nogen juridisk forpligtelse til at levere denne kildekode (i modsætning til kernekildekoden, som de er forpligtet til at frigive i henhold til GPL), og derfor har de ikke noget incitament til at frigive den. Så uden adgang til kameraets HAL-kilde, hvordan får udviklere så kameraet til at fungere på AOSP ROM'er? Svaret er en BLOB, shim og masser af fejlfinding.
En enhed BLOB (Binary Large OBject) indeholder færdigpakkede binære filer, som er den kompilerede form for software. I dette tilfælde kompileres kameraets HAL-kilde af OEM og sendes på enheder som binære filer. Når udviklere taler om BLOB'er, henviser de til de binære filer, der sendes på live-enheder, som de er i stand til at udtrække. Nu har emnet "kamera BLOBs". længe plaget OnePlus i mange måneder, men sandheden i sagen er, at udviklere altid har haft adgang til kameraets BLOB'er. Det kamera HAL kildekode er den gyldne billet for udviklere her, men det vil aldrig, aldrig blive frigivet på grund af den juridiske fare ville det sætte virksomheder som OnePlus ind.
Udviklere, der ønsker at bringe AOSP ind på en enhed, har således kun BLOB'er fra kameraets HAL, som de ikke har adgang til kildekoden til. Sjældent om nogensinde kan en udvikler parre deres AOSP ROM-kode med kameraets HAL BLOB og forvente, at det virker, så for at bygge bro mellem de to, skaber udviklere det, der kaldes en "shim.”
At "shim" er at "kile (noget) eller fylde et mellemrum." Dette er faktisk, hvad en udvikler gør hvornår skrive et shim - de tilføjer kode for at give BLOB'en mulighed for at interface med den AOSP-kildekode, de arbejder med. Shims bruges til at få BLOB'er af alle forskellige slags til at fungere med AOSP, men normalt er det kameraet BLOB, der kræver mest shimming. Som vi nævnte før, kræves shimming ikke kun for at overføre nyere versioner af Android til en enhed (som f.eks. alle de uofficielle Android Oreo ROM'er), men også nødvendige, når AOSP af den samme Android-version overføres til den enhed.
Anbefalet læsning: Fra butik til hylde: En dybdegående kapitulation af hvorfor MSM8974-enheder er udelukket fra Nougat
OnePlus 2 modtog for eksempel sin sidste officielle større OS-opdatering i form af Android 6.0 Marshmallow. Enheden har dog faktisk fuldt fungerende tilpassede AOSP-baserede ROM'er baseret på Android Nougat, og det er takket være det hårde arbejde fra udviklere og deres shims. Vi vil nedbryde nogle eksempler på shims, men først skal vi tale om, hvordan shims præcis fungerer.
Hvordan fungerer shimming?
Da udviklere ikke har adgang til kameraets HAL- eller OEM ROM-kilde (og kun de prækompilerede binære filer), kan de ikke vide, hvilke funktioner kameraets HAL forventer. På grund af dette er der ofte et misforhold mellem navnet på den funktion, som kameraet HAL leder efter, og det faktiske navn på funktionen i AOSP-koden, som udvikleren arbejder med.
For at løse dette problem opretter udvikleren blot en ny funktion, der bruger det samme navn som funktion, som kameraet HAL BLOB forventer, men denne nye funktion udfører bare, hvad udvikleren ønsker det til. Denne nye funktion, der fungerer som en mellemmand mellem BLOB og AOSP, er shim. Dette særlige scenarie, hvor BLOB ikke kan finde den funktion, den leder efter, er et af de mest almindelige, hvor der er behov for et mellemlæg.
Måske vil tingene give lidt mere mening med et hypotetisk eksempel, der involverer OnePlus 3T. Vi vil lave et eksempel ved hjælp af OxygenOS og OnePlus-kameraet. Hvis vi bruger kamera-BLOB'er taget fra OxygenOS Nougat til OnePlus 3T til at bygge en AOSP-baseret Nougat ROM, kan vi løbe ind i problemer. Dette skyldes, at kamera-BLOB'erne (som oprindeligt blev kompileret af OEM) vil være i stand til at referere til alle de funktioner, det har brug for i OxygenOS, men da kompileret AOSP ROM har muligvis ikke disse funktioner eller kan have kompileret dem under et andet navn (hvilket fører til uoverensstemmelse mellem funktionssymboler), vil der være en fejl. Dette kan rettes ved at oprette en ny funktion i AOSP ROM'en med det navn, som BLOB forventer - vores shim.
Symboler i en programmeringssammenhæng bruges til at henvise til specifikke funktioner i kode. Symboler er nødvendige, fordi positionen af en funktion kan ændre sig, når koden redigeres, og det for at undgå hardkodning referencer til funktioner, opretter compileren en tabel med symboler, som andre funktioner kan bruge til altid at henvise til højre fungere. Når du ændrer navnet på en funktion før kompilering, ændres dens symbol også, så stort set alle ændringer som OEM'en laver til kameraets HAL-kilde før kompilering vil kræve, at udviklere laver en ny shim.
Forklaringen, vi har tilbudt indtil videre, får det til at lyde, som om det er nemt at oprette shims. At ændre et par funktionsnavne her og der lyder ikke for svært, vel? Hvis det bare var så nemt. Virkeligheden med shims involverer mere end blot funktionsomdøbninger. Vi talte med XDA Recognized Developer Sultanxda, som var i stand til at give os et eksempel på en af de mere vanskelige shims, han har arbejdet på.
Shimming - Ikke så nemt som det lyder
For dem, der ikke kender til OnePlus 3T, var det frontvendte kamera temmelig ødelagt i starten på AOSP-baserede brugerdefinerede ROM'er. Til at begynde med ville et forsøg på at tage et billede over 8 MP resultere i styrter ned. I sit forsøg på at løse dette problem lavede Sultanxda flere shims for at lade OnePlus 3T frontvendte kamera fungere korrekt.
Shim #1 - Ændring af kamerapakkens navn
For at forhindre det frontvendte kamera i at gå ned, når brugeren tog et billede over 8 MP, tvang Sultanxda kameraet HAL til at identificere alle kameraer som OnePlus-kameraet. Dette er gjort, fordi OnePlus besluttede at dedikere en hjælpefunktion til visse applikationer (isOnePlusCamera, isFacebookCameraosv.) af en eller anden grund. Sultanxda løste dette ved at shimme kameraets HAL, så det peger på en ny funktion, der altid returnerer "sand", som om brugeren bruger OnePlus-kameraet - selv når de ikke er det.
Shim #2 - Deaktiver QuadraCfa
Til sit næste shim var han nødt til at deaktivere QuadraCfa, som formentlig er en proprietær Qualcomm-teknologi relateret til kameraet. Vi siger formentlig, fordi hverken jeg selv eller Sultanxda er helt sikker på, hvad QuadraCfa er, men Sultanxda ved, at det knækkede det frontvendte kamera, når det blev aktiveret.
Han observerede, at QuadraCfa på en eller anden måde ville aktivere sig selv, men han var ikke sikker på, hvorfor eller hvordan det gjorde det. At løse dette krævede en ret ukonventionel modifikation fra hans side. I en konventionel shim giver shim-funktionen, når den er kompileret, det manglende symbol, som BLOB'en leder efter. I dette tilfælde havde BLOB'en allerede de symboler, den havde brug for - dem, der formodentlig repræsenterede de funktioner, der startede QuadraCfa.
Derfor var han nødt til at tilsidesætte de symboler, der blev brugt af kameraets HAL og i det væsentlige få dem til at "mangle" så hans shims ville give de "manglende" symboler. Den eneste måde at gøre det på er via hex-redigering af selve kameraets HAL. Hex-redigering er dybest set at kigge gennem en masse uorganiseret volapyk i form af binære data for at finde en nål i høstakken - enten en funktion eller en streng, du ønsker at redigere.
Hex-redigering af en funktion er væsentligt sværere end hex-redigering af en streng, men heldigvis kunne Sultanxda undgå at skulle hex-redigere funktionerne bag QuadraCfa ved i stedet at hex-redigering af symbolnavnene for at annullere disse symboler.
Shim #3 - Bright Light Crash Fix
Dernæst identificerede Sultanxda, at at tage et billede fra det fremadvendte kamera under skarpe lysforhold ville få kameraet til at gå ned. For at reproducere denne fejl på sin egen enhed, Sultanxda faktisk tændte lommelygtefunktionen på sin OnePlus One og skinnede lyset foran OnePlus 3T's frontvendte kamera for at få det til at gå ned og producere brugbare logfiler! Da han opdagede, hvilken funktion der forårsagede styrtet, lavede han et shim for at tvinge enheden til hele tiden at bruge svagt lys til det frontvendte kamera.
Shim #4 - Lavopløsnings frontvendte kamerabilleder
Efter at have rettet det kraftige lysnedbrud med det tidligere shim, opdagede Sultanxda en anden fejl, som faktisk opstod som et direkte resultat af det shim: lavopløsnings frontvendte kamerabilleder. I stedet for at tage billeder med den opløsning, brugeren anmoder om (f. 16 MP), ville det resulterende billede blive taget ved 4 MP.
At løse dette krævede, at han shimde funktionerne handleSuperResolution og isSuperResolution for altid at returnere sandt, men KUN når det frontvendte kamera er aktivt (fordi ellers ville kameraet gå ned, når der blev taget billeder fra den bageste sensor).
Lektion lært - Shimming kan være svært
Sultanxda indrømmer, at de shims, han skulle lave for at få OnePlus 3T frontvendte kamera til at virke, ikke repræsenterer dit typiske eksempel på et shim. Han er ret stolt af sit shim i betragtning af dets kompleksitet og den sjældne nødvendighed af at hex-redigere selve BLOB. Men dette eksempel viser bare, hvor svært det kan være at få kameraets hardware til at fungere på bestemte enheder.
Må dine kamera-shim-eventyr være mindre smertefulde, end mine var. - Sultanxda
Logs, logs og flere logs. Uden en konsekvent måde at reproducere et nedbrud og uden logfiler, har udviklere lidt håb om at finde kilden til problemet. Selvom de finder, hvad der forårsager problemet, er det ikke altid en ligetil løsning. Hele processen med at finde og knuse disse fejl kan tage dage eller uger og er grunden til, at det er en af de sværere opgaver at rette kameraet på AOSP ROM'er.
Hvis din enhed har en AOSP ROM porteret til den med fuldt fungerende hardware, kan du forhåbentlig begynde at værdsætter den kamp, som disse udviklere måtte have gennemgået for at bringe dig dem funktioner. Sæt pris på dem for deres arbejde, for det er ikke nemt. Det er meget arbejde, som langt de fleste brugere ikke engang vil bemærke, da talentfulde udviklere på vores fora tager sig af de mange usete dele af Android.
Vi vil gerne give en særlig tak til Sultanxda for de mange bidrag, han foreslog under udarbejdelsen af denne artikel.