Wie bekommen Entwickler ohne Quellcode Hardwarekomponenten wie Kameras in benutzerdefinierten ROMs zum Laufen? Die Antwort ist ein BLOB, ein Shim und jede Menge Debugging.
Mit der Veröffentlichung von Android Oreo und vielen Geräten wie dem Xiaomi Redmi Note 3, Google Nexus 5 Und andere erhalten es inoffiziell, ist es wahrscheinlich berechtigt, sich zu fragen, warum dieselben Funktionen (hauptsächlich die Kamera) dazu neigen, kaputt zu gehen, wenn Entwickler ein auf Android Open Source Project (AOSP) basierendes ROM portieren. Sie haben wahrscheinlich XDA-Forenthreads von ROMs mit einer langen Liste defekter Funktionen oben gesehen. „Was funktioniert?“, gefolgt von einer Liste der funktionierenden Funktionen, und darunter das ikonische „Was funktioniert nicht?“. Du sagst es mir!" sind zwei beliebte Refrains in unseren Foren, die auf Reddit und Twitter praktisch zu einem Meme geworden sind.
Warum gehen so viele Funktionen verloren, wenn ein Entwickler versucht, ein AOSP-ROM auf sein Gerät zu portieren? Die grundlegende Antwort lautet: Da sich die Funktionen zwischen verschiedenen Android-Versionen ändern, funktionieren alte, als BLOBs verpackte Gerätetreiber nicht mit neueren Android-Versionen oder auch nur mit Standard-AOSP. Um dies zu überwinden, verwenden Entwickler einen sogenannten „Shim“, aber der damit verbundene Prozess ist knifflig, zeitintensiv und manchmal sehr schwer zu debuggen.
In diesem Artikel beschreiben wir die Funktionsweise von Shims, insbesondere im Hinblick darauf, dass die Kamera auf AOSP-basierten ROMs ordnungsgemäß funktioniert. Als Beispiel nehmen wir das OnePlus 3T. Beachten Sie, dass die Schwierigkeit, diese Funktionen zum Laufen zu bringen, stark gerätespezifisch ist.
OnePlus 3T mit OxygenOS. Obwohl OnePlus-Telefone für ihre Benutzerfreundlichkeit bei der benutzerdefinierten Entwicklung bekannt sind, leisten Entwickler hinter den Kulissen viel Arbeit, um stabile AOSP-Portierungen zu erstellen.
Was ist ein Shim oder ein BLOB?
Um überhaupt einen Teil dessen zu verstehen, was Entwickler tun, müssen wir zunächst einige Dinge erklären. Obwohl das Android-Betriebssystem Open Source ist (es wird aus einem bestimmten Grund Android Open Source Project genannt), ist dies bei der Software (ohne Kernel), die auf Tausenden von Android-Geräten ausgeliefert wird, nicht der Fall. Entwickler haben keinen Zugriff auf den Quellcode von Samsung-Erlebnis, EMUI, OxygenOSoder eine der anderen Android-Varianten von Drittanbietern.
Entwickler, die Standard-AOSP auf ein Nicht-Google-Gerät portieren, kümmern sich wahrscheinlich nicht um den Quellcode dieser Android-Skins, da dies auch nicht der Fall sein wird Modifizieren und Erstellen dieser ROMs. Das wäre wahr, wenn es nicht einen großen, großen Grund gäbe: vor allem die Teile, die notwendig sind, damit die Kamera richtig funktioniert Die Kamera HAL (Hardware-Abstraktionsschicht) sind auch Closed Source.
Das Problem, wenn nicht nur das Kamera-HAL, sondern auch das ROM Closed Source vorhanden ist, besteht darin, dass Entwickler daran arbeiten, AOSP auf ihr Gerät zu portieren blind arbeiten. Das Closed-Source-OEM-ROM kann problemlos mit dem Kamera-HAL kommunizieren, da der OEM Zugriff auf die HAL-Quelle der Kamera hat. Der Kamera-HAL ermöglicht es dem ROM, mit der Kamera-Hardware zu „kommunizieren“ – ohne ihn wäre die Kamera nicht funktionsfähig. Stellen Sie sich die Kamera-HAL als Lenkrad und Pedale des Autos vor. Das Lenkrad/die Pedale ermöglichen die Steuerung der internen Komponenten des Fahrzeugs, indem sie dem Fahrer eine externe Schnittstelle (das ROM) zur Nutzung der internen Komponenten bieten.
Da die Kamera-Hardware immer komplexer wird (die Aufkommen von Dual-Kameras, zum Beispiel), würde der Zugriff auf die HAL-Quelle der Kamera die Portierung eines AOSP-ROMs mit einer funktionierenden Kamera viel einfacher machen.
Aus verschiedenen Gründen gewähren OEMs jedoch keinen Zugriff auf die HAL-Quelle der Kamera. Erstens: Wenn sie nicht alle Eigentumsrechte an der Kamera-HAL besitzen (z. B. wenn sie geistiges Eigentum anderer Unternehmen übernehmen), können sie die Quelle nicht verbreiten. Zweitens kann die Freigabe der HAL-Quelle der Kamera ihr eigenes geistiges Eigentum gefährden. Schließlich sind Unternehmen nicht gesetzlich verpflichtet, diesen Quellcode bereitzustellen (im Gegensatz zum Kernel-Quellcode, der sie sind). zur Veröffentlichung unter der GPL verpflichtet), sodass sie keinen Anreiz haben, es freizugeben. Wie genau bringen Entwickler die Kamera ohne Zugriff auf die HAL-Quelle der Kamera auf AOSP-ROMs zum Laufen? Die Antwort ist ein BLOB, ein Shim und jede Menge Debugging.
Ein Gerät KLECKS (Binary Large OBject) enthält vorgefertigte Binärdateien, die die kompilierte Form von Software darstellen. In diesem Fall wird die HAL-Quelle der Kamera vom OEM kompiliert und als Binärdateien auf die Geräte geliefert. Wenn Entwickler von BLOBs sprechen, beziehen sie sich auf die Binärdateien, die auf Live-Geräten ausgeliefert werden und die sie extrahieren können. Nun ist das Thema „Kamera-BLOBs“ angesagt lange geplagt OnePlus seit vielen Monaten, aber die Wahrheit ist, dass Entwickler immer Zugriff auf die Kamera-BLOBs hatten. Der Der HAL-Quellcode der Kamera ist das goldene Ticket für Entwickler hier zwar, aber das wird niemals veröffentlicht werden aufgrund der rechtlichen Gefahr, die dadurch Unternehmen wie OnePlus entstehen würde.
Daher bleiben Entwicklern, die AOSP auf ein Gerät bringen möchten, nur BLOBs des Kamera-HALs, für die sie keinen Zugriff auf den Quellcode haben. Selten, wenn überhaupt, kann ein Entwickler seinen AOSP-ROM-Code mit dem Kamera-HAL-BLOB koppeln und erwarten, dass er funktioniert. Um die Lücke zwischen den beiden zu schließen, erstellen Entwickler daher etwas, das als „Unterlegscheibe.”
Unter „shim“ versteht man „etwas verkeilen oder einen Raum ausfüllen“. Dies ist im Grunde das, was ein Entwickler tut, wenn Schreiben eines Shims – sie fügen Code hinzu, um dem BLOB die Verbindung mit dem AOSP-Quellcode zu ermöglichen, an dem sie arbeiten mit. Shims werden verwendet, damit BLOBs aller Art mit AOSP funktionieren, aber normalerweise ist es das Kamera-BLOB, das den meisten Shim erfordert. Wie bereits erwähnt, ist Shimming nicht nur für die Portierung neuerer Android-Versionen auf ein Gerät (z. B alle diese inoffiziellen Android-Oreo-ROMs), werden aber auch benötigt, wenn AOSP derselben Android-Version darauf portiert wird Gerät.
Literatur-Empfehlungen: Vom Laden ins Regal: Eine ausführliche Kapitulation darüber, warum MSM8974-Geräte von Nougat ausgeschlossen sind
Das OnePlus 2 beispielsweise erhielt seine letztes offizielles großes Betriebssystem-Update in Form von Android 6.0 Marshmallow. Das Gerät hat es jedoch tatsächlich voll funktionsfähige benutzerdefinierte AOSP-basierte ROMs basiert auf Android Nougat, und das ist der harten Arbeit der Entwickler und ihrer Shims zu verdanken. Wir werden einige Beispiele für Unterlegscheiben aufschlüsseln, aber zuerst müssen wir darüber sprechen, wie genau Unterlegscheiben funktionieren.
Wie funktioniert Shimming?
Da Entwickler keinen Zugriff auf die Kamera-HAL- oder OEM-ROM-Quelle haben (und nur auf die vorkompilierten Binärdateien), können sie nicht wissen, welche Funktionen die Kamera-HAL erwartet. Aus diesem Grund gibt es oft eine Diskrepanz zwischen dem Namen der Funktion, nach der die Kamera-HAL sucht, und dem tatsächlichen Namen der Funktion im AOSP-Code, mit dem der Entwickler arbeitet.
Um dieses Problem zu lösen, erstellt der Entwickler einfach eine neue Funktion, die denselben Namen verwendet Funktion, die das Kamera-HAL-BLOB erwartet, aber diese neue Funktion führt nur das aus, was der Entwickler will es zu. Diese neue Funktion, die als Vermittler zwischen BLOB und AOSP fungiert, ist der Shim. Dieses spezielle Szenario, in dem das BLOB die gesuchte Funktion nicht findet, ist eines der häufigsten, bei dem ein Shim benötigt wird.
Vielleicht ergibt ein hypothetisches Beispiel mit dem OnePlus 3T etwas mehr Sinn. Wir erstellen ein Beispiel mit OxygenOS und der OnePlus-Kamera. Wenn wir Kamera-BLOBs aus OxygenOS Nougat für das OnePlus 3T verwenden, um ein AOSP-basiertes Nougat-ROM zu erstellen, können Probleme auftreten. Dies liegt daran, dass die Kamera-BLOBs (die ursprünglich vom OEM kompiliert wurden) in OxygenOS auf alle benötigten Funktionen verweisen können Wenn ein kompiliertes AOSP-ROM diese Funktionen möglicherweise nicht hat oder sie unter einem anderen Namen kompiliert hat (was zu einer Nichtübereinstimmung zwischen Funktionssymbolen führt), wird es eine geben Fehler. Dies kann behoben werden, indem im AOSP-ROM eine neue Funktion mit dem Namen erstellt wird, den das BLOB erwartet – unser Shim.
Symbole werden in einem Programmierkontext verwendet, um auf bestimmte Funktionen im Code zu verweisen. Symbole sind notwendig, da sich die Position einer Funktion ändern kann, wenn der Code bearbeitet wird, und so eine harte Codierung vermeiden Bei Verweisen auf Funktionen erstellt der Compiler eine Tabelle mit Symbolen, die andere Funktionen verwenden können, um immer auf die rechte Seite zu verweisen Funktion. Wenn Sie den Namen einer Funktion vor dem Kompilieren ändern, ändert sich auch ihr Symbol, also grundsätzlich alle Änderungen Da der OEM die HAL-Quelle der Kamera vor der Kompilierung erstellt, müssen Entwickler eine neue erstellen Unterlegscheibe.
Die Erklärung, die wir bisher gegeben haben, lässt den Eindruck entstehen, dass die Herstellung von Unterlegscheiben einfach ist. Hier und da ein paar Funktionsnamen zu ändern, klingt doch nicht allzu schwierig, oder? Wenn es nur so einfach wäre. Die Realität von Shims umfasst mehr als nur Funktionsumbenennungen. Wir haben mit dem von XDA anerkannten Entwickler Sultanxda gesprochen, der uns ein Beispiel für einen der schwierigeren Shims liefern konnte, an denen er gearbeitet hat.
Shimmen – nicht so einfach, wie es sich anhört
Für diejenigen, die mit dem OnePlus 3T nicht vertraut sind: Die Frontkamera war anfangs ziemlich kaputt AOSP-basierte benutzerdefinierte ROMs. Zunächst einmal würde der Versuch, ein Bild mit mehr als 8 MP aufzunehmen, zu einem Ergebnis führen stürzt ab. Bei seinem Versuch, dieses Problem zu lösen, unternahm Sultanxda mehrere Unterlegscheiben damit die Frontkamera des OnePlus 3T ordnungsgemäß funktioniert.
Unterlage Nr. 1 – Ändern des Kamerapaketnamens
Um zu verhindern, dass die Frontkamera abstürzt, wenn der Benutzer ein Bild mit mehr als 8 MP aufnimmt, hat Sultanxda die Kamera-HAL gezwungen, alle Kameras als OnePlus-Kamera zu identifizieren. Dies geschieht, weil OnePlus beschlossen hat, bestimmten Anwendungen eine Hilfsfunktion zuzuweisen (isOnePlusCamera, isFacebookCamerausw.) aus irgendeinem Grund. Sultanxda hat dieses Problem behoben, indem es den Kamera-HAL angepasst hat, sodass er auf eine neue Funktion verweist, die immer „true“ zurückgibt, als ob der Benutzer die OnePlus-Kamera verwendet – auch wenn dies nicht der Fall ist.
Shim Nr. 2 – QuadraCfa deaktivieren
Für seinen nächsten Shim musste er QuadraCfa deaktivieren, bei dem es sich vermutlich um eine proprietäre Qualcomm-Technologie für die Kamera handelt. Wir sagen vermutlich, weil weder ich noch Sultanxda genau wissen, was QuadraCfa ist, aber Sultanxda weiß, dass es die nach vorne gerichtete Kamera kaputt gemacht hat, wann immer sie aktiviert wurde.
Er beobachtete, dass sich QuadraCfa irgendwie selbst aktivierte, war sich jedoch nicht sicher, warum oder wie dies geschah. Die Lösung dieses Problems erforderte eine eher unkonventionelle Modifikation seinerseits. Bei einem herkömmlichen Shim stellt die Shim-Funktion beim Kompilieren das fehlende Symbol bereit, nach dem das BLOB sucht. In diesem Fall verfügte das BLOB bereits über die benötigten Symbole – diejenigen, die vermutlich die Funktionen darstellten, die QuadraCfa starteten.
Daher musste er die von der Kamera-HAL verwendeten Symbole überschreiben und sie im Wesentlichen „fehlend“ machen sein Unterlegscheiben würden diese „fehlenden“ Symbole liefern. Der einzige Weg, dies zu tun, ist über Hex-Bearbeitung der Kamera-HAL selbst. Bei der Hex-Bearbeitung geht es im Grunde darum, einen Haufen unorganisierten Kauderwelschs in Form von Binärdaten zu durchsuchen, um die Nadel im Heuhaufen zu finden – entweder eine Funktion oder einen String, den Sie bearbeiten möchten.
Die Hex-Bearbeitung einer Funktion ist wesentlich schwieriger als die Hex-Bearbeitung einer Zeichenfolge, aber glücklicherweise konnte Sultanxda stattdessen die Hex-Bearbeitung der Funktionen hinter QuadraCfa vermeiden Hex-Bearbeitung der Symbolnamen, um diese Symbole ungültig zu machen.
Unterlegscheibe Nr. 3 – Crash-Fix bei hellem Licht
Als nächstes stellte Sultanxda fest, dass das Aufnehmen eines Bildes mit der Frontkamera bei hellen Lichtverhältnissen zum Absturz der Kamera führen würde. Um diesen Fehler auf seinem eigenen Gerät zu reproduzieren, hat Sultanxda tatsächlich schaltete die Taschenlampenfunktion seines OnePlus One ein und richtete das Licht vor die Frontkamera des OnePlus 3T um es zum Absturz zu bringen und brauchbare Protokolle zu erstellen! Nachdem er herausgefunden hatte, welche Funktion den Absturz verursachte, erstellte er eine Unterlage, um das Gerät zu zwingen, für die Frontkamera ständig den Schwachlichtmodus zu verwenden.
Unterlage Nr. 4 – Bilder der Frontkamera mit niedriger Auflösung
Nachdem Sultanxda den Absturz bei hellem Licht mit dem vorherigen Shim behoben hatte, entdeckte er einen weiteren Fehler, der tatsächlich als direkte Folge dieses Shims auftrat: Bilder der nach vorne gerichteten Kamera mit niedriger Auflösung. Anstatt Bilder mit der vom Benutzer gewünschten Auflösung aufzunehmen (z. B. 16MP), würde das resultierende Bild mit 4MP aufgenommen.
Um dieses Problem zu lösen, musste er die Funktionen anpassen handleSuperResolution Und isSuperResolution um immer „true“ zurückzugeben, aber NUR, wenn die nach vorne gerichtete Kamera aktiv ist (da sonst die Kamera abstürzen würde, wenn Bilder vom hinteren Sensor aufgenommen werden).
Lektion gelernt – Shimming kann schwierig sein
Sultanxda gibt zu, dass die Unterlegscheiben, die er herstellen musste, um die Frontkamera des OnePlus 3T zum Laufen zu bringen, kein typisches Beispiel für eine Unterlegscheibe sind. Angesichts seiner Komplexität und der seltenen Notwendigkeit, das BLOB selbst zu verhexen, ist er ziemlich stolz auf sein Shim. Aber dieses Beispiel zeigt nur, wie schwierig es sein kann, die Kamera-Hardware auf bestimmten Geräten zum Laufen zu bringen.
Mögen Ihre Kamera-Shim-Abenteuer weniger schmerzhaft sein als meine. -Sultanxda
Protokolle, Protokolle und noch mehr Protokolle. Ohne eine konsistente Möglichkeit, einen Absturz zu reproduzieren, und ohne Protokolle haben Entwickler kaum Hoffnung, die Ursache des Problems zu finden. Selbst wenn sie die Ursache des Problems finden, ist es nicht immer eine einfache Lösung. Der gesamte Prozess, diese Fehler zu finden und zu beheben, kann Tage oder Wochen dauern und ist der Grund, warum das Reparieren der Kamera auf AOSP-ROMs eine der schwierigeren Aufgaben ist.
Wenn auf Ihrem Gerät ein AOSP-ROM mit voll funktionsfähiger Hardware portiert ist, können Sie hoffentlich damit beginnen Schätzen Sie den Kampf, den diese Entwickler möglicherweise auf sich genommen haben, um Ihnen diese zu bieten Merkmale. Schätzen Sie sie für ihre Arbeit, denn es ist nicht einfach. Es ist eine Menge Arbeit, die die überwiegende Mehrheit der Benutzer nicht einmal bemerken wird, da sich talentierte Entwickler in unseren Foren um die vielen unsichtbaren Teile von Android kümmern.
Wir möchten Sultanxda besonders für die vielen Beiträge danken, die er bei der Erstellung dieses Artikels vorgeschlagen hat.