Warum müssen wir ROMs portieren [geschlossen]

-2

Wir können Windows auf einer Reihe von Computern installieren, aber wenn man versucht, ein ROM auf einem anderen Android-Gerät zu flashen, funktioniert es nicht. Ich gehe davon aus, dass dies daran liegt, dass die Kernel- und Systemoptimierungen nur mit der spezifischen SOC-Batterie kompatibel sind. Das BIOS informiert Windows über die Funktionen verschiedener Geräte über ACPI-Tabellen und funktioniert mit einer Reihe von Hardwarekomponenten. Gibt es einen Grund, warum es auf Android-Geräten keine Hardware-Abstraktionsschicht im üblichen Sinne gibt, sind es nur die Hersteller, die davon profitieren?

acpi hal

— Lewis Kelsey
quelle

Die meisten Ihrer Annahmen sind falsch. Sie können ROM nicht "flashen". Flash-Speicher ist nicht "ROM" . Android hat HW-Abstraktionsebenen. Die Tatsache, dass Android auf einer größeren Bandbreite läuft ( Angebot nicht Anzahl) von Geräten als Windows beweist diesen Punkt. Das Problem ist, dass das Image vollständig an die Hardware angepasst ist. Während sich eine Windows-Installation im Hintergrund selbst konfiguriert und versucht, alle erforderlichen Gerätetreiber automatisch für Sie zu installieren. Deshalb müssen Sie während der Installation mit dem Internet verbunden sein.

— sawdust

google.co.uk/amp/s/lifehacker.com/… Rom ist in diesem Fall zum Synonym für ein mobiles Betriebssystem mit einem benutzerdefinierten Skin geworden

— Lewis Kelsey

Gibt es einen Grund, warum es auf Android-Geräten keine Hardware-Abstraktionsschicht im üblichen Sinne gibt?

Wirtschaftliche Gründe:

Android-Geräte sind in der Regel Einplatinen-ARM-basierte Geräte mit eingebetteter Hardware, die sich über die Lebensdauer des Geräts nicht ändern. Der Benutzer kauft normalerweise nur ein neues Gerät.
Android ist ein "eingebettetes" Betriebssystem. Von Hardware, auf der Android ausgeführt wird, wird normalerweise nicht erwartet, dass sie ein anderes Betriebssystem unterstützt oder ausführt.
ACPI ist ein komplexer Standard, der schwer zu implementieren ist.

Für Unternehmen ist Time-to-Market mehr wert als die Entwicklung von Standards, die andere Unternehmen verwenden. Windows, das Betriebssysteme verkaufen wollte, die auf verschiedenen Intel-basierten Hardwareanbietern funktionieren, bevorzugte offensichtlich den Standard (und sowohl Intel als auch Microsoft hatten einen Einfluss auf das Design von ACPI.)

Technische Gründe:

Windows ist beim Start und während des Betriebs sehr stark von der Firmware (BIOS oder UEFI) abhängig. Linux kann so konfiguriert werden, dass es sich nach dem Laden überhaupt nicht auf Firmware stützt. Für ARM-Plattformen ist dies wahrscheinlich typisch.
- Auf diese Weise können unter Linux einfachere (und weniger benutzerfreundliche) Schemata verwendet werden, z. B. Gerätebäume oder einfach im Kernel integrierte Treiber, die wissen, wo sich ihre Hardware auf der Plattform befindet, ohne dass eine Ermittlung erforderlich ist.

aber wenn man versucht, ein ROM auf einem anderen Android-Gerät zu flashen, funktioniert es nicht

Der Bootloader auf Android-Geräten ist häufig so konfiguriert, dass nur ein signiertes Image geladen wird. Wenn das Image, das das Betriebssystem enthält, nicht signiert ist, funktioniert es nicht.
Der Bootloader selbst ist häufig sehr hardwarespezifisch und für ein bestimmtes Board konzipiert. (Sie können kein BIOS für ein Modell eines Laptops verwenden und erwarten, dass es auch auf einem anderen Modell eines Laptops funktioniert. Als OEM müssten Sie ein neues BIOS für eine neue Plattform erstellen.) Wenn das ROM-Image den Bootloader enthält und Sie versuchen, ihn auf der falschen Plattform auszuführen, funktioniert er wahrscheinlich nicht.
Die Linux-Treiber für die Hardwaregeräte vieler Android-Geräte sind nicht Open Source. Umfasst Dinge wie Display, Wifi, Handy. Daher funktionieren sie mit späteren Kernelversionen nicht mehr. Wahrscheinlich ist dies der Hauptgrund, warum verschiedene ROMs nicht funktionieren, da die Kernelversion eine spätere, bessere ist, aber kein neuerer Treiber verfügbar ist (und einer ohne den Quellcode nicht erstellt werden kann).
Die Befehlszeilenoptionen, die an den Boot-Kernel übergeben werden, können von entscheidender Bedeutung sein. Diese Optionen können beispielsweise den Kernel anweisen, bestimmte Speicherbereiche zu vermeiden, die dazu führen, dass das System beim Zugriff abstürzt.

— LawrenceC
quelle

Diese Antworten auf die Fragen des OP sind falsch (z. B. hat Android eine HW-Abstraktion) und die Argumentation ist auch falsch. Das OP entspricht dem Schreiben des Android-Flash-Images einer Windows-Installation, die eine Systemkonfiguration durchführt. Es gibt keine Konfiguration, wenn das Android-Flash-Image "installiert" ist. Der äquivalente Windows-Vorgang ist das Umsetzen eines vorhandenen Windows-Systems auf eine Festplatte / SSD von einem PC auf einen anderen und das erwartete fehlerfreie Booten. Das OP vergleicht Installationen das sind wie Äpfel für Orangen, und diese "Antwort" weist nicht darauf hin.

— sawdust

Sie haben eine gute Vorstellung davon, wie das Flashen eines ROMs in der von OP beschriebenen Weise dem Transplantieren eines vorhandenen Windows gleicht. Ich kenne die "Vendor Interface" -HAL in Oreo, aber es hängt nicht damit zusammen, wie ACPI auf x86 versucht, Hardware zu präsentieren - die Android-HAL ist auf Betriebssystemebene, nicht auf Firmwareebene.

— LawrenceC