Samsung, Exynos und AOSP erklärt: Eine Geschichte des Verrats

Denken Sie daran, erinnern Sie sich an den ersten Teil der Notiz, der ICS-Veröffentlichung und der Handlung

Ich weiß keinen Grund, warum der Superbrick-Verrat jemals vergessen werden sollte

Ältere Forumsmitglieder und Android-Benutzer früher Samsung-Geräte erinnern sich möglicherweise schwach daran Superbrick-Fiasko. Die Ereignisse, die zu Superbrick führen, sind langwierig und komplex. Der Kürze halber ein tl; Die Erklärung von Dr. ist, dass ein durchgesickertes ICS-Update für einige Trägervarianten des Galaxy S2 i9100 und des Galaxy Note N7000 einen verursacht hat dauerhafter Ziegelstein. Dies war kein gewöhnlicher Hard Brick, da ein betroffenes Gerät nicht über JTAG wiederbelebt werden konnte und völlig tot war und nicht reagierte. Der Superbrick beeinträchtigte die eMMC des Geräts und daher konnten Reparaturen nur durch einen vollständigen Austausch des Motherboards durchgeführt werden.

Der Haftungsausschluss, der im Allgemeinen mit „Leaks“ einhergeht, galt auch in diesem Fall, dass es sich bei Leaks im Wesentlichen um „unveröffentlichte“ Software handelt, die möglicherweise für den öffentlichen Gebrauch geeignet ist oder auch nicht. Um die Sache jedoch noch komplizierter zu machen, gelangte dieser Super-ICS-Kernel tatsächlich als offizielle Version, die über Kies und OTA-Updates verfügbar ist, auf das Galaxy Note N7000.

Das Superbrick-Fiasko und das damit einhergehende Drama, das sich aufgrund der Haltung von Samsung gegenüber Entwicklern entwickelte, wurden in einer Serie mit 13 Beiträgen von Andrew Dodd alias XDA Senior Recognized Developer beleuchtet Entropie512 auf seinem Google+. Den Anfang dieser Beitragsreihe finden Sie hier Hier. Wir sehr empfehlenswert dass sich die Leser eine Auszeit nehmen und die gesamte Beitragsreihe lesen, um sich ein vollständiges Kontextbewusstsein zu verschaffen und den ganzen Ernst der Situation zu verstehen, die sich 2012/13 ereignete.

Um einige wichtige Punkte hervorzuheben, hier ein paar Ausschnitte (mit zusätzlicher Hervorhebung) aus den Beiträgen:

"...Natürlich ist sich fast jeder, der mir folgt, des jüngsten Social-Media-Sturms bewusst, der aus der Frustration der Menschen resultiert Android-Firmware-Community von Drittanbietern (insbesondere CyanogenMod-Benutzer und -Entwickler) hat damit Erfahrungen gemacht Samsung. Das „Superbrick“-Fiasko, die mangelnde Dokumentation des Exynos4-SoCs von Samsung im Vergleich zu den SoCs von Qualcomm und TI und eine lange Liste anderer Probleme – all das hat sich in letzter Zeit zugespitzt die Entscheidung aller derzeit aktiven Exynos4-Gerätebetreuer, keine neuen Geräte zu übernehmen..." - Elternbeitrag.

"...Im November veröffentlichte Samsung XWKK5 für I9100 und UCKK6 für I777. Bluetooth HID würde bei diesen Builds nicht mit von der Quelle erstellten Kerneln funktionieren – nur mit Binärdateien, die diesen Builds zugeordnet sind. Samsung hat nie wieder ein Gingerbread-Quellupdate für den I9100 veröffentlicht, obwohl die Binärdateien eindeutige Hinweise auf eine funktionale Änderung der Quelle zeigten. Ebenso wurde die UCKK6-Quelle für I777 erst zu einem unbekannten Zeitpunkt Mitte 2012 veröffentlicht – ich bin mir ziemlich sicher, bestenfalls erst nach der Veröffentlichung von I9100 ICS. Das ist richtig – Samsung hat gegen die GPL verstoßen mit I777 UCKK6 und jedem I9100 Gingerbread-Build von XWKK5 (November 2011) bis zur offiziellen Veröffentlichung von I9100 ICS (März 2012) – Eigentlich Technisch gesehen sind sie es immer noch, da die Gingerbread-Quelle, die diesen Kerneln entspricht, nie veröffentlicht wurde, aber das spielt einfach keine Rolle mehr..."

