Hoe krijgen ontwikkelaars zonder broncode hardwarecomponenten zoals camera's in aangepaste ROM's werkend? Het antwoord is een BLOB, shim en veel foutopsporing.
Met de release van Android Oreo en veel apparaten zoals de Xiaomi Redmi Opmerking 3, Google Nexus5 En anderen ontvangen het onofficieel, is het waarschijnlijk eerlijk om je af te vragen waarom dezelfde functies (meestal de camera) vaak kapot gaan als ontwikkelaars een op Android Open Source Project (AOSP) gebaseerd ROM porten. Je hebt waarschijnlijk XDA-forumthreads van ROM's gezien met een lange lijst met kapotte functies bovenaan. ‘Wat werkt’, gevolgd door een lijst met werkende functies, en daaronder het iconische ‘Wat werkt niet? Vertel jij mij het!" zijn twee populaire refreinen op onze forums die praktisch een meme zijn geworden op plaatsen als Reddit en Twitter.
Waarom wordt er zoveel functionaliteit verbroken wanneer een ontwikkelaar een AOSP ROM naar zijn apparaat probeert te porten? Het basisantwoord is dat omdat functies veranderen in verschillende versies van Android, oude apparaatstuurprogramma's verpakt als BLOB's niet zullen werken met nieuwere versies van Android, of zelfs alleen maar met stock-AOSP. Om dat te ondervangen maken ontwikkelaars gebruik van wat een ‘shim’ wordt genoemd, maar het proces dat daarmee gepaard gaat is lastig, tijdrovend en soms erg moeilijk te debuggen.
In dit artikel zullen we schetsen hoe shims werken, vooral met betrekking tot het correct laten werken van de camera op AOSP-gebaseerde ROM's. We zullen de OnePlus 3T als voorbeeld gebruiken. Houd er rekening mee dat de moeilijkheid om deze functies werkend te krijgen, zeer apparaatspecifiek is.
OnePlus 3T met OxygenOS. Hoewel OnePlus-telefoons bekend staan om hun aangepaste ontwikkelvriendelijkheid, wordt er achter de schermen veel werk verricht door ontwikkelaars om stabiele poorten van AOSP te maken.
Wat is een vulring of een BLOB?
Om zelfs maar een deel van wat ontwikkelaars doen te begrijpen, moeten we eerst een paar dingen uitleggen. Hoewel het Android-besturingssysteem open source is (het wordt niet voor niets het Android Open Source Project genoemd), is de software (zonder kernel) die op duizenden Android-apparaten wordt geleverd dat niet. Ontwikkelaars hebben geen toegang tot de broncode van Samsung-ervaring, EMUI, ZuurstofOS, of een van de andere versies van Android van derden.
Nu geven ontwikkelaars die stock-AOSP overbrengen naar een niet-Google-apparaat waarschijnlijk niets om de broncode van deze Android-skins, aangezien dat ook niet het geval zal zijn het aanpassen en bouwen van deze ROM's. Dat zou waar zijn, al was het niet om één grote, grote reden: voornamelijk de onderdelen die nodig zijn om de camera goed te laten werken de camera HAL (Hardware-abstractielaag), zijn ook gesloten bron.
Het probleem met het feit dat niet alleen de HAL van de camera, maar ook de gesloten ROM-bron is, is dat ontwikkelaars die werken aan het porten van AOSP naar hun apparaat, blind werken. De closed source OEM ROM kan prima communiceren met de camera-HAL omdat de OEM toegang heeft tot de HAL-bron van de camera. De camera-HAL zorgt ervoor dat het ROM met de camerahardware kan 'praten'. Zonder deze HAL zou de camera niet functioneren. Beschouw de camera HAL als het stuur en de pedalen van de auto. Het stuurwiel/de pedalen maken controle over de interne componenten van het voertuig mogelijk door een externe interface te bieden waarmee de bestuurder (de ROM) gebruik kan maken van de interne componenten.
Naarmate camerahardware steeds complexer wordt (de komst van dubbele camera's(bijvoorbeeld) zou het hebben van toegang tot de HAL-bron van de camera het overzetten van een AOSP ROM met een functionele camera een veel eenvoudiger onderneming maken.
OEM's bieden echter om verschillende redenen geen toegang tot de HAL-bron van de camera. Ten eerste: als ze niet alle eigendomsrechten op de camera HAL hebben (zoals wanneer ze intellectueel eigendom van andere bedrijven overnemen), kunnen ze de bron niet verspreiden. Ten tweede kan het vrijgeven van de HAL-bron van de camera hun eigen intellectuele eigendom in gevaar brengen. Ten slotte zijn bedrijven niet wettelijk verplicht om deze broncode te verstrekken (in tegenstelling tot de kernelbroncode die ze wel zijn). verplicht vrij te geven onder de GPL), dus ze hebben geen prikkel om het vrij te geven. Dus hoe krijgen ontwikkelaars, zonder toegang tot de HAL-bron van de camera, de camera precies werkend op AOSP ROM's? Het antwoord is een BLOB, shim en heel veel debuggen.
Een apparaat BLOB (Binary Large OBject) bevat voorverpakte binaire bestanden die de gecompileerde vorm van software zijn. In dit geval wordt de HAL-bron van de camera samengesteld door de OEM en als binaire bestanden op apparaten verzonden. Wanneer ontwikkelaars over BLOB's praten, verwijzen ze naar de binaire bestanden die op live-apparaten worden verzonden en die ze kunnen extraheren. Nu is er het onderwerp “camera-BLOB’s”. lang geplaagde OnePlus maanden lang, maar de waarheid is dat ontwikkelaars altijd toegang hebben gehad tot de camera-BLOB's. De camera HAL-broncode is het gouden ticket voor ontwikkelaars hier, maar dat zal wel gebeuren nooit meer vrijgelaten worden vanwege het juridische gevaar dat bedrijven als OnePlus daarin zouden terechtkomen.
Ontwikkelaars die AOSP op een apparaat willen brengen, blijven dus alleen achter met BLOB's van de camera-HAL waarvoor ze geen toegang hebben tot de broncode. Zelden of nooit kan een ontwikkelaar zijn AOSP ROM-code koppelen aan de HAL BLOB van de camera en verwachten dat deze werkt, dus om de kloof tussen de twee te overbruggen, creëren ontwikkelaars een zogenaamde “vulplaatje.”
'Shim' betekent '(iets) vastzetten of een ruimte opvullen'. Dit is feitelijk wat een ontwikkelaar wanneer doet een shim schrijven: ze voegen code toe zodat de BLOB kan communiceren met de AOSP-broncode waarmee ze werken met. Shims worden gebruikt om allerlei soorten BLOB's te laten werken met AOSP, maar meestal is het de BLOB van de camera die de meeste shimming vereist. Zoals we eerder vermeldden, is shimming niet alleen vereist voor het porten van nieuwere versies van Android naar een apparaat (zoals al die onofficiële Android Oreo ROM's) maar ook nodig bij het porten van AOSP van dezelfde Android-versie daarop apparaat.
Aanbevolen lectuur: Van winkel tot plank: een diepgaande uitleg van waarom MSM8974-apparaten zijn uitgesloten van Nougat
De OnePlus 2 ontving bijvoorbeeld zijn laatste officiële grote OS-update in de vorm van Android 6.0 Marshmallow. Het apparaat heeft dat echter wel volledig werkende aangepaste AOSP-gebaseerde ROM's gebaseerd op Android Nougat, en dat is te danken aan het harde werk van ontwikkelaars en hun shims. We zullen enkele voorbeelden van shims opsplitsen, maar eerst moeten we praten over hoe shims precies werken.
Hoe werkt het shimmen?
Omdat ontwikkelaars geen toegang hebben tot de HAL- of OEM-ROM-bron van de camera (en alleen de vooraf gecompileerde binaire bestanden), kunnen ze niet weten welke functies de HAL van de camera verwacht. Hierdoor is er vaak een discrepantie tussen de naam van de functie waarnaar de HAL van de camera zoekt en de daadwerkelijke naam van de functie in de AOSP-code waarmee de ontwikkelaar werkt.
Om dit probleem op te lossen, maakt de ontwikkelaar eenvoudigweg een nieuwe functie die dezelfde naam gebruikt als de functie die de camera HAL BLOB verwacht, maar deze nieuwe functie voert gewoon uit wat de ontwikkelaar wil het aan. Deze nieuwe functie die fungeert als tussenpersoon tussen de BLOB en AOSP is de vulring. Dit specifieke scenario waarin de BLOB er niet in slaagt de functie te vinden waarnaar hij op zoek is, is een van de meest voorkomende scenario's waarbij een vulstuk nodig is.
Misschien wordt het wat logischer met een hypothetisch voorbeeld van de OnePlus 3T. We zullen een voorbeeld maken met OxygenOS en de OnePlus-camera. Als we camera-BLOB's uit OxygenOS Nougat voor de OnePlus 3T gebruiken om een op AOSP gebaseerd Nougat-ROM te bouwen, kunnen we problemen tegenkomen. Dit komt omdat de camera-BLOB's (die oorspronkelijk door de OEM zijn samengesteld) kunnen verwijzen naar alle functies die nodig zijn binnen OxygenOS, maar aangezien de gecompileerde AOSP ROM deze functies mogelijk niet heeft of ze onder een andere naam heeft gecompileerd (wat leidt tot een mismatch tussen functiesymbolen), zal er een fout. Dit kan worden opgelost door een nieuwe functie binnen de AOSP ROM te maken met de naam die de BLOB verwacht: onze shim.
Symbolen in een programmeercontext worden gebruikt om naar specifieke functies in code te verwijzen. Symbolen zijn nodig omdat de positie van een functie kan veranderen wanneer de code wordt bewerkt, en dus om hardcoding te voorkomen verwijzingen naar functies creëert de compiler een tabel met symbolen die andere functies kunnen gebruiken om altijd naar rechts te verwijzen functie. Wanneer u de naam van een functie wijzigt voordat u deze compileert, verandert het symbool ervan ook, dus eigenlijk alle wijzigingen die de OEM vóór de compilatie in de HAL-bron van de camera aanbrengt, vereist dat ontwikkelaars een nieuwe maken vulplaatje.
Uit de uitleg die we tot nu toe hebben gegeven, klinkt het alsof het maken van vulplaatjes eenvoudig is. Hier en daar een paar functienamen veranderen klinkt niet zo moeilijk, toch? Was het maar zo makkelijk. De realiteit van shims omvat meer dan alleen het hernoemen van functies. We spraken met XDA Recognized Developer Sultanxda, die ons een voorbeeld kon geven van een van de moeilijkere shims waaraan hij heeft gewerkt.
Shimmen - niet zo eenvoudig als het klinkt
Voor degenen die niet bekend zijn met de OnePlus 3T: de camera aan de voorkant was aanvankelijk nogal kapot Op AOSP gebaseerde aangepaste ROM's. Om te beginnen zou een poging om een foto van meer dan 8 MP te maken resulteren in crashen. In zijn poging dit probleem op te lossen, heeft Sultanxda er verschillende gemaakt vulplaatjes om de camera aan de voorzijde van de OnePlus 3T correct te laten werken.
Shim #1 - De naam van het camerapakket wijzigen
Om te voorkomen dat de camera aan de voorzijde crasht wanneer de gebruiker een foto van meer dan 8 MP maakt, dwingt Sultanxda de camera HAL om alle camera's te identificeren als de OnePlus-camera. Dit wordt gedaan omdat OnePlus heeft besloten een helperfunctie te wijden aan bepaalde applicaties (isOnePlusCamera, isFacebookCamera, enz.) om een of andere reden. Sultanxda heeft dit opgelost door de HAL van de camera te verschuiven, zodat deze naar een nieuwe functie verwijst die altijd 'waar' retourneert alsof de gebruiker de OnePlus-camera gebruikt, zelfs als dat niet het geval is.
Vulplaatje #2 - QuadraCfa uitschakelen
Voor zijn volgende shim moest hij QuadraCfa uitschakelen, vermoedelijk een eigen Qualcomm-technologie met betrekking tot de camera. We zeggen vermoedelijk omdat noch ikzelf, noch Sultanxda precies zeker weten wat QuadraCfa is, maar Sultanxda weet wel dat de camera aan de voorzijde kapot ging wanneer deze werd ingeschakeld.
Hij merkte op dat QuadraCfa zichzelf op de een of andere manier mogelijk zou maken, maar hij wist niet zeker waarom of hoe het dat deed. Om dit op te lossen was een nogal onconventionele aanpassing van zijn kant nodig. In een conventionele shim levert de shim-functie, wanneer deze is gecompileerd, het ontbrekende symbool waarnaar de BLOB op zoek is. In dit geval beschikte de BLOB al over de symbolen die hij nodig had: de symbolen die vermoedelijk de functies vertegenwoordigden die QuadraCfa opstartten.
Hij moest dus de symbolen die door de camera HAL worden gebruikt, vervangen en ze in wezen ‘ontbrekend’ maken zijn vulplaatjes zouden voor die “ontbrekende” symbolen zorgen. De enige manier om dat te doen is via hex bewerken van de camera HAL zelf. Hex-bewerking is in feite het doorzoeken van een hoop ongeorganiseerd gebrabbel in de vorm van binaire gegevens om een speld in de hooiberg te vinden: een functie of een string die je wilt bewerken.
Hex-bewerking van een functie is aanzienlijk moeilijker dan hex-bewerking van een string, maar gelukkig kon Sultanxda voorkomen dat hij de functies achter QuadraCfa moest bewerken door in plaats daarvan hex de symboolnamen bewerken om deze symbolen ongeldig te maken.
Shim #3 - Crashfix bij helder licht
Vervolgens stelde Sultanxda vast dat het maken van een foto met de camera aan de voorzijde onder fel licht ertoe zou leiden dat de camera crasht. Om deze bug op zijn eigen apparaat te reproduceren, heeft Sultanxda eigenlijk zette de zaklampfunctie van zijn OnePlus One aan en scheen het licht voor de camera aan de voorzijde van de OnePlus 3T om het te laten crashen en bruikbare logs te produceren! Toen hij eenmaal ontdekte welke functie de crash veroorzaakte, creëerde hij een vulstuk om het apparaat te dwingen de modus voor weinig licht altijd te gebruiken voor de camera aan de voorzijde.
Shim #4 - Camerabeelden met lage resolutie aan de voorzijde
Na het oplossen van de crash bij fel licht met de vorige shim, ontdekte Sultanxda nog een bug die feitelijk ontstond als een direct gevolg van die shim: camerabeelden met lage resolutie aan de voorzijde. In plaats van foto's te maken met de door de gebruiker gevraagde resolutie (bijv. 16 MP), wordt de resulterende foto gemaakt met 4 MP.
Om dit op te lossen, moest hij de functies opvullen handleSuperResolution En isSuperResolution om altijd waar terug te geven, maar ALLEEN wanneer de camera aan de voorzijde actief is (omdat de camera anders zou crashen bij het maken van foto's met de sensor aan de achterzijde).
Geleerde les - Shimmen kan moeilijk zijn
Sultanxda geeft toe dat de vulplaatjes die hij moest maken om de camera aan de voorzijde van de OnePlus 3T werkend te krijgen, niet het typische voorbeeld van een vulplaatje zijn. Hij is nogal trots op zijn vulstuk, gezien de complexiteit ervan en de zeldzame noodzaak om de BLOB zelf te bewerken. Maar dit voorbeeld laat alleen maar zien hoe moeilijk het kan zijn om de camerahardware op bepaalde apparaten werkend te krijgen.
Mogen jouw camera-shim-avonturen minder pijnlijk zijn dan de mijne. -Sultanxda
Logboeken, logboeken en nog eens logboeken. Zonder een consistente manier om een crash te reproduceren en zonder logbestanden hebben ontwikkelaars weinig hoop de oorzaak van het probleem te vinden. Zelfs als ze wel ontdekken wat het probleem veroorzaakt, is dit niet altijd een eenvoudige oplossing. Het hele proces van het vinden en oplossen van deze bugs kan dagen of weken duren en is de reden waarom het repareren van de camera op AOSP ROM's een van de moeilijkere taken is.
Als op uw apparaat een AOSP ROM is geporteerd met volledig functionerende hardware, kunt u daar hopelijk mee beginnen waardeer de strijd die deze ontwikkelaars mogelijk hebben doorgemaakt om u deze te kunnen bieden functies. Waardeer ze voor hun werk, want het is niet gemakkelijk. Het is een hoop werk dat de overgrote meerderheid van de gebruikers niet eens zal merken, aangezien getalenteerde ontwikkelaars op onze forums zorg dragen voor de vele onzichtbare delen van Android.
We willen Sultanxda speciaal bedanken voor de vele bijdragen die hij heeft voorgesteld bij het maken van dit artikel.