Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsAndroid: Google fordert von OEMs zwei Jahre lang Patches
Eher noch mindestens 5 Jahre, meiner Meinung nach. 10 Jahre muss nicht unbedingt sein, wie einige schreiben, wenn es natürlich trotzdem wünschenswert wäre.
tmkoeln schrieb:
Bevor hier zu viele Hoffnungen entstehen. Sicherheitsupdates nicht Feature oder Versionsupdates....
Braucht keiner hoffen das ein Android P Device die nächste Version erhält...
Das halte ich persönlich auch gar nicht für nötig. Hauptsache die Sicherheitslücken sind zu.
Kacha schrieb:
Fuer euch beide: Der Unterschied ist schlicht und einfach, dass ein Smartphone eigentlich ein Embedded Device ist und eben kein Computer. Die komplette Architektur, Software, Hardware, ist darauf ausgelegt. Gegenueber einem Computer hat ein Smartphone so gut wie keine Abstraktionsebenen. Deswegen hat man ja fuer jedes Smartphone sein eigenes ROM. Da ist alles drin was benoetigt wird mit der Hardware zu kommunizieren. Du kannst nicht einfach Treiber wechseln oder aehnliches. Das Android auf Linux aufbaut hat absolut nichts mit einer Linux Computer Distribution zu tun. Es gibt genug Embedded devices die auf Linux aufbauen aber genau die gleichen Probleme haben.
Ehrlich gesagt ist das doch total egal. Worauf das aufbaut, wie das funktioniert. Sicherheitslücken sind eben zwingend zu schließen. Wenn du eine andere Software kaufst, ist dies ja auch - zumindest in D für die Zeit der Gewährleistung (was dann auch nur 2 Jahre sind) - zu beheben, dasselbe gilt für Hardware. Wieso nicht bei der Kombination Software mit Hardware? Übrigens gibt es dann noch die Produkthaftung, und die zählt unabhängig von der Gewährleistung unbegrenzt. Daher gibt es ja auch z.B. bei Fahrzeugen Rückrufaktionen. Aber auch bei anderen Produkten. Oder eben Updates (bei Software), da man als Hersteller eines Produkts eben auch nach der Gewährleistung (unter bestimmten Bedingungen) haftet.
EDIT: Produkthaftung bei Konsumentenendgeräten wird wahrscheinlich schwierig, da Sach- oder Personenschaden eintreten muss.
Ist das nicht eigentlich eine Sache für den Verbraucherschutz?
Funktionsupgrades können die Hersteller meinetwegen ja nach belieben verteilen, (bekannte, nicht gepatchte) Sicherheitslücken sollten mmn. aber als Produktmangel gelten der als Rückgabegrund zählt!
Die Hersteller sollten daher verpflichtet sein den Geräten zwei Jahre lang Softwarepflege ab dem Kauf im Laden (nicht Release des Geräts) zuzusichern.
Kann man das (aufgrund etwaiger Ladenhüter) nicht stemmen sollte Soft-und Hardware ein auf der Packung (/ Beschreibung im Netz) ein offensichtlich präsentiertes "Mindesthaltbarkeits-Datum" aufweisen, anhhand dessen der Käufer erkennen kann, wie lange das Produkt noch mit Sicherheitspatches und Bugfixes versorgt wird.
Eher noch mindestens 5 Jahre, meiner Meinung nach. 10 Jahre muss nicht unbedingt sein, wie einige schreiben, wenn es natürlich trotzdem wünschenswert wäre.
Das halte ich persönlich auch gar nicht für nötig. Hauptsache die Sicherheitslücken sind zu.
Ehrlich gesagt ist das doch total egal. Worauf das aufbaut, wie das funktioniert. Sicherheitslücken sind eben zwingend zu schließen. Wenn du eine andere Software kaufst, ist dies ja auch - zumindest in D für die Zeit der Gewährleistung (was dann auch nur 2 Jahre sind) - zu beheben, dasselbe gilt für Hardware. Wieso nicht bei der Kombination Software mit Hardware? Übrigens gibt es dann noch die Produkthaftung, und die zählt unabhängig von der Gewährleistung unbegrenzt. Daher gibt es ja auch z.B. bei Fahrzeugen Rückrufaktionen. Aber auch bei anderen Produkten. Oder eben Updates (bei Software), da man als Hersteller eines Produkts eben auch nach der Gewährleistung (unter bestimmten Bedingungen) haftet.
EDIT: Produkthaftung bei Konsumentenendgeräten wird wahrscheinlich schwierig, da Sach- oder Personenschaden eintreten muss.
Es ging darum, dass Android dauernd mit Windows oder Linux, bzw. mit Computern verglichen wurde. Das ist schlichtweg falsch. Natuerlich koennen Hersteller Updates anbieten, aber es ist eben aufwendiger als "einfach wie Windows Updates einspielen". Dazu passt die Architektur nicht. Aber genau das geht nicht in die Koepfe einiger.
Es ging darum, dass Android dauernd mit Windows oder Linux, bzw. mit Computern verglichen wurde. Das ist schlichtweg falsch. Natuerlich koennen Hersteller Updates anbieten, aber es ist eben aufwendiger als "einfach wie Windows Updates einspielen". Dazu passt die Architektur nicht. Aber genau das geht nicht in die Koepfe einiger.
Sorry auch wenn die Argumentation eventuell technisch einen Boden hat, inhaltlich hat sie diesen nicht.
Wenn Google und die OEM eine solches Setup im Markt anbieten, dann haben sie auch die Kosten für die entsprechend aufwendige Entwicklung dieser Sicherheitspatches zu tragen. Es ist doch nicht das Problem der Kunden, wenn Hersteller wie Xiamoi hundert verschiedene HW-Konfigurationen anbieten. Dann müssen die Kosten für Sicherheitspatches eben mit in die Produktpreiskalkulation, so einfach ist das.
Microsoft muss mit Windows sicher mindestens genau so viele, wenn nicht mehr mögliche Hardwarekombinationen unterstützen wie Google/Android-Handyhersteller unterstützen müssten.
Apple macht es sich mit aktuell gerade einmal 13 unterstützten Handys ziemlich einfach - aber Microsoft schafft es auch, quasi jede Hardware der letzten 12 Jahre zu unterstützen
Um wirklich einen "Computer" zu haben muesstest du die Gerate komplett anders aufbauen. Das macht wenig Sinn und kostet erstmal enorm Geld, weil es eine komplette Neuentwicklung ist. Von dem her, bitte lasst diese sinnlosen Vergleiche. Wie auch schon jemand anders gesagt hat, es ist ermuedend.
Du hast im Kern der Sache Recht aber das Geld ist imho nicht der springende Punkt, Abstraktion kostet vor allem Performance bzw Effektivität und das kann man im Smartphone eben nicht so einfach durch rohe Leistung kompensieren wie im PC.
Seit Android 8 (gilt nur für Smartphones die 8.0+ bereits zur Auslieferung vorinstalliert hatten) bzw Project Treble geht Google da ja einen sinnvoll erscheinenden Zwischenweg.
njchw schrieb:
Microsoft muss mit Windows sicher mindestens genau so viele, wenn nicht mehr mögliche Hardwarekombinationen unterstützen wie Google/Android-Handyhersteller unterstützen müssten.
Kannst Du das genauer ausführen? Die Abstraktionsebenen beziehen sich meines Wissens nach auf Generic Treiber. Die kann man schon nutzen, ist dann halt ... (Wobei auch der Linux Kernel ganz klar generische Treibersprachen unterstützt, btw)
Windows bekommt es ohne Probleme hin, mir auch den jeweils für meine GPU, mein LAN oder auch meinen Soundchip den genau entsprechenden (aktuellen!) Low-Level Hersteller Treiber zu installieren.
Wieso sollte das bei Google denn nicht möglich sein? Eine Art WHQL Zertifikat welches die OEM/Chiphersteller beantragen müssen. Wenn erhalten, kann man entsprechend direkt in die Google-Update Datenbank posten.
Weiterhin betreffen Sicherheitspatches zu 90% Kernel oder Userland Patches. Die müssten von Google bereitgestellt, von den jeweiligen Herstellern für ihre Geräte validiert und dann veröffentlicht werden. Das alles natürlich zeitnah.
Da kann auch niemand kommen und sagen das wäre technisch unmöglich. Das ist einzig und alleine mit Kosten verbunden, die Günstig-Hersteller oder Geräte für 200€ eben nicht in ihrer Produktpreiskalkulation drinnen haben. Aber nochmal, das ist sicherlich nicht Problem des Kunden.
Fuer euch beide: Der Unterschied ist schlicht und einfach, dass ein Smartphone eigentlich ein Embedded Device ist und eben kein Computer. Die komplette Architektur, Software, Hardware, ist darauf ausgelegt. Gegenueber einem Computer hat ein Smartphone so gut wie keine Abstraktionsebenen. Deswegen hat man ja fuer jedes Smartphone sein eigenes ROM. Da ist alles drin was benoetigt wird mit der Hardware zu kommunizieren. Du kannst nicht einfach Treiber wechseln oder aehnliches. Das Android auf Linux aufbaut hat absolut nichts mit einer Linux Computer Distribution zu tun. Es gibt genug Embedded devices die auf Linux aufbauen aber genau die gleichen Probleme haben.
Um wirklich einen "Computer" zu haben muesstest du die Gerate komplett anders aufbauen. Das macht wenig Sinn und kostet erstmal enorm Geld, weil es eine komplette Neuentwicklung ist. Von dem her, bitte lasst diese sinnlosen Vergleiche. Wie auch schon jemand anders gesagt hat, es ist ermuedend.
Danke für die Erläuterungen.
Weisst du auch wie es technisch bei Windows on ARM Geräten aussieht, die z.B. mit dem Snapdragon 850 ausgestattet sind?
das ist ja auch ein SoC. Wird es dann hier wahrscheinlich auch nach wenigen Jahren keine Updates mehr geben, weil weniger abstrahiert wird oder läuft das in diesem Fall anders?
Man kann auch ein Problem konstruieren, wo keines ist. Natürlich habe ich bezogen auf den SoC weniger einzelne Treiberebenen. Ich habe aber auch anstatt fünf verschiedenen, einen Hersteller und Treiberlieferanten. Somit gleicht sich das doch ganz gut aus.
Dieser Hersteller, ob nun Samsung, Snapdragon oder TI müssten ihre Treiber für ihre SoC per Zertifikat in eine Google-Update-Datenbank einreichen können. Das ist doch kein Hexenwerk.
Bei Microsoft läuft es doch nicht anders. Die supporten ausschließlich Geräte auf denen WHQL Treiber laufen. Alles andere wird abgelehnt und erstmal um "clean-install" gebeten. Genauso, müsste Google es auch machen. Sicherheitspatches werden nur an Geräten supported, die entsprechend seitens Google und Hersteller validierte und aktuelle Treiber drauf haben. Alle Hersteller die das nicht liefern, erhalten keinen offiziellen Google-Support. Genauso wie Hersteller ohne Windows WHQL keinen offiziellen MS Support erhalten.
Ja. Nun hat man aber die Wahl, die Daten einem Betriebssystem Hersteller zu geben oder zusätzlich allen die etwas auf dem Betriebssystem anbieten.
Durch zu aggressive oder nachteilige Einflussnahme verliert bzw. Microsoft viel Geld durch ein schlechteres Image. Dadurch hält sich Microsoft beispielsweise an sehr viele Regeln.
Machen das aber tausende von Betrügern, die sich an keine Regeln halten, können die nichts verlieren, weil die keinen Ruf haben.
Man kann nur eine Person in sein Haus lassen, die von einem abhängig ist und es abschließen oder völlig offen lassen und jede Person von der Straße rein lassen.
Windows bekommt es ohne Probleme hin, mir auch den jeweils für meine GPU, mein LAN oder auch meinen Soundchip den genau entsprechenden (aktuellen!) Low-Level Hersteller Treiber zu installieren.
Der Aufbau ist bei Windows grundlegend anders als bei Android, du hast das eigentliche Windows und getrennt davon die Treiber die sicherstellen dass die Hardware mit Windows kommunizieren kann. Microsoft macht die Vorgaben und die Hardwarehersteller stellen kompatible Treiber zur verfügung.
Bei Android ist das alles direkt integriert, du kannst nicht einen einzelnen Treiber tauschen ohne das komplette Image neu kompilieren zu müssen. Jeder Smartphonehersteller muss jeden einzelnen Hardwaretreiber erst in das jeweilige ROM integrieren und das Gesamtpaket dann veröffentlichen.
Seit Project Treble ist das nicht mehr ganz so extrem wie vorher so dass das Android OS Framework unabhängig von der Vendor Implementation aktualisiert werden kann. https://source.android.com/devices/architecture
Sorry auch wenn die Argumentation eventuell technisch einen Boden hat, inhaltlich hat sie diesen nicht.
Wenn Google und die OEM eine solches Setup im Markt anbieten, dann haben sie auch die Kosten für die entsprechend aufwendige Entwicklung dieser Sicherheitspatches zu tragen. Es ist doch nicht das Problem der Kunden, wenn Hersteller wie Xiamoi hundert verschiedene HW-Konfigurationen anbieten. Dann müssen die Kosten für Sicherheitspatches eben mit in die Produktpreiskalkulation, so einfach ist das.
Erstmal, Google und die OEMs muessen gar nichts ausser Profit machen. Es sind Firmen. Ich habe technisch dargestellt, warum es eben nicht ein Computer ist und deshalb schlichtweg nicht vergleichbar ist. Vergleiche es lieber mit einem Router. Die Firmen werden Sicherheitspatches anbieten, wenn es fuer sie profitabel ist, oder die Kunden einfach nicht mehr ihre Geraete kauft. Das ist aber ein komplett anderes Thema.
njchw schrieb:
Microsoft muss mit Windows sicher mindestens genau so viele, wenn nicht mehr mögliche Hardwarekombinationen unterstützen wie Google/Android-Handyhersteller unterstützen müssten.
Apple macht es sich mit aktuell gerade einmal 13 unterstützten Handys ziemlich einfach - aber Microsoft schafft es auch, quasi jede Hardware der letzten 12 Jahre zu unterstützen
Einfach nein. Lies meinen ersten Post hier im Thread. Smartphone = Embedded Device != Computer.
NoD.sunrise schrieb:
Du hast im Kern der Sache Recht aber das Geld ist imho nicht der springende Punkt, Abstraktion kostet vor allem Performance bzw Effektivität und das kann man im Smartphone eben nicht so einfach durch rohe Leistung kompensieren wie im PC.
Seit Android 8 (gilt nur für Smartphones die 8.0+ bereits zur Auslieferung vorinstalliert hatten) bzw Project Treble geht Google da ja einen sinnvoll erscheinenden Zwischenweg.
Ja, Performance und Energie sind da beide auch vorne mit dran. Man packt nicht 50 Abstraktionsebenen auf ein Geraet bei dem man den Overhead sofort in der Laufzeit bemerkt. Treble ist in der tat ein guter Schritt, ich bin gespannt wie sich das auswirkt.
Kannst Du das genauer ausführen? Die Abstraktionsebenen beziehen sich meines Wissens nach auf Generic Treiber. Die kann man schon nutzen, ist dann halt ... (Wobei auch der Linux Kernel ganz klar generische Treibersprachen unterstützt, btw)
Windows bekommt es ohne Probleme hin, mir auch den jeweils für meine GPU, mein LAN oder auch meinen Soundchip den genau entsprechenden (aktuellen!) Low-Level Hersteller Treiber zu installieren.
Wieso sollte das bei Google denn nicht möglich sein? Eine Art WHQL Zertifikat welches die OEM/Chiphersteller beantragen müssen. Wenn erhalten, kann man entsprechend direkt in die Google-Update Datenbank posten.
Weiterhin betreffen Sicherheitspatches zu 90% Kernel oder Userland Patches. Die müssten von Google bereitgestellt, von den jeweiligen Herstellern für ihre Geräte validiert und dann veröffentlicht werden. Das alles natürlich zeitnah.
Da kann auch niemand kommen und sagen das wäre technisch unmöglich. Das ist einzig und alleine mit Kosten verbunden, die Günstig-Hersteller oder Geräte für 200€ eben nicht in ihrer Produktpreiskalkulation drinnen haben. Aber nochmal, das ist sicherlich nicht Problem des Kunden.
So weit ich weiss bezieht sich die Abstraktion auf fast alle Geraetetreiber. Die Idee ist, dass dein ROM nur noch mit der Abstraktionsebene spricht. Deswegen brauchst du eine Vendor-Partition, die die Treiber enthaelt. Falls das sinnvoll umgesetzt ist reicht ein ROM fuer alle Geraete. Du hast halt mehr Overhead, brauchst mehr Performance und verlierst Laufzeit.
Noch einmal, ein Smartphone ist kein Computer und nicht vergleichbar mit Windows. Derzeit sind die Treiber direkt im ROM enthalten. Da ist nichts mit installieren oder nachladen. Noch einmal, die Architektur ist schlicht und einfach nicht so aufgebaut wie bei einem Computer.
Technisch unmoeglich sind Userland Patches nicht, nein, aber eben auch hier wieder aufwendig. Kernel Patches sind natuerlich aufwendiger.
Das Problem des Kunden ist, dass er Software-Updates nicht mit in die Bewertung eines Geraetes einbezieht. Und ja, das ist das Problem des Kunden. Man kann gerne fordern laenger Updates verfuegbar zu machen, aber die Firmen muessen es nicht. Der Druck muss vom Kunden kommen, den es aber nicht kuemmert.
phoenixtr schrieb:
Danke für die Erläuterungen.
Weisst du auch wie es technisch bei Windows on ARM Geräten aussieht, die z.B. mit dem Snapdragon 850 ausgestattet sind?
das ist ja auch ein SoC. Wird es dann hier wahrscheinlich auch nach wenigen Jahren keine Updates mehr geben, weil weniger abstrahiert wird oder läuft das in diesem Fall anders?
Das ist eine gute Frage, hier muss ich aber passen. Ich habe mir Windows on ARM nicht wirklich angeschaut. Es kann aber gut sein, dass Microsoft hier nur sehr wenige SoCs zulaesst und der Aufwand sich in Grenzen haelt. Aber vielleicht kennt sich jemand mehr aus.
Man kann auch ein Problem konstruieren, wo keines ist. Natürlich habe ich bezogen auf den SoC weniger einzelne Treiberebenen. Ich habe aber auch anstatt fünf verschiedenen, einen Hersteller und Treiberlieferanten. Somit gleicht sich das doch ganz gut aus.
Dieser Hersteller, ob nun Samsung, Snapdragon oder TI müssten ihre Treiber für ihre SoC per Zertifikat in eine Google-Update-Datenbank einreichen können. Das ist doch kein Hexenwerk.
Bei Microsoft läuft es doch nicht anders. Die supporten ausschließlich Geräte auf denen WHQL Treiber laufen. Alles andere wird abgelehnt und erstmal um "clean-install" gebeten. Genauso, müsste Google es auch machen. Sicherheitspatches werden nur an Geräten supported, die entsprechend seitens Google und Hersteller validierte und aktuelle Treiber drauf haben. Alle Hersteller die das nicht liefern, erhalten keinen offiziellen Google-Support. Genauso wie Hersteller ohne Windows WHQL keinen offiziellen MS Support erhalten.
Nochmals, Smartphone = Embedded Device != Computer. Das funktioniert so nicht. Dann musst du gleich noch alle Hersteller dazu verdonnern, dass Bootloader, Recovery, Partitionen, etc. entweder alle gleich sind, oder doch sehr aehnlich. Kann man versuchen, wird aber wahrscheinlich nicht klappen. Ausserdem hast du nicht nur einen Hersteller und einen Treiberlieferanten. Du hast zwar viel auf dem SoC, aber eben nicht alles. Alleine die Tatsache, dass man Treiber mit in das ROM kompilieren muss sollte doch klar machen, dass deine Idee nicht so wirklich funktioniert.
Deswegen and ich und alle anderen die mit dem Windows/Linux Vergleich kommen, schaut euch an was ein Embedded Device ist, schaut euch den Hardware/Software Aufbau an und schaut es euch bei einem Smartphone an. Hier wird viel Unwissen vorgebracht und dadurch sind die Vorschlaege nicht wirklich sinnvoll und helfen nicht. Deswegen, erkundigen und lernen.
Ich bin mit meinem S6 zufrieden, das letzte Update ist der Patch von Juni 2018, da kann man nicht meckern für ein Android-Gerät von Anfang 2015.
Man muss sich halt vorher informieren was so geboten wird.
So gesehen wird es wohl als Nachfolger ein Samsung Gerät der S-Serie werden.
Danke, war mir nicht bewusst, dass Google da soweit vom Linux-Standard abweicht. Aber wie darf ich das genau verstehen? Der Android ROM ist eigentlich gar kein ROM sondern in wirklichkeit die root-partition mit Schreibschutz?
Ich habs mal kurz überflogen, aber wie kann ein ROM ein ROM sein, wenn er neu beschrieben werden kann?
Nehme also mal an damit ist die read-only Root-Partition gemeint.
Aber dann sehe ich da auch wieder keinen großen Fehler. Im Standard läuft es doch so, dass Linux einen zweiten Kernel mit neu komplierten Treibern live bootet. Ist der Vorgang erfolgreich abgeschlossen wird der Userland dem neuen Kernel übergeben und der alte gecancelt. Wieso sollte so etwas bei Droid nicht möglich sein?
Ergänzung ()
Kacha schrieb:
Erstmal, Google und die OEMs muessen gar nichts ausser Profit machen. Es sind Firmen. Ich habe technisch dargestellt, warum es eben nicht ein Computer ist und deshalb schlichtweg nicht vergleichbar ist. Vergleiche es lieber mit einem Router. Die Firmen werden Sicherheitspatches anbieten, wenn es fuer sie profitabel ist, oder die Kunden einfach nicht mehr ihre Geraete kauft. Das ist aber ein komplett anderes Thema.
Naja und hier steckt halt mein Punkt begraben. Meiner Ansicht nach sind Sicherheitslücken Gewährleistungsmängel die vom Hersteller gesetzlich gepatcht werden müssten.
So weit ich weiss bezieht sich die Abstraktion auf fast alle Geraetetreiber. Die Idee ist, dass dein ROM nur noch mit der Abstraktionsebene spricht. Deswegen brauchst du eine Vendor-Partition, die die Treiber enthaelt.
Letztlich stammen die aus Pre-Internet Zeiten. Damit ein Gerät überhaupt mal in einen Zustand gesetzt werden konnte, mit dem man weitere Treiber installieren konnte.
Noch einmal, ein Smartphone ist kein Computer und nicht vergleichbar mit Windows.
Derzeit sind die Treiber direkt im ROM enthalten. Da ist nichts mit installieren oder nachladen. Noch einmal, die Architektur ist schlicht und einfach nicht so aufgebaut wie bei einem Computer.
Und hier halte ich die grundlegende Architektur für verbesserungswürdig. Du kannst ja im Umkehrschluss schlecht behaupten, eine rootfs-driver-partition ist für Embedded-Devices zwingend notwendig.
Ich denke, es ist nur der für Google und Hersteller günstigste Weg. Siehe wieder oben, Gewährleistung etc. Sollte nicht Problem des Kunden sein.
Nochmals, Smartphone = Embedded Device != Computer. Das funktioniert so nicht. Dann musst du gleich noch alle Hersteller dazu verdonnern, dass Bootloader, Recovery, Partitionen, etc. entweder alle gleich sind, oder doch sehr aehnlich.
Entweder verdonnere ich die Hersteller dazu und biete im Gegenzug an die Patchlevel-Pflege zu übernehmen.
Oder ich verlagere auf die Hersteller, stelle Patches zur Verfügung und sage:
Implementierung und Validierung: Euer Problem.
Ausserdem hast du nicht nur einen Hersteller und einen Treiberlieferanten. Du hast zwar viel auf dem SoC, aber eben nicht alles.
Das ist mir klar. Ich wollte nur darauf hinaus, dass durch die eine Abstraktionsebene beim SoC eben auch wiederum nur noch ein Ansprechpartner da ist, wo z.B. für Microsoft fünf oder sechs Firmen unter einem Hut wären. Daher gleicht sich die Schwierigkeit imho aus.
Alleine die Tatsache, dass man Treiber mit in das ROM kompilieren muss sollte doch klar machen, dass deine Idee nicht so wirklich funktioniert.
Siehe oben. Ich halte das Konzept schlicht für sub-optimal, respektive Problemverlagerung auf den Kunden.
Deswegen and ich und alle anderen die mit dem Windows/Linux Vergleich kommen, schaut euch an was ein Embedded Device ist, schaut euch den Hardware/Software Aufbau an und schaut es euch bei einem Smartphone an.
Wie oben bereits erwähnt. Ich bezweifel, dass ein embedded-Gerät per-se nicht in der Lage sein sollte ein Update so durchzuführen, (Kernel-Replika / Kompilierung im Live-Sys) wie es bei Linux seit Jahren gängiger Standard ist.
Richtig ist, ein embedded-device welches auf Treibern im RootFS basiert, benötigt stehts ein komplettes Image zum Update. Und wie gesagt, das Konzept sagt mir nicht zu.
Microsoft muss mit Windows sicher mindestens genau so viele, wenn nicht mehr mögliche Hardwarekombinationen unterstützen wie Google/Android-Handyhersteller unterstützen müssten.
Nun Microsoft erwartet von der Hardware bestimmte Dinge die gegeben sein sollen Kompatibilität mit IA32 (x86) mit NX-Bit Support ab Windows 8 für 32-Bit vorausgesetzt (schließt diverse Pentium Ms aus) oder Kompatibilität zu x64 oder jetzt neuerlich ARMv8?! Das darf Google nicht erwarten...
Und wie viel Performance geht bei Windows an dem ganzen Overhead flöten? Es ist ja kein Zufall oder Unfähigkeit der MS Programmierer dass sich ein Smartphone oft mal flotter anfühlt als ein Windows PC.
Wer wäre denn bereit Akkulaufzeit und flüssige Bedienung auf dem Altar der Zentralupdates zu opfern?
Mit voller Abstraktion wäre Android niemals konkurrenzfähig zu iOS gewesen.
Google hat ganz pragmatisch so mit Android angefangen wie es eben praktikabel war und setzt jetzt (auch dank steigender Hardwarepower) mehr und mehr in Richtung Abstraktion um.
Danke, war mir nicht bewusst, dass Google da soweit vom Linux-Standard abweicht. Aber wie darf ich das genau verstehen? Der Android ROM ist eigentlich gar kein ROM sondern in wirklichkeit die root-partition mit Schreibschutz?
Ich habs mal kurz überflogen, aber wie kann ein ROM ein ROM sein, wenn er neu beschrieben werden kann?
Nehme also mal an damit ist die read-only Root-Partition geeinigt.
Aber dann sehe ich da auch wieder keinen großen Fehler. Im Standard läuft es doch so, dass Linux einen zweiten Kernel mit neu komplierten Treibern live bootet. Ist der Vorgang erfolgreich abgeschlossen wird der Userland dem neuen Kernel übergeben und der alte gecancelt. Wieso sollte so etwas bei Droid nicht möglich sein?
Deswegen hast du den Recovery-Modus. Dort kannst du die read-only Root-Partition ueberschreiben, aber halt nur ganz. Deswegen kannst du das schlicht vergessen mit on the fly Kernel wechseln. In die Recovery kommst du in der Regel auch nur mit Neustart.
Sun_set_1 schrieb:
@NoD.sunriseNaja und hier steckt halt mein Punkt begraben. Meiner Ansicht nach sind Sicherheitslücken Gewährleistungsmängel die vom Hersteller gesetzlich gepatcht werden müssten.
Das ist etwas schwerer zu bewerten. Was war mit Software als Internet noch nicht wirklich vorhanden war? Wenn es dort Bugs gab dann viel Spass. Heute hast du einfach nur die Moeglichkeit es schnell zu fixen, aber soll daraus ein Anspruch darauf entstehen? Denn sobald du patcht veraenderst du das Produkt das ausgefliefert wurde und dann koennte man auch sagen ab sofort hast du keinen Anspruch mehr, weil es ja nicht mehr das Produkt im Ausgangzustand ist auf das die Gewaehrleistung gilt. Das ganze ist etwas knifflig.
Sun_set_1 schrieb:
@NoD.sunrise
Letztlich stammen die aus Pre-Internet Zeiten. Damit ein Gerät überhaupt mal in einen Zustand gesetzt werden konnte, mit dem man weitere Treiber installieren konnte.
Ja und nein, die derzeitige Architektur ist durchaus valide. Ich kann verstehen warum es so gewaehlt wurde, vor allem zu dem Zeitpunkt als die ersten Smartphones veroeffentlicht wurden.
Sun_set_1 schrieb:
@NoD.sunriseUnd hier halte ich die grundlegende Architektur für verbesserungswürdig. Du kannst ja im Umkehrschluss schlecht behaupten, eine rootfs-driver-partition ist für Embedded-Devices zwingend notwendig.
Ich denke, es ist nur der für Google und Hersteller günstigste Weg. Siehe wieder oben, Gewährleistung etc. Sollte nicht Problem des Kunden sein.
Sicher ist es guenstig und einer der Gruende, aber es ist eben auch effizienter. Klar kann man das weiter in Richtung Linux machen, man muss halt mit den Nachteilen leben. Ist ja jetzt nicht so als gaebe es nur Vorteile. Genauso, was ist denn wenn der Treiberhersteller einfach keine Lust mehr hat seine alten Treiber weiter zu entwickeln? Willst du den dann auch zwingen weiter zu machen?
Sun_set_1 schrieb:
@NoD.sunriseEntweder verdonnere ich die Hersteller dazu und biete im Gegenzug an die Patchlevel-Pflege zu übernehmen.
Oder ich verlagere auf die Hersteller, stelle Patches zur Verfügung und sage: Implementierung und Validierung: Euer Problem.
Mit der derzeitigen Architektur und dem Wunsch der Hersteller nach Individualisierung, ganz klar das zweite. Google wuerde nur ein Stock-Android anbieten und das war es. Das werden einige Hersteller nicht moegen.
Sun_set_1 schrieb:
@NoD.sunrise
Das ist mir klar. Ich wollte nur darauf Hinaus dass durch die eine Abstraktionsebene beim SoC eben auch wiederum nur noch ein Ansprechpartner da ist, wo z.B. für Microsoft fünf oder sechs Firmen unter einem Hut wären. Daher gleicht sich die Schwierigkeit imho aus.
Wie gesagt, es gibt mehr als den SoC. Was wohl schnell Aufwand werden kann ist die Kamera mit all den Moeglichkeiten die die Chips bieten. Zumindest haben Custom ROMs da nicht immer Spass mit.
Sun_set_1 schrieb:
@NoD.sunrise
Siehe oben. Ich halte das Konzept schlicht für sub-optimal, respektive Problemverlagerung auf den Kunden.
Wie oben bereits erwähnt. Ich bezweifel, dass ein embedded-Gerät per-se nicht in der Lage sein sollte ein Update so durchzuführen, (Kernel-Replika / Kompilierung im Live-Sys) wie es bei Linux seit Jahren gängiger Standard ist.
Richtig ist, ein embedded-device welches auf Treibern im RootFS basiert, benötigt stehts ein komplettes Image zum Update. Und wie gesagt, das Konzept sagt mir nicht zu.
Man kann es nicht moegen, ja, man kann auch andere Vorschlaege machen und mittlerweile duerfte es bestimmt Alternativen geben. Allerdings haben die halt auch immer Nachteile. Es gibt einen Grund fuer Embedded Devices und der ist schlichtweg Energieeffizienz. Und zu dem Zeitpunkt als Smartphones rauskamen war das ein wichtiger Punkt. Das jetzt zu aendern wird schwer.
Ich finde den Schritt von Google absolut richtig. Der Support alle Android Geräte muss besser werden!!!
Ja man sagt es sei so aufwändig ein Update zu schreiben. Mag sein. Ich denke einfach dass Hersteller sich nicht mehr mit alten Geräten beschäftigen wollen, wenn es doch schon neue gibt.
1. Finde ich den Zyklus viel zu schnell. Oft schaffen es Teilehersteller gar nicht so schnell neue Chips oder Kameras zu bauen. Huawei und Co schmeißen öfter neue Handys auf den Markt, als ich meine Unterhose wechsle. Also oft hat der Nachfolger den selben Chip bzw Kamera (Pixel 2/3 oder Oneplus 6/6T).
2. Wenn das neue Gerät auf dem Markt ist, will der Hersteller sich um das aktuelle Gerät kümmern und dass es gut läuft. Die älteren werden vernachlässigt.
3. Finde ich es wirklich schade, weil private Softwareentwickler oft bessere und neuere Software bauen können, als renommierte Hersteller. Sogar auf mein Nexus S von Google, sorgte Cyanogenmod für neuere Android Versionen.
4. Neue Android Version. Wollte Google den Zyklus nicht verlangsamen? Alle 2-3 Jahre eine neue Android Version? Ich meine was kann Pie so viel besser? Hauptsächlich wurde an der UI gefeilt und die Geschwindigkeit verbessert. Auf mein Nokia 7+. Dazu brauch es doch kein neues Android.
Ich bin gespannt was da nun mit Fuchsia wird. Vielleicht wollen die da hin wo Apple ist.
Ja das stimmt. So war es auch bei Windows Phone OS. Hersteller können exklusive Apps anbieten und sonst nur mit Android One fahren. Wie z.B Videoplayer, Video Editor, Galerie oder ein Musikplayer. Das wäre für mich ideal. Immerhin hat man da 3 Jahre Support.
Aber von Heute auf Morgen kann das Google auch nicht verbieten. Hersteller drehen durch. Wahrscheinlich schaut man erst einmal mit Android One wie es klappt. Dennoch hat Android One viele Problemchen. Mein Update zu Pie lief schief. Ich musste ein Hardreset machen. Jetzt läuft es. Es scheint also schon kompliziert zu sein.
Ich wünsche mir ein Android One Gerät preislich zwischen den Nokia 7+ und Pixel 2/3. Sowas wie ein Galaxy S8 oder OnePlus 6 mit Android One. Und kleiner als 150mm.