"...Etwa zur gleichen Zeit brachte Samsung das Tab 7.0 Plus und das Tab 7.7 auf den Markt, die beide auf dem gleichen Exynos 4210 SoC basieren, der auch im GS2 zu finden ist...Diese Geräte verwendeten einen WLAN-Chip der Atheros AR6000-Serie. Interessanterweise stellt Atheros den Quellcode für diese Geräte unter einer Doppellizenz, GPL und BSD, bereit. (Da Atheros das volle Urheberrecht an allen Komponenten seines Referenztreibers besitzt, ist dies legal.) Samsung hat sich für die BSD-Lizenz für diesen Treiber entschieden. Das Endergebnis ist, wenn nach der WLAN-Treiberquelle gefragt wird (die in den Quelldateien für diese Geräte nicht vorhanden war): Samsung antwortete mit „Code ist eine Doppellizenz GPL oder BSD.“ Wir wählen BSD [statt GPL]“..." - Elternbeitrag

"...Wenn aus ICS auf dem GT-I9100 eine offensichtliche Schlussfolgerung gezogen werden konnte, dann diese Hersteller-Skins halten nicht lange. Nachdem die I9100 ICS-Firmware auf dem I777 zum Laufen gebracht wurde (hauptsächlich durch Reverse Engineering der vertauschten Mikrofonkanäle). Dieses Gerät, das den größten Teil eines Wochenendes Arbeit in Anspruch nahm...), war offensichtlich, dass Touchwizz viele der Vorteile zunichte machte ICS. Teile der Firmware waren „neu“, Teile waren „Legacy Gingerbread“ und die ständigen Diskontinuitäten waren erschütternd … - Elternbeitrag

Noch schlimmer... Offizielles ICS für das N7000 mit XXLPY eingeführt. Wir dachten, Samsung würde niemals zulassen, dass ein so schrecklicher Fehler in einen veröffentlichten Kernel gelangt, aber wir haben uns geirrt ...

- Elternbeitrag

"...Ein Kontakt bei Samsung hatte schließlich zugegeben, dass man sich der Situation bewusst sei und „fleißig“ daran arbeite... Schließlich wurde uns Samsungs „Lösung“ präsentiert. Chainfire war mit der vorgeschlagenen „Lösung“ NICHT zufrieden, ich auch nicht... Es beinhaltete keinen Schutz auf Kernel-Ebene und war schlechter als das, was wir bereits mit BOARD_SUPPRESS_EMMC_WIPE in CM hatten. Darüber hinaus baten sie uns, die Lösung nicht zu verbreiten und Kernel-Entwickler, die nach einer Lösung suchten, an sie weiterzuleiten ..."

"... Samsung weigerte sich auch so gut wie, irgendwelche Lösungen mit Bootloadern zu diskutieren... Die Begründung, die keinen Sinn ergab, war, dass fast alle Garantieansprüche wegen benutzerdefinierter Firmware vor diesem eMMC-Defekt auf eine Beschädigung des Bootloaders zurückzuführen waren... Das macht natürlich keinen Sinn, denn Wir wollten Methoden zur Wiederherstellung nach einer Beschädigung des Bootloaders besprechen, die einen Großteil dieser Garantiekosten für Samsung einsparen würden. Wir boten sogar an, den Großteil des Engineerings und der Lösungsbereitstellung selbst zu übernehmen, solange Samsung uns nur einige spezifische kleine Komponenten zur Verfügung stellte, die Dominik und Adam brauchten …"

