Kiwi++Soft
Ehrenmitglied
- 32.707
"ROM mit 'Port-Anleitung' portieren" vs. "Port auf Sourcen-Basis":
Ich bekam die Frage gestellt, ob man ein bestimmtes ROM mit einer ganz normal 'Port-Anleitung' für ein Acer A210 portieren könnte.
Natürlich kann ich diese Frage nur schwer mit Sicherheit beantworten, da ich weder genau weiß, um welche Port-Anleitung es sich handelt, noch das betreffende ROM kenne.
Daher werde ich einfach ein paar allgemeine Worte zum Thema ROM portieren schreiben.
Meine Erfahrung:
Zunächst mal muss ich zugeben, dass ich etwas voreingenommen bin gegen Port-Anleitungen, die nicht auf der Basis von Sourcen funktionieren. Dies liegt daran, dass ich bei meinem ersten Versuch CM 10 (nicht das aktuelle CM 10.1) mit dem Versuch des Portierens vom Acer A700 auf das Acer A210 nur wenig Erfolg hatte. Viele Hardware-Komponenten konnten auf dieser Basis nicht unterstützt werden. Nach einigen Wochen Arbeit habe ich das Projekt eingestellt.
Nach einiger Zeit habe ich dann einen Port von CM 10.1 auf der Basis von Sourcen begonnen, was dazu führte, dass ich nach wenigen Tagen bereits deutlich weiter war, als bei dem ersten Versuch nach vielen Wochen.
Um objektiv zu bleiben, muss ich allerdings zugeben, dass sich aus dieser einen Erfahrung keine prinzipielle Regel ableiten lässt. Aber ich kann ja mal die Probleme, die ich sehe auflisten.
Mögliche Probleme:
Die Menge der möglichen Probleme wird umso größer, je unterschiedlich die Geräte (Quell-Gerät = Gerät von dem das ROM stammt und Ziel-Gerät = Gerät auf das das ROM portiert werden soll) sind.
Kernel:
Wenn das Quell- und Ziel-Gerät unterschiedliche Prozessoren haben, dürfte es ohne jede Diskussion klar sein, dass der Kernel des Quell-Gerätes nicht verwendet werden kann. Es reichen aber auch schon Unterschiede in den Hardware-Komponenten, wie beispielsweise unterschiedliche Touch-Displays, so dass nicht anzunehmen wäre, dass im Quell-Gerät Kernel ein geeigneter Treiber für das Zielgerät mit drin ist.
Wenn man jetzt jedoch einen Kernel vom Ziel-Gerät verwenden will, so ist auch wiederum mit Problemen zu rechnen. Auf der einen Seite kann es sein, dass das zu portierende ROM bestimmte Module im Kernel erwartet, die im Stock-Kernel des Zielgerätes nicht mit eingebunden sind, andererseits können auch schon Unterschiede im init-Script des Stock-Kernels des Ziel-Gerätes und dem Custom-Kernel für das zu portierende ROM alle Erfolgsaussichten zunichte machen. Ein gutes Beispiel hierfür ist die Tatsache, dass der 'normale Kiwi++Kernel' für Android 4.1.1 nicht für das CM10.1 oder das AOKP verwendet werden kann, obgleich der Kiwi++Kernel für CM10.1/AOKP aus dem selben Source-Code erstellt wird.
Liste der Device abhängigen Files:
Das nächste Problem sind die sogenannten 'Device abhängigen Files'. Das sind Konfigurations-Dateien, Firmware-Binaries und ähnliches. Keine 'generische Anleitung' zum Portieren kann eine vollständige Liste der 'Device abhängigen Files' lieferen, denn diese unterscheiden sich sowohl in Menge als auch in Namen und im Speicher-Ort. Selbst bei relativ ähnlichen Geräten wie dem A700 und dem A210 gibt es zahlreiche Unterschiede in der Liste der 'Device abhängigen Files'.
Konfigurations-Dateien:
Leider kommt hier auch nicht damit über die Runde, hier einfach die Bezeichnung des Gerätes anzupassen, und schon ist alles gut. Man muss teilweise sehr genau untersuchen, wie in dem Zielgerät der eine oder der andere Treiber heißt, welche 'Device-Node' vom Kernel des Zielgerätes angelegt wird und unter welchem Pfad diese zu finden ist. Auch kann es sein, dass das Zielgerät eine Konfigurations-Datei benötigt, die das Quell-Gerät und das Stock-ROM des Zielgerätes beide nicht benötigen. Dies ist dann der Fall, wenn das Quell-Gerät eine andere Hardware als das Ziel-Gerät hat, aber das Stock-ROM mit einer anderen Bibliothek auf die Hardware zugreift, als die das zu portierende ROM.
Hardware Abstraction Libraries:
Das schwerste Thema sind die Hardware Abstraction Libraries. Diese bilden das Interface zwischen der Hardware des Zielgerätes und dem Android-System. Bei den kann der gleiche Effekt wie bei den Konfigurations-Dateien auftreten, dass wegen Unterschieden in der Hardware die Library des Quell-Systems nicht verwendet werden kann, aber wegen Unterschieden in der Art des Zugriffs die Library des Stock-ROMs ebenso nicht für das portierte ROM geeignet ist.
Das Fehlen des Source-Codes:
Durch das Fehlen des Source-Codes hat man gleich zwei Probleme zu bewältigen:
Was ist die Botschaft dieses Textes:
Ich will es nicht für von vornherein für sinnlos deklarieren, nach einer Port-Anleitung eine Portierung zu versuchen, jedoch gebe ich folgendes zu bedenken:
Die Schwierigkeiten erhöhen sich mit jeden der folgenden Punkte, die zwischen Quell-Gerät und Ziel-Gerät liegen:
Und wenn sogar nach dem ersten Portieren das Gerät startet, aber die eine oder andere Hardware-Komponente nicht läuft, hat man auf dieser Basis wenig Chancen, die letzten Probleme auszumerzen, um zu einem 'sauberen ROM zu kommen.
Daher würde ich immer den Weg empfehlen, sich einmal die Mühe zu machen, eine Build-Umgebung aufzusetzen und eine Portierung auf Basis der Sourcen zu machen. So unendlich schwer ist das nicht, siehe hier: https://www.android-hilfe.de/forum/...en-sourcen-aosp-cm-aokp-aospa-usw.443795.html
Ich hoffe, mit diesem Text weiter geholfen zu haben und stehe für Fragen gerne zur Verfügung.
Grüsse Uwe
Ich bekam die Frage gestellt, ob man ein bestimmtes ROM mit einer ganz normal 'Port-Anleitung' für ein Acer A210 portieren könnte.
Natürlich kann ich diese Frage nur schwer mit Sicherheit beantworten, da ich weder genau weiß, um welche Port-Anleitung es sich handelt, noch das betreffende ROM kenne.
Daher werde ich einfach ein paar allgemeine Worte zum Thema ROM portieren schreiben.
Meine Erfahrung:
Zunächst mal muss ich zugeben, dass ich etwas voreingenommen bin gegen Port-Anleitungen, die nicht auf der Basis von Sourcen funktionieren. Dies liegt daran, dass ich bei meinem ersten Versuch CM 10 (nicht das aktuelle CM 10.1) mit dem Versuch des Portierens vom Acer A700 auf das Acer A210 nur wenig Erfolg hatte. Viele Hardware-Komponenten konnten auf dieser Basis nicht unterstützt werden. Nach einigen Wochen Arbeit habe ich das Projekt eingestellt.
Nach einiger Zeit habe ich dann einen Port von CM 10.1 auf der Basis von Sourcen begonnen, was dazu führte, dass ich nach wenigen Tagen bereits deutlich weiter war, als bei dem ersten Versuch nach vielen Wochen.
Um objektiv zu bleiben, muss ich allerdings zugeben, dass sich aus dieser einen Erfahrung keine prinzipielle Regel ableiten lässt. Aber ich kann ja mal die Probleme, die ich sehe auflisten.
Mögliche Probleme:
Die Menge der möglichen Probleme wird umso größer, je unterschiedlich die Geräte (Quell-Gerät = Gerät von dem das ROM stammt und Ziel-Gerät = Gerät auf das das ROM portiert werden soll) sind.
Kernel:
Wenn das Quell- und Ziel-Gerät unterschiedliche Prozessoren haben, dürfte es ohne jede Diskussion klar sein, dass der Kernel des Quell-Gerätes nicht verwendet werden kann. Es reichen aber auch schon Unterschiede in den Hardware-Komponenten, wie beispielsweise unterschiedliche Touch-Displays, so dass nicht anzunehmen wäre, dass im Quell-Gerät Kernel ein geeigneter Treiber für das Zielgerät mit drin ist.
Wenn man jetzt jedoch einen Kernel vom Ziel-Gerät verwenden will, so ist auch wiederum mit Problemen zu rechnen. Auf der einen Seite kann es sein, dass das zu portierende ROM bestimmte Module im Kernel erwartet, die im Stock-Kernel des Zielgerätes nicht mit eingebunden sind, andererseits können auch schon Unterschiede im init-Script des Stock-Kernels des Ziel-Gerätes und dem Custom-Kernel für das zu portierende ROM alle Erfolgsaussichten zunichte machen. Ein gutes Beispiel hierfür ist die Tatsache, dass der 'normale Kiwi++Kernel' für Android 4.1.1 nicht für das CM10.1 oder das AOKP verwendet werden kann, obgleich der Kiwi++Kernel für CM10.1/AOKP aus dem selben Source-Code erstellt wird.
Liste der Device abhängigen Files:
Das nächste Problem sind die sogenannten 'Device abhängigen Files'. Das sind Konfigurations-Dateien, Firmware-Binaries und ähnliches. Keine 'generische Anleitung' zum Portieren kann eine vollständige Liste der 'Device abhängigen Files' lieferen, denn diese unterscheiden sich sowohl in Menge als auch in Namen und im Speicher-Ort. Selbst bei relativ ähnlichen Geräten wie dem A700 und dem A210 gibt es zahlreiche Unterschiede in der Liste der 'Device abhängigen Files'.
Konfigurations-Dateien:
Leider kommt hier auch nicht damit über die Runde, hier einfach die Bezeichnung des Gerätes anzupassen, und schon ist alles gut. Man muss teilweise sehr genau untersuchen, wie in dem Zielgerät der eine oder der andere Treiber heißt, welche 'Device-Node' vom Kernel des Zielgerätes angelegt wird und unter welchem Pfad diese zu finden ist. Auch kann es sein, dass das Zielgerät eine Konfigurations-Datei benötigt, die das Quell-Gerät und das Stock-ROM des Zielgerätes beide nicht benötigen. Dies ist dann der Fall, wenn das Quell-Gerät eine andere Hardware als das Ziel-Gerät hat, aber das Stock-ROM mit einer anderen Bibliothek auf die Hardware zugreift, als die das zu portierende ROM.
Hardware Abstraction Libraries:
Das schwerste Thema sind die Hardware Abstraction Libraries. Diese bilden das Interface zwischen der Hardware des Zielgerätes und dem Android-System. Bei den kann der gleiche Effekt wie bei den Konfigurations-Dateien auftreten, dass wegen Unterschieden in der Hardware die Library des Quell-Systems nicht verwendet werden kann, aber wegen Unterschieden in der Art des Zugriffs die Library des Stock-ROMs ebenso nicht für das portierte ROM geeignet ist.
Das Fehlen des Source-Codes:
Durch das Fehlen des Source-Codes hat man gleich zwei Probleme zu bewältigen:
- Man hat bei einem Portierungs-Problem nicht die Möglichkeit, an Hand einer Meldung im Log-File in den Source-Code zu gucken, was das Problem ausgelöst hat. Dies ist sehr oft nötig, da die Meldung im Logfile zwar sagt, an welcher Stelle etwas nicht erfolgreich war, aber man nur schlecht erahnen kann, warum dieser Schritt jetzt nicht erfolgreich war.
- Man hat keine Möglichkeit, zusätzliche Logmeldungen einzubauen, wenn man auf der Suche nach einem Problem ist, und kann somit aus den vorhandenen Logmeldungen oft nicht erschließen, was die eigentliche Ursache des Problems ist.
- Wenn man die Ursache des Problems gefunden hat, kann man keinen Fix in den vorhandenen Code einbauen, wenn man nicht die vollständige Build-Umgebung aufgesetzt hat.
- Man kann keine zusätzlichen Hardware-Abstraction-Libraries erstellen, wenn sich die Notwendigkeit einer solchen ergibt.
Was ist die Botschaft dieses Textes:
Ich will es nicht für von vornherein für sinnlos deklarieren, nach einer Port-Anleitung eine Portierung zu versuchen, jedoch gebe ich folgendes zu bedenken:
Die Schwierigkeiten erhöhen sich mit jeden der folgenden Punkte, die zwischen Quell-Gerät und Ziel-Gerät liegen:
- Unterschiedlicher Prozessor
- Unterschiedliche Hardware-Komponenten
- Unterschiedlicher Hersteller
- Unterschiedliche Android-Version
Und wenn sogar nach dem ersten Portieren das Gerät startet, aber die eine oder andere Hardware-Komponente nicht läuft, hat man auf dieser Basis wenig Chancen, die letzten Probleme auszumerzen, um zu einem 'sauberen ROM zu kommen.
Daher würde ich immer den Weg empfehlen, sich einmal die Mühe zu machen, eine Build-Umgebung aufzusetzen und eine Portierung auf Basis der Sourcen zu machen. So unendlich schwer ist das nicht, siehe hier: https://www.android-hilfe.de/forum/...en-sourcen-aosp-cm-aokp-aospa-usw.443795.html
Ich hoffe, mit diesem Text weiter geholfen zu haben und stehe für Fragen gerne zur Verfügung.
Grüsse Uwe
Zuletzt bearbeitet:
