@Olandos Man kann Windows nicht mit Android vergleichen! Beides sind Betriebssysteme und da endet die Gemeinsamkeit auch schon.
Wenn du den genauen Grund für die Updateproblematik wissen möchtest, dann im Folgenden ein bisschen Text dazu. Technische Details sind vereinfacht dargestellt, um das Problem verständlich und keine Doktorarbeit daraus zu machen:
Prinzipiell ist deine Frage durchaus berechtigt und nachvollziehbar. Sie hat aber einen kleinen Denkfehler: Google hat (fast) keinerlei Rechte, auf die Systempartitionen eines Gerätes schreibend zuzugreifen. Welche Ausnahmen das sind, werde ich dir weiter unten erklären. Aber das ist im Vergleich zu Microsoft der Grund, wieso Updates über die Hersteller eingespielt werden
müssen.
In Windows öffne ich die Computerverwaltung und kann das Konto des Administrators aktivieren und nutzen. In Linux öffne ich ein Terminalfenster und gebe
sudo su ein. In beiden Fällen kann ich danach im System meinen Unfug treiben. In Android, das im wesentlich auf Linux basiert, v.a. die Systemverwaltung betreffend, wäre auch der Befehl
su nötig, um Schreibrechte auf höchster Ebene zu erhalten. Leider gibt es aber im AOSP weder die Binary
sudo noch
su, die es möglich machen würden, zum User root zu wechseln oder zumindest Befehle als root auszuführen. Somit ist es also für niemanden möglich, im lfd. System schreibend auf irgendwelche Systemverzeichnisse zuzugreifen. Lesend natürlich schon, sonst könnte man kein Gerät booten. Diese und weitere Einschränkungen werden durch die Zugriffsrechte verwaltet.
Wie können dann überhaupt Updates bei Android eingespielt werden, wenn keiner schreibend Zugriff hat? Windows gliedert das Betriebssystem durch viele Verzeichnisse auf der genutzten Festplatte. Android aber nutzt keine Verzeichnisse, sondern Partitionen auf deinem Speicherchip. Sehr vereinfacht dargestellt: /bootloader, /boot, /system und /vendor (insgesamt sind es 50-100 Partitionen, je nach Hersteller). Das Sicherheitskonzept bei Android, das bei deiner Frage maßgeblich verantwortlich dafür ist, warum Updates über die Hersteller eingespielt werden müssen, heißt AVB (Android Verified Boot).
AVB macht folgendes: Zuerst wird der Bootloader gecheckt, ob er gesperrt ist. Wenn ja, startet folgende Verifizierungskette, wobei jedes Element das darauffolgende Element verifiziert:
Bootloader > /boot > /vendor > /system
und wenn alles erfolgreich ist, ist Android gebootet (sehr vereinfacht dargestellt).
Die Verifizierung erfolgt dabei über SHA-Prüfsummen. Diese Prüfsummen haben die Eigenschaft, dass sich ihr Ausgabewert (Hash) schon bei einer Veränderung von nur 1 Bit komplett verändert. Ist also der Hashwert nicht wie erwartet, bootet das Gerät nicht, weil die Integrität der Dateien nicht gewährleistet ist.
Zurück zum Update: Im lfd. System besteht also kein Schreibrecht. Außerdem wäre das Recht nur dann von Vorteil, wenn auch ein Dateisystem existiert. Android besitzt nämlich viele Partitionen mit Binärdaten, die nicht als Dateien dargestellt und angesprochen werden können.
All dies spielt dann keine Rolle mehr, wenn wir auf Partitionsebene arbeiten. Durch die feine Gliederung der einzelnen Partitionen haben wir auch viele Optionen, Veränderungen durchzuführen. Aber auch auf dieser Ebene haben wir im lfd. System natürlich keine Schreibrechte.
Also gehen wir in die Recovery. Die Recovery ist immer als User root angemeldet und das ist nicht änderbar, weil auch hier keine Binary
su existiert (su ≠ super user, sondern = substitute user!). In der Recovery können einzelne Partitionen verwaltet werden. Aber nur auf Partitionsebene und nicht auf Dateiebene! Vergleichbar mit der Installationsroutine von Windows, bei der ich einzelene Partitionen verwalte, ohne auf deren Inhalt Zugriff zu haben.
Zusammengefasst: Wir ersetzen bei einem Update aufgrund der Schreibrechte die einzelnen Partitionen in der Recovery.
Gesagt, getan. Genauso funktioniert grundsätzlich ein Update bei Android. Ein OTA-Update ist nur eine angepasste Variante dessen, um die Dateigröße zu senken. Prinzip bleibt aber gleich.
Das alles könnte Google prinzipiell so umsetzen, um selber Updates einzupflegen. Aber danach würde dein Gerät nicht mehr booten, denn wir müssen AVB beachten! Das Update ändert ja logischerweise den Hashwert der Partitionen. Diesen Hashwert kann Google aber nicht bestimmen, da die Firmware jedes Modells eines jeden Herstellers da draußen zusammengesetzt ist aus
AOSP + Google Mobile Services + Herstellersoftware
Letzteres ist Google selbstverständlich nicht bekannt. Deinem Hersteller aber schon. Also ist nur der Hersteller in der Lage, den Hashwert zu bestimmen, der mit einem Update angepasst werden muss, damit dein Gerät bootet. Das ist der Grund für alles und die Antwort auf deine Frage.
###
BTW:
Google hat im Hintergrund die vergangenen Jahre sehr, sehr viel bei Android angepasst, um Einfluss auf die Updates zu haben. Googles Ziel ist es, so viele Komponenten von Android wie möglich selbst verwalten und updaten zu können (
Project Mainline). Aber sie können durch die o.g. Bedingungen nicht alles selber verwalten. Du als Nutzer kennst nur die Google Play System Updates, die ein Ergebnis dessen sind. Dahinter stecken einzelne Module von Android, die unabhängig vom Hersteller auf einer eigenen Partition ausgegliedert wurden (/apex) und Updates über den Play Store erhalten. Das widerspricht auf den ersten Blick zwar völlig meinen Ausführungen von oben, wurde aber so strukturiert, dass es konform ist. Aber es ist immer noch nur ein Teil der Updates das AOSP betreffend und im Grunde nichts Ganzes und nichts Halbes.
Google will, aber Android müsste von Grund auf neu aufgebaut werden. Das ist leider ein Fehler in der Struktur, der sich nur schwer ausgleichen lässt, um die Updateproblematik in den Griff zu bekommen.
Man darf auch nicht annehmen, dass Google die alleinige Macht hat und die Hersteller sich den Policies zu unterwerfen haben. Das AOSP, was nicht Android ist (Android = AOSP + Google Mobile Services), wird von der
Open Handset Alliance verwaltet. Google hat zwar den Vorsitz, aber die Hersteller haben auch ein Wörtchen mitzureden. Samsung hat sich z.B. in der Vergangenheit bei einer Neuerung dermaßen quergestellt, dass die Policies zu Android 11 ihren Wünschen entsprechend von Google angepasst wurden (s.
hier).
h00bi schrieb:
und die fehlende Eierlegende-Wollmilchsau-Backuplösung ohne dass man das Gerät rooten muss.
Auch da kann Google nicht viel ändern. Die Entwickler der Apps aber schon. Das Problem ist das Sandbox-Prinzip: Eine App kann nur auf die eigenen Daten, aber nicht auf die Daten anderer Apps zugreifen. Somit ist keine App in der Lage, die Daten anderer Apps zu sichern und wiederherzustellen.
Nehmen wir Whatsapp, sieht man das ganz deutlich. Whatsapp sichert sich selbst, weil nur Whatsapp auf die eigenen Daten zugreifen kann.
Das kannst du z.B. mit Total Commander oder einer Terminal App gut testen. Die appeigenen Verzeichnisse unter /data/data sind problemlos schreibend zugänglich. Alle anderen nicht.
Die Google Sicherung umgeht das Sandbox-Prinzip mit einer Freigabe der betreffenden Appdaten, die dann gesichert werden können. Aber nicht Google bestimmt hier, ob und welche Daten freigegeben sind, sondern die Entwickler der Apps. Google nimmt dann das, was ihnen die Entwickler erlauben zu nehmen.