"...Nachdem Samsung einen Monat lang „fleißig gearbeitet“ hat, wirft es uns eine Granate ins Gesicht

Anfang Juli ist XXLQ5 für den I9100 durchgesickert. Innerhalb eines Tages häuften sich zahlreiche Meldungen über Ziegelsteine. Nicht lange danach ging XWLPM auf Kies live und Auch bei diesem Gebäude wurde links und rechts gemauert.

Trotz der Behauptung, es zu sein fleißig arbeiten Bei diesem Problem hat Samsung stattdessen ein zuvor sicheres Gerät genommen und es gefährdet ...“ – Elternbeitrag

"...Zu diesem Zeitpunkt ist es also Mitte November 2012, und kein einziges Gerät, das von Samsungs defektem eMMC betroffen ist, hat einen Kernel-Fix erhalten. Während die Bemühungen der Community die Schadensraten VIEL senken, solange es die offiziellen Kernel von Samsung sind Wenn ich verwundbar bin, bekomme ich immer noch alle paar Tage eine PN von einem Superbricked-Benutzer, der Hilfe braucht, den ich nicht kann helfen..." - Elternbeitrag

"...Mitte August habe ich mich wider besseres Wissen dazu entschlossen, ein Note 10.1 (WiFi-Variante – GT-N8013) zu kaufen. Ich dachte mir, dass es eine ziemlich sichere Sache wäre, da es ein SoC mit dem I9300 teilt ...

Das hatte ich nun bestätigt, sowohl durch die Nichtfunktionalität des WLAN-Treibers als auch durch verschiedene String-Vergleiche mit dem Backup Standardkernel, dass die veröffentlichten Quellen für jede N80xx-Variante NICHT mit den Standardkerneln übereinstimmten (alle hatten das gleiche kaputte WLAN). Fahrer und andere Leute, die mit den Quellen arbeiteten, beschwerten sich über ähnliche Probleme.), habe ich das Problem bei meinem Ansprechpartner angesprochen Samsung...

Sie machten jemanden ausfindig, und die Antwort dieser Person war: Samsung war nicht verpflichtet, eine Quelle bereitzustellen, die mit dem UEALGB-Build für GT-N8013 übereinstimmte, da es sich nicht um einen offiziellen Build handelte. Ja, das stimmt – tatsächlich jemand wagte es zu behaupten, dass die Firmware, die auf jedem in den USA verkauften GT-N8013-Gerät vorinstalliert war, ein LEAK war. Dies war das dritte Mal, dass jemand bei Samsung Mobile das Gesicht meines Kontakts unverhohlen belogen hat …“ - Elternbeitrag

"...Also dazwischen, andere Dinge (viele Beispiele finden Sie in früheren Teilen dieser Saga) und Superbrick, So ziemlich alle Exynos4-Betreuer waren mit Samsung und insbesondere mit am Rande der Erschöpfung Exynos4.

Ich gab an, dass das Note 10.1 mein letztes Gerät sein würde, und ich war mir nicht sicher, wie lange ich beim I777 und N7000 bleiben würde, da ich zu diesem Zeitpunkt auch erschöpft war.

Ich hatte es satt, dem Rest des Cyanogenmod-Teams Monate hinterherzuhinken, weil ich mit Geräten gearbeitet habe, die mehr Blobs und mehr Schnittstellenunterbrechungen in den Blobs hatten als jedes andere Gerät

(Außer bei Tegra3-Geräten, aber die Leute wussten bereits, dass man diese meiden sollte, es sei denn, sie befanden sich in einem Nexus.)..." - Elternbeitrag

