Google überarbeitet Android-Sicherheitsupdates: Monatliche Notfall-Patches und quartalsweise Gesamt-Updates
von Benjamin Mamerow | 40 Kommentare
Ein Monat ohne eine einzige gemeldete Sicherheitslücke, der nächste mit über hundert. Was bei den Android-Sicherheitsupdates im Sommer 2025 passierte, war kein Zufall, sondern die sichtbare Konsequenz eines tiefgreifenden Umdenkens bei Google. Das Unternehmen hat die Art und Weise, wie Sicherheitspatches an Hersteller verteilt werden, reformiert.
Bisher war der Prozess wohl starr und vorhersehbar: Jeden ersten Montag im Monat veröffentlichte Google ein Android Security Bulletin, das Dutzende von geschlossenen Sicherheitslücken auflistete. Die Hersteller bekamen die Informationen und Patches rund einen Monat im Voraus, um die Updates für ihre unzähligen Geräte anzupassen und vorzubereiten. Kennt man so alles.
Während einige Hersteller es schafften, ihre Flaggschiff-Modelle monatlich zu versorgen, blieben viele andere Geräte, insbesondere im günstigeren Preissegment, auf der Strecke. Die Realität waren oft verspätete oder nur vierteljährliche Updates, was die Sicherheit der Nutzer beeinträchtigte.
Mit dem neuen „Risk-Based Update System“ (RBUS) bricht Google mit der alten Routine. Der neue Plan: Nur das, was wirklich akut und gefährlich ist, wird sofort behandelt. Die monatlichen Bulletins listen daher nur noch Schwachstellen auf, die als „hochriskant“ eingestuft werden, also solche, für die bereits aktive Angriffe existieren. Alle anderen, weniger zeitkritischen Patches werden gesammelt. Diese gesammelten Korrekturen fließen dann in umfangreiche Quartals-Updates ein, die jeweils im März, Juni, September und Dezember erscheinen.
Das Ziel dieser Maßnahme: Der Druck auf die Gerätehersteller wird massiv reduziert. Ein kleineres monatliches Paket für Notfälle und ein planbares, großes Quartals-Update machen es für die Hersteller deutlich einfacher, eine zuverlässige Update-Versorgung für ihr gesamtes Portfolio zu gewährleisten. Davon profitieren am Ende vor allem Nutzer von Nicht-Premium-Geräten.
Experten, wie die des GrapheneOS-Projekts, warnen allerdings, dass der deutlich längere Vorlauf für die Quartals-Patches (mehrere Monate statt nur einem) die Gefahr von Informationslecks vergrößern könnte. Sollten Details zu einer Lücke vorzeitig durchsickern, hätten Angreifer entsprechend mehr Zeit für die Entwicklung von Schadsoftware.
Da der Quellcode der Patches nun nicht mehr monatlich, sondern nur noch quartalsweise veröffentlicht wird, können zudem alternative Android-Systeme nicht mehr zeitnah mit den offiziellen Sicherheitspatches versorgt werden. Für den durchschnittlichen Anwender ist die Umstellung von Google eher ein logischer Schritt. Im besten Fall führt sie dazu, dass mehr Geräte verlässlicher mit Updates versorgt werden, auch wenn der Rhythmus für die meisten Patches nun quartalsweise ist.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Und das soll ein Fortschritt sein? Eher Rückschritt…
Würde sagen weder noch. Eher eine Anpassung an die Realität. Leider.
So funktioniert genau nichts. Wenn die Hersteller den Arsch nicht hochziehen, muss der Druck eben erhöht werden, nicht verringert. Und wenn es eben Vorschriften über die Zertifizierung werden. Wenn ein Hersteller bei den Updates schlampt, wird in Zukunft die Zertifizierung verweigert, bis nachgebessert wurde, da der Hersteller offenbar bereits jetzt mit seinen eigenen Geräten überfordert ist. Davon abgesehen hätte es da auch gerne bei der EU-Vorschrift klarere Vorgaben geben dürfen. 5 Jahre Updates bringen wenig, wenn die Updates zu selten kommen und die Systeme offen sind wie Scheunentore. Wenn das Ergebnis ist, dass es in Summe nicht mehr 20 neue Geräte pro Hersteller gibt, sondern nur noch 5-10, wird das wohl auch kein großer Verlust sein.
Als wenn das bei den Herstellern irgendetwas ändern würde.Samsung liefert doch schon ewig nur vierteljährlich bei den Tablet•s aus. Für LinageOS ein herber Rückschlag.. Einerseits Apple Preise verlangen und jetzt sowas.
Dumme Frage, aber warum werden die Sicherheitspatches nicht direkt von Google an ausgerollt?
Warum der Umweg über die Hersteller?
Weil bei ARM die Systemimages immer auf die Hardware angepasst werden muss.
Fast richtig. Bei Consumer-ARM ist das notwendig, weil man sich nicht an die in der x86- und ARM-Server-Welt etablierten standards hält. Das begreift aber seit über 15 Jahren niemand, obwohl es immer mehr auf die Füße fällt. Darum könnte selbst Linux die seit über 10 Jahren scheiternden Windows on ARM Geräte nicht retten, Software läuft zwar bedeutend zuverlässiger, die Hardwareunterstützung ist aber ein absoluter Krampf. Und darum ist die Entwickelung selbst von Android-basierten Alternativen wie eben GrapheneOS oder /e/ so aufwändig.
So unterstützt man die Hersteller im träge sein. Was Google in letzter Zeit vom Stapel lässt, ist absolut nicht nachvollziehbar.
Selten so eine technisch blöde Lösung gesehen. Da bei Google in der Regel keine Idioten arbeiten, geht es offensichtlich darum, offenen Android-Projekten wie GrapheneOS weiter zu schaden.
Das würde ich so nicht unterschreiben. Ich würde in der Tat sagen, dass bei Google vermehrt nur noch Idioten arbeiten, was sie seit einem Jahr selbst auf ihren eigenen Geräten an Qualität abliefern ist so unterirdisch wie vermutlich noch nie. Alle kompetenten Mitarbeiter sind offenbar gegangen oder gegangen worden. GrapheneOS und co sind zu irrelevant um solchen Aufwand zu betreiben, das wird wohl eher als netter Nebeneffekt mitgenommen.
@ Alex
Du hast Recht, dies gräbt AOSP immer mehr das Wasser ab. Bei dem Lebensgefährten meiner Mutter läuft LinageOS auf dem Pixel 4a 5G ohne Probleme. Er bekommt jeden Samstag ein Update und hat somit immer Zeitnah den Sicherheitspatch vom 5ten des Monats.
Was ich aber glaube ist, Google will Geld sparen zumal sie ja sehen, dass ihre Arbeit von vielen Herstellern unzureichend genutzt wird.
Richtiger Assi-Move von Google. Die Sicherheitslücken werden geleaked und ausgenutzt werden. Viel zu viele Entwicklungsteams weltweit werden Zugriff darauf haben, um solche Infos wirklich geheim halten zu können.
Hat am Ende für User nur Nachteile.
So oder so, das Thema wurde diese Woche schon zu Genüge auf anderen Plattformen diskutiert. Siehe beispielsweise den entsprechenden Post auf Hackernews. Fazit ist leider negativ für uns.
Als Google groß ankündigte, dass es X Jahre Patches gibt, hab ich immer gesagt: Müssen sie erstmal beweisen, macht bisher nur ein Hersteller: Apple. Jetzt verschlimmbessert man sich schon mal auf dem Weg dahin.
Und nicht vergessen: Google ist Werbung. Die verdienen Geld damit, dass sie eure Daten sammeln und ihr einen Bildschirm habt, der Werbung anzeigt. Ob Android oder Chrome oder sonst ein Produkt – alles Mittel zum Zweck. Und alles gerade genau so schlecht oder gut, dass die Leute es nutzen bei maximalem Profit für Google.
Samsung hält sich bisher auch an ihrem Updateversprechen (so weit ich das mitbekomme). Auch Google liefert die versprochenen Updates. Die Änderungen finde ich aber auch nicht gut.
Apple mag zwar lange Updates liefern, versprechen tun die aber gar nichts.
„Google ist Werbung“
Das ist auch der Grund, warum es keine vorinstallierte Firewall gibt oder auch nur eine offizielle Möglichkeit, Internetzugriff abzulehnen (oder besser zu gewähren). Eine App könnte auf alles Zugriff haben, ohne Internet (sowie Telefon- und SMS-Zugriff) würde der meiste Schaden abgewendet werden.
Und weshalb die guten Werbeblocker im PlayStore unerwünscht sind.
Früher kam für eine Sicherheitslücke ein Patch. Zeitnah.
Heute haben die Anbieter sich völlig verrannt in Patchdays, signierte Komplett-Images, gerätespezifische Anpassungen, und auf dieser von BWLern geschaffenen Basis kann man jetzt „leider, leider“ keine ordentliche Technik mehr anbieten.
Auf die Handys gehört EIN Basissystem, Hersteller können das gern modular erweitern, und Oberflächen sind einfach Apps. Fertig. Ist eine zentrale Komponente schadhaft, wird diese gefixt. So, wie wir das bei Desktop-Rechnern ja auch seit einem halben Jahrhundert machen.
Aber die wollen halt nicht, dass man einfach „das neue Android“ auf seinem alten Handy kaufen kann, Stick rein, Update, fertig.
Das ist genau das Problem, das seit mittlerweile fast 15 Jahren nicht angegangen wird. Man fummelt am Symptom statt die Ursache anzugehen (aber das ist halt Typisch für unser aktuelles Wirtschaftssystem).
ARM ist schön und gut aber man hätte es endlich weiter entwickeln sollen und ein vernünftiges Abstraktionslevel einbauen müssen, wie man das vom PC kennt (BIOS, UEFI). Dann müsste nicht jeder Hersteller sein eigenes Süppchen kochen und es geben einheitliche Software. Vielleicht hätten sie dann auch locker mit Software Geld verdienen können. Und man hätte also Kunde echte Alternativen (Linux statt Android).
Stattdessen hält man (absichtlich?) an dem Walled Garden fest und quält sich mit den Updates. Ohne Regulierung passiert hier nichts mehr. Die Ingeniuere des letzten Jahhunderts schütteln nur den Kopf, denn damals ging es um Standards und Langlebigkeit. Heute nur kurzfristigen Profit.
ARM selbst ist nicht das Problem, bei ARM in Servern gibt’s keine Probleme. Schon alleine weil es da keine andere Option gibt, als perfekte Linux-Unterstützung zu bieten, sonst kauft die keiner. Aber Consumer-ARM-Geräte sind da einfach Schmutz, egal ob die mit Android, Windows oder macOS verkauft werden. Einzig Geräte wie RasPis, die für Linux gebaut sind, funktionieren ordentlich und verkaufen sich wie geschnitten Brot.
@ Jörg
Naja es gibt bei Android eben zu viele unterschiedliche Hardware. Da Android im Kern ja Linux ist wird der Kernel usw. an die jeweilige Hardware angepasst.
Klar könnte man ein Android machen wie eine moderne Linux Distro, wo dann alle erdenklichen Module dabei sind, aber es würde den Speicherplatz des BS im Smartphone sicherlich mehr als verdoppeln. Dies will aber ja auch keiner.
Mein Fedora Gnome System dass ich ungefähr vor einem Monat installiert habe und das bereits meine wichtigsten Programme installiert hat, belegt 30GB meiner Festplatte. Ein frisches Android braucht jetzt sicher auch schon 20GB. Also nein ich denke nicht dass da mehr als doppelt soviel Speicher fürs System gebraucht wird.
Noch mehr kannst du aber nicht zeigen, dass du keine Ahnung hast, was? Der Debian-Kernel belegt ca 200 MB, dazu kommen vielleicht noch ein paar hundert MB an Firmware. Selbst wenn du immer alles an Firmware vorrätig hast, was es upstream gibt, sind das nur knapp über 5 GB. In der Bootpartition und damit im Arbeitsspeicher landet davon wenig bis gar nichts. Das ist dann in der Lage, auf praktisch jedem x86_64 Computer der letzten 20 Jahre zu booten, die Wahrscheinlichkeit dass irgendeine Hardware nicht unterstützt wird ist gar nicht so groß.
Und jetzt erklär uns doch Mal bitte wie du es schaffen willst, dass in den wenigstens 10 GB Speicher, die fürs System reserviert sind, kein Kernel passen soll, bei dem man vieles abschalten kann, weil es eh keine Relevanz hat, und wo man eben dynamisch nur die Firmware/Microcode hinterlegt, die das Gerät braucht. Würden die Hersteller gezwungen ihre Treiber upstream einzupflegen, wie es Intel und AMD seit Jahrzehnten machen, wäre der Aufwand für Google und für die Hersteller um Größenordnungen geringer. Mal davon abgesehen, dass Treiber sicherlich deutlich bessere Qualität vorzuweisen hätten.
> Naja es gibt bei Android eben zu viele unterschiedliche Hardware.
Das ist jetzt nicht dein Ernst, dass Smartphones diverser sein sollen als x86-64?
Das ist nichtmal ansatzweise so, UND es gibt ja Wege, den Kernel zu erweitern: Module, Treiber,…
Smartphones sind auf jeden Fall diverser, bei x86 hast du genau zwei Hersteller, die aktuell eine Lizenz haben, bei ARM hast du neben Google, Samsung, Qualcomm und Huawei noch einige andere. Und da hast du ja nicht nur unterschiedliche CPUs, sondern auch GPUs und Modems. Da kannst du vielleicht die gleichen Treiber für Mali-CPUs nutzen, wenn du entsprechende Firmware schreibst vermutlich auch für alle mit ARM Kernen von der Stange. Bei Mobilfunk, WLAN und Bluetooth ist aber spätestens Schluss, und dann kommt noch einiges mehr.
Bei PCs hast Du aber auch unterschiedliche GPUs. Neben den Integrierten von AMD und Intel sind da noch die dedizierten Karten von AMD, Nvidia und Intel. Teilweise sind auch integrierte und dedizierte GPUs vorhanden, nicht zwangsweise vom selben Hersteller.
Außerdem gibt es auch Laptops mit Mobilfunkmodem. Fast alle PCs haben ebenfalls WLAN und Bluetooth. Von der universellen Erweiterbarkeit über PCIe (und USB) mal ganz abgesehen.
Auch bei den CPUs gibt es Unterscheide: Server-CPUs haben andere Fähigkeiten als Consumer-CPUs. Es gibt CPUs mit unterschiedlichen Kernen (ähnlich wie bei Smartphones auch). Außerdem brauchst Du bei x86 auch noch ein Mainboard mit einem Chipsatz und davon gibt es mehr Mainboard-Hersteller als von den CPU-Hersteller und es sind nicht wie bei Smartphones die CPU-Hersteller selbst.
Klar, aber in Summe sind es sowohl weniger Komponenten als in Smartphones und von weniger Herstellern. Bei GPUs alleine hast du ja schon ARMs Mali, powerVR, Qualcomms Adreno und Samsungs RDNA-basierte GPUs. Klar, du hast keine dGPUs, aber das macht bei der Diversität der Geräte keinen wirklichen Unterschied. Das Motherboard mit Chipsatz und Co ist ohnehin irrelevant, dafür brauchst du keine Treiber und BIOS Updates kommen immer direkt vom Hersteller. Und bei Smartphones ist es vielleicht besser, dass sie kein BIOS haben, sonst wäre Dual BIOS Pflicht, sonst wäre die Chance zu groß, sich das Gerät zu zerschießen.
Und warum kann ich mir dann für Windows Chipsatztreiber installieren, wenn die nicht benötigt werden?
Ich habe in meinem Rechner eine TV-Karte drin. In Smartphones ist das eher unüblich (wenn es das überhaupt gibt). Was haben Smartphones für Hardwarekomponenten, die es in PCs und Laptops nicht gibt?
dGPUs machen schon einen Unterschied, auch wenn es nicht so viele gibt. Mit dGPUs kommt es oft vor, dass dann 2 GPUs (dGPU+iGPU) verbaut sind, nicht zwangsweise vom selben Hersteller. Man kann auch zwischen denen flexibel wechseln. Das können Smartphones nicht, ganz zu schweigen davon, dass Smartphones keine zwei GPUs haben.
So etwas wie ein BIOS haben Smartphones auch, ist wahrscheinlich Wortklauberei. Aber auch den Bootloader von Smartphones kannst Du zerschießen.
Sofern Jörg mit x86-64 PCs (und Laptops) gemeint hat: Linux und Windows laufen (mehr oder weniger) auch auf ARM, z.B. auf dem Raspberry Pi. Und es gibt offensichtlich auch ARM für Server. Das erhöht also die Hardwarediversität. Dass nicht alle Programme darauf laufen ist ein anderes Problem.
> Und warum kann ich mir dann für Windows Chipsatztreiber installieren, wenn die nicht benötigt werden?
Ich glaube du redest da von einem anderen „Chipsatz“. Das, was gemeinhin als „Chipsatz“ des Motherboards bezeichnet wird, wird einzig vom BIOS mit Updates versorgt und ermöglicht verschiedene Funktionen, etwa geht Overclocking der CPU oft nur mit einem Motherboard mit dem richtigen Chipsatz. Und der Chipsatz legt eben auch fest, welche CPUs funktionieren, selbst wenn der Sockel der gleiche ist. Was auch immer Windows da als Chipsatz bezeichnet meint mit sehr hoher Wahrscheinlichkeit etwas anderes, kann auch ne schlechte Übersetzung sein.
> Was haben Smartphones für Hardwarekomponenten, die es in PCs und Laptops nicht gibt?
ISPs gibt’s nur in den paar Qualcomm Laptops und ich meine den aktuellsten Intel Laptops. DSPs sind meine ich auch eher unüblich in einem PC. NFC gab es mal in ein paar Laptops, aber ich meine das ist inwzischen ausgestorben. Dazu noch eine Vielzahl von Sensoren wie Lagesensor, Beschleunigungssensor, Näherungssensor, Barometer etc. Orientierungssensoren findest du noch in Convertibles und Tablets, aber dann wird’s eng.
> dGPUs machen schon einen Unterschied
Nein, nicht in einer Form die in dieser Diskussion von Relevanz wäre.
> So etwas wie ein BIOS haben Smartphones auch, ist wahrscheinlich Wortklauberei.
Nein, haben sie eben nicht, weil sie es schlicht nicht brauchen. Da wird nur der Bootloader geladen, der sonst vom BIOS/UEFI geladen wird.
> Sofern Jörg mit x86-64 PCs (und Laptops) gemeint hat
Lesen will gelernt sein. Stein des Anstoßes war die Aussage:
> Das ist jetzt nicht dein Ernst, dass Smartphones diverser sein sollen als x86-64?
In Smartphones kann auch ein Intel-SoC stecken, so dumm ist nur keiner mehr, weil die im Vergleich bedeutend schlechter waren.
> Was auch immer Windows da als Chipsatz bezeichnet …
Aber es ist etwas Mainboardspezifisches. Linux hat etwas entsprechendes auch im Kernel. Man kann ja auch verschiedene Temperatursensoren, Spannungssensoren usw. auslesen.
Das Steamdeck hat auch eine Bewegungssteuerung, das scheint also gar kein so großes Problem zu sein.
> DSPs sind meine ich auch eher unüblich in einem PC. NFC gab es mal in ein paar Laptops.
Eine TV-Karte dürfte doch ein DSP sein, oder? Kann man ja zur Not nachrüsten. Es spielt keine Rolle ob es unüblich oder ausgestorben ist. Es geht darum, dass es so etwas gibt/gab. NFC wird wahrscheinlich immer noch gehen, wenn man die entsprechende HW findet.
In der Industrie wird es ISPs und DSPs wahrscheinlich vermehrt geben. Ob das dazu zählt kann ich aber nicht beurteilen.
> Lesen will gelernt sein. Stein des Anstoßes war die Aussage:
> > Das ist jetzt nicht dein Ernst, dass Smartphones diverser sein sollen als x86-64?
Wer im Glashaus sitzt: Er hat auf „Naja es gibt bei Android eben zu viele unterschiedliche Hardware.“ geantwortet. Und er schrieb nicht „ARM-SoCs sind diverser als x86-64“. „x86-64“ und „Smartphones“ sind Äpfel und Birnen. Daher meine Annahme.
In der ganzen Diskussion geht es doch über die HW-Flexibilität von Android. Die Annahme, dass der andere Part Windows- und Linuxrechner sind, liegt doch recht nahe. Und da gibt es auch ARM-Chips, was den Bereich noch diverser macht. Z.B. Raspberry Pi oder die von Dir genannten Qualcomm Laptops.
> Aber es ist etwas Mainboardspezifisches. Linux hat etwas entsprechendes auch im Kernel.
Und? Was hat das mit dem Thema zu tun, außer absolut gar nichts?
> Eine TV-Karte dürfte doch ein DSP sein, oder?
Wieso sollte sie?
> In der Industrie wird es ISPs und DSPs wahrscheinlich vermehrt geben.
Nicht in der x86-Welt. Bei Smartphones gibt es diese große Anzahl an spezialisierten Prozessoren, weil es der einzige Weg ist, ausreichend Leistung in das enge Energiebudget zu pressen. Bei x86-Geräten ist dieser Zwang eben nicht so groß, daher verschwendet keiner für sowas Silizium. Vielleicht in Industrieanlagen, die alles hochoptimiert verbauen, aber das läuft dann nicht auf x86. Und nur davon war die Rede.
> Wer im Glashaus sitzt: Er hat auf „Naja es gibt bei Android eben zu viele unterschiedliche Hardware.“ geantwortet. Und er schrieb nicht „ARM-SoCs sind diverser als x86-64“. „x86-64“ und „Smartphones“ sind Äpfel und Birnen. Daher meine Annahme.
Nur dass deine Annahmen völlig am Thema vorbei gehen. Ich habe auch nie gesagt, einzig ARM-SoCs wären diverser als x86 Chips, aber du hast einfach alleine da schon so viel Diversität, mit nur einer von sehr vielen Componenten eines Smartphones, dass die x86-Welt dagegen schlichtweg alt aussieht.
> In der ganzen Diskussion geht es doch über die HW-Flexibilität von Android. Die Annahme, dass der andere Part Windows- und Linuxrechner sind, liegt doch recht nahe. Und da gibt es auch ARM-Chips, was den Bereich noch diverser macht. Z.B. Raspberry Pi oder die von Dir genannten Qualcomm Laptops.
Das ist nun wirklich die Definition von goalpost shifting um Recht zu behalten. Die Aussage war x86, nicht PCs. Damit sind PCs mit ARM SoC per definition ausgeschlossen. Und es ging eben nicht um Flexibilität, sondern um Diversität. Wenn du den Unterschied nicht kennst, rate ich zum Blick ins Wörterbuch. Also bleib beim Thema oder sei wenigstens ehrlich und gib zu, dass du unsinn verbreitest, einfach nur um Recht zu behalten.
> > Eine TV-Karte dürfte doch ein DSP sein, oder?
> Wieso sollte sie?
Weil sie digitale Signale prozessiert? Oder wie meinst Du kommen die analogen Signale auf den Bildschirm? Wikipedia gibt mir sogar recht: TV-Karten können DSPs einsetzen.
> Nur dass deine Annahmen völlig am Thema vorbei gehen.
Smartphones sind vollständige Systeme. x86-64 bezeichnet ausschließlich die CPU. Das ist nicht Vergleichbar. Man muss also von x86-64-CPU auf x86-64-PC schließen. Viele Elemente eines Smartphones-SoCs sind bei „x86-64“ ausgelagert, müsste man eigentlich mit betrachten.
> Das ist nun wirklich die Definition von goalpost shifting um Recht zu behalten.
Die Ursprüngliche Aussage war doch, dass Android so hochspezialisiert ist, dass es immer nur ein speziell angepasstes Android-OS für ein ganz bestimmtes System gibt. Weil die Systeme/Smartphones so divers sind. Android ist demnach extrem unflexibel, da es immer nur auf ein System angepasst werden kann. Windows und Linux haben dieses Problem nicht.
Ich gebe aber zu, dass Jörg nicht vom OS gesprochen hat. Ich gebe auch zu, dass es mehr unterschiedliche Smartphones als x86-64-CPUs gibt (was ich auch gar nicht bestritten habe). Abgesehen davon, dass das ein Äpfel-Birnen-Vergleich ist, ist dass das eigentliche „goalpost shifting“. Denn darum geht es nämlich gar nicht. Ich „shifte“ also nur zurück.
Selbst die Diversität ist eigentlich kein gutes Argument. Windows und Linux laufen auf allen möglichen HW-Kombinationen. Und lass es nur AMD- und Intel-CPUs sein, das ist schon mehr was Android kann.
Lineage OS (Samsung wahrscheinlich auch) unterscheidet zwischen Galaxy S10, Galaxy S10 5G und Galaxy S10+, obwohl die sehr ähnlich sind: das S10+ hat nur eine Kamera mehr und einen größeren Akku (und ein größeres Display, aber die selbe Auflösung).
GrapheneOS unterscheidet zwischen Pixel 9 Pro XL und Pixel 9 Pro (und Pixel 9). Die Auflösung und die Akkugröße reichen anscheinend schon aus, um für Android die Diversität ins technisch unmögliche zu erhöhen.
Natürlich ist da so. Verschiedene SoC Konfigurationen, verschiedene Sensoren, grundverschiedene Hardware Komponenten. Oder besteht dein Smartphone nur aus einem Akku, einem Display und einem Standard-SoC ohne Anpassungen?
Falls dir das alles schon klar ist: wer genau soll die Treiber für all das liefern, damit sie in den Kernel gebacken werden können?
Irgendwie ist dein Post ganz weit entfernt von der (Hardware-)Realität und der Software-Situation auf Mobilgeräten.
Ach und PCs sind alle gleich? Alleine die Anzahl an Mainboards von verschiedenen Herstellern und Ausbaustufen ist nicht gerade klein. In Kombination mit der CPU und GPU in verschiedenen Größen und Generationen dürfte da eine große Auswahl entstehen. Dank PCIe (und USB) lassen die sich auch beliebig erweitern.
Und dann gibt es auch noch Laptops, die wieder eigene CPUs und Mainboards haben. Die dürften ähnliche (wenn nicht sogar mehr) Variationen wie Smartphones haben. Die bestehen auch nicht nur aus Akku, einem Display und einem Standard-SoC (hier eher Chipsatz+CPU+GPU) ohne Anpassungen.
Thema verfehlt, setzen.
Und für die Zensur der Drittentwicklerapps wollten sie uns weis machen, sie würden sich ja nur für unsere Sicherheit interessieren, schaden dieser dann aber aktiv mit solchen Fehlentscheidungen. Traurig dass es weiterhin Leute gibt, die den Unsinn glauben und verteidigen…
So zu sehen beim Pixel 8 Pro: Seit inzwischen 4 Monaten funktionieren die Navigationstasten, also die wichtigsten Tasten überhaupt, nicht, bzw. sehr verzögert(10sec+). Neuerdings dreht sich der Bildschirm immer seltener zur Seite(landscape).
Man könnte allerdings eher den Eindruck bekommen, dass das zum Neukauf anregen soll. Auch wenn einige wenige aber meinungsstarke behaupten, dass Google nichts weniger wolle.
,,Während einige Hersteller es schafften, ihre Flaggschiff-Modelle monatlich zu versorgen,“ Welche sind das? Samsung und Xiaomi schonmal nicht.
Dafür das Google vor Jahren noch meinte es wird mit jeder Android Version einfacher für andere, passiert in letzter Zeit eher genau das Gegenteil. Es wird immer schwieriger.
Sagt wer? Es wird einfacher, aber wenn auf der einen Seite kompetente Entwickler rausgeschmissen werden und auf der anderen Seite ein Mix aus Geldgier und Vorgaben zur Uodatelänge stehen, am Ende aber nicht weniger Geräte jedes Jahr auf den Markt geschmissen werden, wächst der Aufwand natürlich exponentiell, auch wenn er pro Gerät schrumpft.
Diese Änderung zeigt, dass die Unmenge an Android Geräten mit unterschiedlichen Prozessoren und den notwendigen Anpassungen nicht zu handhaben ist. Insbesondere Billigsegment lässt sich damit einfach kein Geld verdienen, weil der Aufwand für die Pflege zu groß ist.
Zumindest mit der Umsetzung und der Geheimniskrämerei ist das nicht möglich. Ist die damals bei UNIX, hätten die sich nicht auf POSIX als kleinsten gemeinsamen Nenner geeinigt, hätten sie sich gegenseitig zerstört. Man könnte es so viel einfacher haben würde man so arbeiten wie Intel, AMD und auch ARM-Anbieter für Server. Will man aber nicht, denn dafür bräuchte es kompetente Entwickler. Die Diversität des Ökosystems ist in keiner Weise das Problem, nur dass man sich nicht an seit Jahrzehnten etablierte best pfactices hält.