Warum passt nicht jedes Android OS auf jedes Smartphone?

[Sakronautus]

Hallo,

wie schon der Titel meine Frage welche ich gerne etwas tiefgründiger beantwortet wüsste.
Evtl. ist das auch eher etwas für XDA, aber ich frage einfach mal ganz blöd:

Warum kann ich nciht einfach jede Android Version von Stock bis Custom auf ein xbeliebiges Handy aufspielen wenn es doch eigentlich Open Source ist?

Das es mit den Rechten, Kernel und Motherboard Versionen etc. nicht passt und zusammenhängt ist mir klar.
Und das der Hersteller das nicht möchte auch. Aber wo ist die Schwierigkeit oder das Unmögliche jede Version auf jede Hardware zu bekommen? Es werden doch von so vielen talentierten da draußen auch divere Roms entwickelt, welche zwar auf dem bestehenden aufbauen, jedoch sollte doch wer mit diesem Geschick auch in der Lage sein so etwas zu realsieren?!

Ich vergleiche das nun mal mit dem PC (bestimmt grober Fehler ) Hier kann ich auch alles zusammenbauen und später einfach Linux, Windows etc installieren wie es mir passt.
Das die Freiheit des fast selbstständigen Zusammenbauens mit dem Google ARA Projekt auch näher rückt möglich, das mit der Software wird wohl nie wie im PC Segment werden, wirtschaftlich verständlich, aber WO ist das technische Problem?

Danke und VG Sakronautus

 

[email.filtering]

Das Hauptproblem ist und bleibt seit jeher die Treiberfrage! Und so lange die Closed Source sind und dem Kunden nicht zur Verfügung stehen, ist da auch nichts mit OS mal eben aufsetzen. Um welches OS und um welche Hardware es dabei geht, ist dabei vollkommen unerheblich! Ganz krass sind in diesem Zusammenhang alle "Vorgänge" rund um das vermeintliche Allheilmittel Bluetooth, bei dem auch noch konzeptionbedingt grundsätzlich der Wurm drinnen ist, weshalb es dabei auch die allermeisten und allerhartnäckigsten Probleme gibt! Der "Hardware-nahe" Anteil der Treiber (in anderen Bereichen oft als .bin bekannt) ist bei Androiden im jeweiligen "Baseband", also einer gesonderten Partition, enthalten, und darauf setzen natürlich noch die "Software-nahen" Treiber (den meisten eher als Schnittstellen ein Begriff) auf, die bei den Androiden in der Regel in der Systempartition enthalten / platziert sind.

Dass es sich die werten Hersteller auch selbst schwer machen, in dem sie jedes mal irgendeine Kleinigkeit an einem schon bestehenden Produkt bzw. dessen Konzept herumfummeln müssen und dann zig verschieden konfigurierte und partitionierte, sonst aber nahezu idente Geräte auf den Markt hauen, macht die Sache für niemanden einfacher.

Das OS selbst setzt dem ganzen dann nur noch den Hut oben drauf, denn auch dort fährt Google mit seinem OS einen Zick-Zack-Kurs der Sonderklasse, weil man vor lauter Daten-; Geld- und Selbstbeweihräucherungs- und -verwirklungsgeilheit (nein, man kann dafür kein anderes Wort wählen) gar nicht mehr weiß was man nun wirklich will. Mal gibt's natives App2SD, mal nicht, mal gibt's eine Speicherkarte, mal nicht, mal wird der USB-Massenspeichermodus unterstützt, mal nicht, und wenn dann immer noch nicht zu viel Probleme und Verwirrung gestiftet wurde, werden halt wieder mal innerhalb kürzester Zeit die APIs zweimal hintereinander gröber über den Haufen gehauen, und an all das soll der (Geräte-)Hersteller die Schnittstellen zu den von ihm selbst nur lizenzierten Treiber anpassen (lassen) und oftmals dafür auch nochmals kräftig beim Hardwarehersteller abdrücken. So wird das auf Dauer wohl nicht weitergehen (können).

 

[Sakronautus]

Danke für deine Ausführung!
Also wenn ich das richtig verstehe wäre es die Nadel im Heuhafen suchen?

Als Beispiel lassen sich nach einiger Zeit alle Konsolen iwie mit Sicherheitskopien spielen.
Diese Informationen waren zuvor auch "Closed Source".

Demnach könnte man doch auch wie gesagt theoretisch Pure Android vom Google Server laden und auf ein Galaxy Phone zB laden.
Aber wenn ich das richtig verstanden habe, sind das im Gegensatz zum Beispiel Konsole einfach zu viele Treiber und Schnittstellen also sprich zu viele unbekannte Variablen als das dies möglich wäre zum laufen zu bringen?

 

[email.filtering]

Ich weiß nicht so recht; der Vergleich mit der Nadel im Heuhaufen passt da irgendwie nicht. Der Knackpunkt bliebt die unbekannte, weil "geschlossene" Hardware und die dafür notwendigen Treiber. Gäbe es einen Layer zwischen der Hardware und dem "System", dann ließe sich das wohl einfacher machen, aber ein solcher ist nicht einmal ansatzweise in Sicht.

Auch Google kann auf seinen "eigenen" Geräten (die ja von den diversen Geräteherstellern aus fremdentwickelten Einzelteilen gefertigt werden) den Source Code des AOSP nicht ohne Anpassungen nutzen, auch wenn das viele annehmen (weil der ja vor der offiziellen Veröffentlichung oder besser Freigabe durch das AOSP von Google angepasst wird und daher der Eindruck entsteht, der sei eben frisch aus dem Repository gezogen worden). Der Source Code des AOSP funktioniert eben nur auf einem abstrakten, also lediglich virtuellen Gerät, das eben nur in einer Virtualisierung "nutzbar" ist.

Bei all diesen Dingen ist im Vorfeld des heutigen AOSP bei der "Projektplanung" (die es vermutlich gar nie wirklich gegeben hat) gewaltig viel versemmelt, zumindest aber nicht ansatzweise "zu Ende" gedacht worden, und vieles davon kann man kaum noch "geradebiegen". Wir werden leider mit diesem Murks leben müssen bis es endlich eine Alternative gibt. Android ist keinesfalls ein Ruhmesblatt für die EDV-Geschichte, gleich wie "erfolgreich" es derzeit mangels jedweder sinnvoller Alternativen und dem Mauern der diversen Beteiligten gerade sein mag.