"...Gegen Ende [von BABBQ 2012] fand Samsungs Präsentation zu Entwicklerbeziehungen statt. Hier versprachen sie, die Qualität des Referenzquellcodes und der Dokumentation für Exynos4 zu verbessern und damit theoretisch die Bedenken der Community auszuräumen. Der eigentliche Präsentationsinhalt versprach wenig - Bei fast allem, was sie ankündigten, handelte es sich um Dinge, die technisch bereits existierten, aber kaum oder gar keinen Nutzen hatten, weil sie veraltet oder einfach nicht funktionsfähig waren ..." - Elternbeitrag

All dies ist nur ein weiterer Fall, in dem Samsung redet und Versprechungen macht und es nicht hält, zu halten, so wie sie es schon seit über einem Jahr tun und versprechen. Entwicklungsboards sollen Mobiltelefonen voraus sein – sie müssen sich nicht mit Netzbetreibertests befassen, Wireless-Zertifizierungen oder andere Dinge, die normalerweise dafür bekannt sind, Mobiltelefone zurückzuhalten Aktualisierung. Außerdem sind die Entwickler ihr eigentliches Ziel, also sollten sie der „Bleeding Edge“ sein. Dies ist die Referenzquelle von Qualcomm und TI – es ist das absolut Neueste, vor allem, was es auf Mobiltelefonen gibt. Was wir von Samsung bekommen, ist mehr als 6 Monate veraltet – ICS für einen SoC, der in einem Mobiltelefon enthalten war, das mit ICS gestartet wurde im Frühjahr 2012 veröffentlicht wurde und Anfang Oktober ein offizielles Jellybean-Update (Anbietergenehmigungen/Wireless-Zertifikate und alles) erhielt 2012... Aber sie arbeiten immer noch an ICS als Referenzquelle???

- Elternbeitrag

Die Serie wurde mit einem zusammenfassenden Beitrag abgeschlossen, der hier zu finden ist Hier. Wir empfehlen allen Benutzern, es zu lesen, bevor Sie fortfahren.

Der Ausgangspunkt dieses Artikels war der Versuch zu erklären, warum Exynos-Geräte im Vergleich zu Qualcomm-Geräten in der Regel an AOSP-basierter Entwicklung scheitern. Die oben erwähnte und zitierte G+-Beitragsreihe beleuchtete die Schwierigkeiten, mit denen ein Betreuer eines Exynos-Geräts konfrontiert ist. Der Beitrag ist auf den Zeitraum 2011–2013 datiert, daher haben wir einige der genannten Entwickler kontaktiert, um herauszufinden, wie die Situation derzeit ist. Schließlich kann sich in der mobilen Welt in drei Jahren viel ändern.

Anscheinend nicht für Samsung und dessen Unterstützung für AOSP.

F: Warum dauert es so lange, bis AOSP-ROMs für Exynos-Geräte verfügbar sind, im Vergleich zu beispielsweise Qualcomm-Geräten?

A: XDA Senior Recognized Developer Codeworkx:

Qualcomm veröffentlicht stets aktuellen Quellcode, der benötigt wird, um alle Komponenten seiner Plattform auf AOSP zum Laufen zu bringen. Sehen Hier.

Samsung unternimmt nichts.

XDA Senior Recognized Developer Entropie512:

"Qualcomm CAF ist in Bezug auf die Rückverfolgbarkeit zu/von OEM-Releases deutlich überlegen (ich habe noch nie ein anderes OEM-Gerät als ein Nexus gesehen, das nicht leicht auf ein CAF-Tag zurückgeführt werden konnte). CodeAurora), Qualität des Codes und Häufigkeit der Aktualisierungen Insignal (Es gibt kein KitKat für den „Arndale Octa“ und nichts Neueres als ICS für den Exynos4.) Abgesehen davon, dass es veraltet ist, gibt es absolut keine Rückverfolgbarkeit zwischen den OEMs von Samsung Mobile Releases und die Exynos-Referenzquelle, während alle OEMs eine ziemlich gute Rückverfolgbarkeit auf CAF haben (HTC und Samsung etwas weniger als andere, aber immer noch weitaus besser als alles andere). Exynos)

