Jak bez zdrojového kódu získají vývojáři hardwarové komponenty, jako jsou kamery pracující ve vlastních ROM? Odpověď je BLOB, podložka a spousta ladění.
S vydáním Android Oreo a mnoha zařízení, jako je Xiaomi Redmi Note 3, Google Nexus 5 a jiní to neoficiálně dostávají, je pravděpodobně spravedlivé se divit, proč stejné funkce (většinou fotoaparát) mají tendenci být narušeny, když vývojáři portují ROM založenou na Android Open Source Project (AOSP). Pravděpodobně jste viděli vlákna ROM na fóru XDA s dlouhým seznamem poškozených funkcí nahoře. „Co funguje“ následuje seznam pracovních funkcí a pod ním ikonické „Co nefunguje? To mi řekni ty!" jsou dva oblíbené refrény na našich fórech, které se prakticky staly memem na místech jako Reddit a Twitter.
Proč je tolik funkcí poškozeno, kdykoli se vývojář pokusí přenést AOSP ROM do svého zařízení? Základní odpovědí je, že vzhledem k tomu, že se funkce v různých verzích Androidu mění, staré ovladače zařízení zabalené jako BLOB nebudou fungovat s novějšími verzemi Androidu, nebo dokonce pouze se skladovými AOSP. Aby to vývojáři překonali, používají to, čemu se říká „shim“, ale proces je složitý, časově náročný a někdy je velmi obtížné jej odladit.
V tomto článku nastíníme, jak fungují podložky, zejména s ohledem na správné fungování fotoaparátu na ROM založených na AOSP. Jako příklad použijeme OnePlus 3T. Všimněte si, že obtížnost zprovoznění těchto funkcí je velmi specifická pro zařízení.
OnePlus 3T běžící OxygenOS. Přestože jsou telefony OnePlus známé svou vstřícností k vlastnímu vývoji, existuje spousta práce, kterou vývojáři dělají v zákulisí, aby vytvořili stabilní porty AOSP.
Co je to shim nebo BLOB?
Abychom vůbec začali chápat část toho, co vývojáři dělají, musíme nejprve vysvětlit několik věcí. Ačkoli je operační systém Android open source (z nějakého důvodu se mu říká Android Open Source Project), software (bez jádra) dodávaný na tisících zařízení Android není. Vývojáři nemají přístup ke zdrojovému kódu Zkušenosti Samsung, EMUI, OxygenOSnebo jakékoli jiné varianty Androidu třetích stran.
Nyní se vývojáři, kteří přenášejí skladové AOSP na zařízení jiného výrobce, pravděpodobně nestarají o zdrojový kód těchto vzhledů pro Android, protože nebudou upravovat a budovat tyto ROM. To by byla pravda, nebýt jednoho velkého, velkého důvodu: hlavně dílů nezbytných pro správné fungování fotoaparátu a kamera HAL (Hardware Abstraction Layer), jsou také uzavřený zdroj.
Problém s uzavřeným zdrojem nejen pro HAL kamery, ale také s ROM je, že vývojáři pracující na portování AOSP na jejich zařízení budou pracující nevidomý. OEM ROM s uzavřeným zdrojovým kódem se dokáže dobře propojit s HAL kamery, protože OEM má přístup ke zdroji HAL kamery. HAL kamery je to, co umožňuje ROM „mluvit“ s hardwarem kamery – bez ní by kamera byla nefunkční. Představte si kameru HAL jako volant a pedály auta. Volant/pedály umožňují ovládání vnitřních součástí vozidla poskytováním externího rozhraní pro řidiče (ROM), aby mohl využívat vnitřní součásti.
Jak se hardware fotoaparátu stává stále složitějším ( nástup duálních fotoaparátůnapříklad), mít přístup ke zdroji HAL kamery by učinilo portování AOSP ROM s funkční kamerou mnohem jednodušší.
Výrobci OEM však z různých důvodů neposkytují přístup ke zdroji HAL fotoaparátu. Za prvé, pokud nemají všechna vlastnická práva k HAL fotoaparátu (např. když začleňují duševní vlastnictví od jiných společností), nemohou zdroj šířit. Za druhé, uvolnění zdroje HAL kamery může ohrozit jejich vlastní duševní vlastnictví. A konečně, společnosti nemají žádnou zákonnou povinnost poskytovat tento zdrojový kód (na rozdíl od zdrojového kódu jádra, kterým jsou povinna uvolnit pod GPL), nemají tedy žádnou motivaci je uvolnit. Takže bez přístupu ke zdroji HAL kamery, jak přesně vývojáři zajistí, aby kamera fungovala na AOSP ROM? Odpověď je BLOB, shim a spousta a spousta ladění.
Zařízení KAPKA (Binary Large OBject) obsahuje předem zabalené binární soubory, které jsou zkompilovanou formou softwaru. V tomto případě je zdroj HAL kamery zkompilován výrobcem OEM a dodáván na zařízení jako binární soubory. Když vývojáři mluví o BLOBech, odkazují na ty binární soubory, které se dodávají na živých zařízeních, která jsou schopni extrahovat. Nyní má téma „kamerové BLOBy“. dlouho sužoval OnePlus po mnoho měsíců, ale pravdou je, že vývojáři vždy měli přístup k objektům BLOB fotoaparátu. The Zdrojový kód kamery HAL je zlatým lístkem pro vývojáře zde, ale to bude nikdy, nikdy nebude propuštěn kvůli právnímu ohrožení by to vložilo společnosti jako OnePlus.
Vývojáři, kteří chtějí zavést AOSP do zařízení, tak zůstávají pouze s objekty BLOB kamery HAL, pro které nemají přístup ke zdrojovému kódu. Zřídka, pokud vůbec, může vývojář spárovat svůj AOSP ROM kód s kamerou HAL BLOB a očekávat, že bude fungovat, takže za účelem překlenutí propasti mezi těmito dvěma vývojáři vytvoří tzv.shim.”
„Přehodit“ znamená „zaklínovat (něco) nebo vyplnit prostor“. To je efektivně to, co vývojář dělá, když psaní shim – přidávají kód, který umožní BLOB propojit se zdrojovým kódem AOSP, na kterém pracují s. Podložky se používají k tomu, aby BLOBy všech různých druhů fungovaly s AOSP, ale obvykle je to BLOB fotoaparátu, který vyžaduje nejvíce podložek. Jak jsme již zmínili, shimming je vyžadován nejen pro portování novějších verzí Androidu na zařízení (např všechny tyto neoficiální ROM Android Oreo), ale také potřebné při portování AOSP stejné verze Androidu přístroj.
Doporučená četba: Z obchodu do regálu: Důkladná kapitulace toho, proč jsou zařízení MSM8974 vyloučena z Nougatu
Své se dočkal například OnePlus 2 poslední oficiální velká aktualizace OS v podobě Androidu 6.0 Marshmallow. Zařízení však ve skutečnosti má plně funkční vlastní ROM založené na AOSP založené na Androidu Nougat, a to díky tvrdé práci vývojářů a jejich shimů. Budeme rozebírat některé příklady podložek, ale nejprve si musíme promluvit o tom, jak přesně podložky fungují.
Jak shimming funguje?
Protože vývojáři nemají přístup ke zdroji HAL kamery nebo OEM ROM (a pouze k předkompilovaným binárním souborům), nemohou vědět, jaké funkce kamera HAL očekává. Z tohoto důvodu často dochází k nesouladu mezi názvem funkce, kterou kamera HAL hledá, a skutečným názvem funkce v kódu AOSP, se kterým vývojář pracuje.
K vyřešení tohoto problému vývojář jednoduše vytvoří novou funkci, která používá stejný název funkce, kterou kamera HAL BLOB očekává, ale tato nová funkce pouze provádí to, co vývojář chce to do. Tato nová funkce, která funguje jako prostředník mezi BLOB a AOSP, je podložka. Tento konkrétní scénář, kdy BLOB nedokáže najít funkci, kterou hledá, je jedním z nejběžnějších scénářů, kdy je potřeba podložka.
Možná budou věci dávat trochu větší smysl s hypotetickým příkladem zahrnujícím OnePlus 3T. Vytvoříme příklad pomocí OxygenOS a fotoaparátu OnePlus. Pokud použijeme objekty BLOB fotoaparátu převzaté z OxygenOS Nougat pro OnePlus 3T k vytvoření ROM Nougat založené na AOSP, můžeme narazit na problémy. Je to proto, že objekty BLOB fotoaparátu (které byly původně zkompilovány výrobcem OEM) budou schopny odkazovat na všechny funkce, které potřebuje v rámci OxygenOS, ale protože zkompilovaná AOSP ROM nemusí mít tyto funkce nebo je mohla zkompilovat pod jiným názvem (což vede k neshodě mezi funkčními symboly), bude existovat chyba. To lze opravit vytvořením nové funkce v AOSP ROM s názvem, který BLOB očekává – náš shim.
Symboly v kontextu programování se používají k odkazování na konkrétní funkce v kódu. Symboly jsou nezbytné, protože pozice funkce se může změnit, když je kód upravován, a proto, aby se zabránilo natvrdo kódování odkazy na funkce, kompilátor vytvoří tabulku symbolů, pomocí kterých mohou ostatní funkce odkazovat vždy vpravo funkce. Když před kompilací změníte název funkce, změní se i její symbol, takže se změní v podstatě jakékoli který výrobce OEM vytvoří se zdrojem HAL fotoaparátu před kompilací, bude vyžadovat, aby vývojáři vytvořili nový shim.
Vysvětlení, které jsme doposud nabídli, zní, jako by vytváření podložek bylo snadné. Změnit pár názvů funkcí tu a tam nezní příliš těžce, že? Kdyby to bylo tak snadné. Realita shims zahrnuje více než jen přejmenování funkcí. Mluvili jsme s XDA Recognized Developer Sultanxda, který nám byl schopen poskytnout příklad jednoho z obtížnějších shimů, na kterých pracoval.
Shimming - Není to tak snadné, jak to zní
Pro ty, kteří neznají OnePlus 3T, byla přední kamera zpočátku spíše rozbitá Vlastní ROM na bázi AOSP. Za prvé, pokus o pořízení jakéhokoli obrázku přes 8 MP by měl za následek shazovat. Ve svém pokusu vyřešit tento problém, Sultanxda udělal několik podložky aby přední kamera OnePlus 3T fungovala správně.
Shim #1 - Změna názvu balíčku fotoaparátu
Aby se zabránilo pádu předního fotoaparátu, kdykoli uživatel pořídil snímek s rozlišením přes 8 MP, Sultanxda přinutil HAL fotoaparátu identifikovat všechny fotoaparáty jako fotoaparát OnePlus. Je tomu tak proto, že OnePlus se rozhodl věnovat pomocnou funkci určitým aplikacím (isOnePlusCamera, isFacebookCameraatd.) z nějakého důvodu. Sultanxda to vyřešil posunutím HAL kamery, takže ukazuje na novou funkci, která vždy vrátí „true“, jako by uživatel používal kameru OnePlus – i když ji nepoužívají.
Podložka č. 2 – Zakázat QuadraCfa
Pro svůj další shim musel deaktivovat QuadraCfa, což je pravděpodobně proprietární technologie Qualcomm související s fotoaparátem. Říkáme pravděpodobně proto, že ani já, ani Sultanxda si nejsou přesně jisti, co je QuadraCfa, ale Sultanxda ví, že rozbil přední kameru, kdykoli byla povolena.
Všiml si, že QuadraCfa se nějak aktivuje, ale nebyl si jistý, proč nebo jak to dělá. Řešení si z jeho strany vyžádalo poměrně netradiční úpravu. V konvenční vložce poskytuje funkce shim při kompilaci chybějící symbol, který BLOB hledá. V tomto případě BLOB již měl symboly, které potřeboval – ty, které pravděpodobně reprezentovaly funkce, které spouštěly QuadraCfa.
Potřeboval tedy přepsat symboly používané kamerou HAL a v podstatě je nechat „chybět“, takže jeho vložky by poskytly tyto „chybějící“ symboly. Jediný způsob, jak to udělat, je přes hex editace HAL samotné kamery. Hexadecimální editace je v podstatě prohlížením hromady neuspořádaného nesmyslu ve formě binárních dat, abyste našli jehlu v kupce sena – buď funkci, nebo řetězec, který chcete upravit.
Hexadecimální editace funkce je podstatně obtížnější než hex editace řetězce, ale naštěstí se Sultanxda dokázal vyhnout nutnosti hexeditární editace funkcí za QuadraCfa tím, hex editace názvů symbolů, aby tyto symboly byly zrušeny.
Shim #3 - Bright Light Crash Fix
Dále Sultanxda zjistil, že pořízení snímku z přední kamery za jasných světelných podmínek by způsobilo zhroucení fotoaparátu. Aby Sultanxda reprodukoval tuto chybu na svém vlastním zařízení zapnul funkci baterky svého OnePlus One a posvítil si před přední kameru OnePlus 3T aby to havarovalo a produkovalo použitelné protokoly! Jakmile zjistil, jaká funkce způsobuje havárii, vytvořil podložku, aby zařízení přinutilo neustále používat režim slabého osvětlení pro přední kameru.
Podložka č. 4 – obrázky z přední kamery s nízkým rozlišením
Poté, co Sultanxda opravila havárii v jasném světle pomocí předchozí podložky, objevila další chybu, která ve skutečnosti vznikla jako přímý důsledek této podložky: snímky přední kamery s nízkým rozlišením. Namísto fotografování v rozlišení požadovaném uživatelem (např. 16MP), výsledný snímek bude pořízen v rozlišení 4MP.
Vyřešení tohoto vyžadovalo podložení funkcí handleSuperResolution a isSuperResolution vždy vrátit true, ale POUZE když je aktivní přední fotoaparát (protože jinak by fotoaparát při pořizování snímků ze zadního snímače havaroval).
Poučení – Shimming může být těžké
Sultanxda připouští, že podložky, které musel vytvořit, aby přední kamera OnePlus 3T fungovala, nepředstavují váš typický příklad podložky. Je na svou podložku poměrně hrdý vzhledem k její složitosti a vzácné nutnosti upravovat samotný BLOB hexem. Ale tento příklad jen ukazuje, jak obtížné může být zprovoznění hardwaru fotoaparátu na určitých zařízeních.
Kéž jsou vaše dobrodružství s fotoaparátem méně bolestivá než moje. -Sultanxda
Protokoly, protokoly a další protokoly. Bez konzistentního způsobu reprodukce selhání a bez protokolů mají vývojáři malou naději na nalezení zdroje problému. I když zjistí, co problém způsobuje, není to vždy jednoduché řešení. Celý proces hledání a odstraňování těchto chyb může trvat dny nebo týdny a je důvodem, proč je oprava fotoaparátu na AOSP ROM jedním z nejobtížnějších úkolů.
Pokud má vaše zařízení portovanou AOSP ROM s plně funkčním hardwarem, doufejme, že můžete začít oceňte boj, kterým tito vývojáři mohli projít, aby vám je přinesli funkce. Oceňujte je za jejich práci, protože to není snadné. Je to spousta práce, které si drtivá většina uživatelů ani nevšimne, protože talentovaní vývojáři na našich fórech se starají o mnoho neokoukaných částí Androidu.
Rádi bychom zvláště poděkovali Sultanxdovi za mnoho příspěvků, které navrhl při tvorbě tohoto článku.