Moment, sie haben schließlich JB für das Origen Quad veröffentlicht? Erst als KitKat fast draußen war... Und was sie JB nannten, war wahrscheinlich nahe an der nutzlosen Katastrophe, die ihnen bevorstand Lebkuchen „ICS“

Exynos3, auch bekannt als Hummingbird, war dank des Nexus S eine völlig andere Geschichte, aber Samsung hat seitdem Wert darauf gelegt, niemals einen Chipsatz zwischen Nexus-Geräten und einem seiner anderen Geräte zu teilen. (Das Galaxy Nexus war OMAP4, während alles andere aus dieser Ära mit wenigen Ausnahmen Exynos4 war, Nexus 10 und das Samsung Chromebook waren zwei der einzigen Exynos 5250-Geräte wurden jemals ausgeliefert, Exynos 54xx wechselte zusammen mit einer ganzen Reihe anderer Änderungen von der Mali-GPU zu PowerVR, sodass Manta für den I9500 nutzlos war. usw.)"

F: Wie sieht die Zukunft der Exynos-Entwicklung aus? Welche Schritte könnte Samsung unternehmen, um entwicklungsfreundlicher zu werden?

A: Codeworkx:

Es gibt keine Zukunft. Alle Entwickler, denen Sie geschrieben haben, haben schon vor langer Zeit aufgehört, an Exynos-Geräten zu arbeiten. Die meisten von ihnen hörten sogar auf, generell an Samsung-Geräten zu arbeiten.

Wir haben mehr als einmal nach dem Quellcode gefragt und nichts ist passiert. Die Gemeinschaft ist ihnen einfach egal. Alles, was sie interessiert, ist $$$

Es ist klar, dass die Situation fast dieselbe ist wie vor mehr als drei Jahren. Samsung-Geräte, insbesondere Exynos-basierte Geräte, sind nach wie vor schlechte Beispiele für die Präsentation der Arbeit der Entwicklergemeinschaft außerhalb von Touchwiz-basierten Beispielen. Die gesamte Entwicklung des Geräts beschränkt sich größtenteils auf Modifikationen an Touchwiz, wobei die Szene benutzerdefiniert ist Bei ROMs geht es um das Hinzufügen oder Entfernen von Funktionen zum „Skin“ des Closed-Source-Betriebssystems von Samsung durch Umkehrung Maschinenbau.

Das soll nicht heißen, dass Exynos-Geräte überhaupt keine Unterstützung für AOSP-ROMs erhalten. AOSP-Roms wie CM und dergleichen tun dies letztlich auf diesen Geräten landen, aber sie sind das Ergebnis einer Menge Hackerangriffe auf niedrigem Niveau und extremer Anstrengungen von Betreuern, die mutig genug sind, ihre ganze Freizeit darauf zu verwenden, das zu reparieren, was Samsung kaputt gemacht hat. Selbst dann ist das Endergebnis kein AOSP-Erlebnis, wie man es normalerweise erwarten würde, und dafür können Sie getrost Samsung die Schuld geben.

Die Wunden von Superbrick sind immer noch frisch bei denen, die sich mit Leib und Seele für eine kaputte Sache einsetzen, die sich Samsung nennt. Wenn Sie auf der Suche nach einem Gerät sind, bei dem das erste Kriterium die benutzerdefinierte ROM-Entwicklung und die Unterstützung von ROM-Entwicklern von Drittanbietern ist, befolgen Sie die Weisheiten von Codeworkx:

Hören Sie auf, solche Unternehmen durch den Kauf ihrer Geräte zu unterstützen.

Nehmen Sie ein Sony- oder Nexus-Gerät, erhalten Sie hochwertige AOSP-ROMs, guten Community-Support und seien Sie einfach glücklich.