Heeft u zich ooit afgevraagd waarom Exynos-apparaten niet de beste AOSP-ondersteuning krijgen? Ontdek het in onze samenvatting van de evenementen!
Onthoud, onthoud, de eerste van de notitie, de ICS-release en plot
Ik ken geen reden waarom het verraad van Superbrick ooit vergeten zou worden
Oudere forumleden en Android-gebruikers van vroege Samsung-apparaten herinneren zich misschien vaag de Een geweldig fiasco. De gebeurtenissen die leiden tot Superbrick zijn lang en complex. Kortheidshalve een tl; Dr. verklaring is dat een gelekte ICS-update voor een paar carriervarianten van de Galaxy S2 i9100 en van de Galaxy Note N7000 een permanente baksteen. Dit was geen gewone harde steen, omdat een getroffen apparaat niet via een JTAG tot leven kon worden gewekt en volledig dood was en niet reageerde. De superrick beïnvloedde de eMMC van het apparaat, en daarom konden reparaties alleen worden uitgevoerd met een volledige vervanging van het moederbord.
De disclaimer die doorgaans bij 'lekken' hoort, gold ook in dit geval, namelijk dat lekken in wezen 'niet-uitgebrachte' software zijn die wel of niet geschikt is voor publieke consumptie. Om de zaken echter nog ingewikkelder te maken, vond deze fantastische ICS-kernel zijn weg naar de Galaxy Note N7000 als een officiële release die beschikbaar was via Kies- en OTA-updates.
Het Superbrick-fiasco en het bijbehorende drama dat volgde dankzij de houding van Samsung ten opzichte van ontwikkelaars, werd belicht in een serie van 13 posts door Andrew Dodd, ook bekend als XDA Senior Recognized Developer Entropie512 op zijn Google+. Je kunt het begin van deze berichtenreeks vinden hier. Wij ten zeerste aanbevelen dat lezers wat vrije tijd nemen en de volledige reeks berichten lezen om volledig contextueel bewustzijn te verwerven en de volledige ernst te begrijpen van de situatie die zich in 2012-2013 heeft voorgedaan.
Om een paar belangrijke punten te benadrukken, zijn hier een paar fragmenten (met extra nadruk) uit de berichten:
"...Het is duidelijk dat bijna iedereen die mij volgt zich bewust is van de recente storm op de sociale media als gevolg van de frustratie van de Android-firmwaregemeenschap van derden (vooral gebruikers en ontwikkelaars van CyanogenMod) heeft er ervaring mee Samsung. Het "Superbrick"-fiasco, het gebrek aan documentatie van Samsung's Exynos4 SoC vergeleken met de SoC's van Qualcomm en TI, en een waslijst aan andere problemen - het is allemaal onlangs tot een hoogtepunt gekomen de beslissing van alle momenteel actieve Exynos4-apparaatbeheerders om geen nieuwe apparaten aan te nemen..." - Ouderbericht.
"...In november bracht Samsung XWKK5 voor I9100 en UCKK6 voor I777 uit. Bluetooth HID op deze builds zou niet werken met bron-gebouwde kernels - alleen met binaire bestanden die aan die builds zijn gekoppeld. Samsung heeft nooit meer een Gingerbread-bronupdate voor de I9100 uitgebracht, ook al vertoonden hun binaire bestanden duidelijk bewijs van een functionele wijziging aan de bron. Op dezelfde manier werd de I777 UCKK6-bron pas op een onbekende tijd medio 2012 uitgebracht - ik ben er vrij zeker van dat dit op zijn best pas gebeurde nadat de I9100 ICS was uitgebracht. Dat klopt: Samsung overtrad de GPL met I777 UCKK6 en elke I9100 Gingerbread-build van XWKK5 (november 2011) totdat ze I9100 ICS officieel uitbrachten (maart 2012) - Eigenlijk, technisch gezien zijn ze dat nog steeds, aangezien de Gingerbread-bron die overeenkomt met die kernels nooit is vrijgegeven, maar het maakt gewoon niet zoveel uit meer..."
"...Rond dezelfde tijd lanceerde Samsung de Tab 7.0 Plus en Tab 7.7, beide gebaseerd op dezelfde Exynos 4210 SoC als in de GS2...Deze apparaten gebruikten een wifi-chip uit de Atheros AR6000-serie. Interessant is dat Atheros broncode voor deze apparaten levert onder een dubbele licentie, GPL en BSD. (Aangezien Atheros het volledige auteursrecht op alle componenten van hun referentiestuurprogramma bezit, is dit legaal.) Samsung heeft de BSD-licentie voor dit stuurprogramma gekozen. Het eindresultaat is, wanneer gevraagd wordt naar de wifi-stuurprogrammabron (die niet aanwezig was in de brondroppings voor deze apparaten), Samsung antwoordde met "code is dubbele licentie GPL of BSD. Wij kiezen voor BSD [in plaats van GPL]"..." - Ouderbericht
"...Als er een voor de hand liggende conclusie kon worden getrokken van ICS over de GT-I9100, dan was het die Skins van fabrikanten gaan niet lang mee. Nadat ik de I9100 ICS-firmware op de I777 had laten draaien (voornamelijk door het reverse-engineeren van de verwisselde microfoonkanalen op dit apparaat, dat het grootste deel van een weekend werk in beslag nam...), was het duidelijk dat Touchwizz veel van de voordelen ervan terugkreeg ICS. Delen van de firmware waren "nieuw", delen waren "legacy Gingerbread", en de voortdurende discontinuïteiten waren schokkend ... - Ouderbericht
Nog erger... Officiële ICS gelanceerd voor de N7000 met XXLPY. We dachten dat Samsung nooit een vreselijke bug als deze in een uitgebrachte kernel zou laten terechtkomen, maar we hadden het mis...
- Ouderbericht
"...Een contactpersoon bij Samsung had eindelijk toegegeven dat ze op de hoogte waren van de situatie en er "ijverig aan werkten"... Uiteindelijk werd de ‘oplossing’ van Samsung aan ons gepresenteerd. Chainfire was NIET blij met de voorgestelde "oplossing", ik ook niet... Het omvatte geen bescherming op kernelniveau en was inferieur aan wat we al hadden met BOARD_SUPPRESS_EMMC_WIPE in CM. Bovendien vroegen ze ons om de oplossing niet te distribueren en kernelontwikkelaars om te leiden die naar een oplossing voor hen zochten..."
"...Samsung weigerde ook vrijwel om oplossingen met bootloaders te bespreken... De redenering, die nergens op sloeg, was dat bijna al hun garantieclaims vanwege aangepaste firmware voorafgaand aan dit eMMC-defect te wijten waren aan corruptie van de bootloader... Dit heeft natuurlijk geen zin, aangezien we wilden methoden bespreken om te herstellen van bootloader-corruptie, waardoor het grootste deel van deze garantiekosten voor Samsung zou worden geëlimineerd. We boden zelfs aan om het grootste deel van de engineering en de implementatie van de oplossing zelf te doen, zolang Samsung ons maar een paar specifieke kleine componenten gaf die Dominik en Adam nodig hadden..."
"...Samsung gooit, na een maand "hard gewerkt" te hebben, een granaat in ons gezicht
Begin juli lekte XXLQ5 voor de I9100. Binnen een dag hadden zich talloze meldingen van stenen opgestapeld. Niet lang daarna ging XWLPM live op Kies, en Ook met deze constructie waren mensen links en rechts aan het metselen.
Ondanks dat dit beweerd wordt ijverig werken over dit probleem heeft Samsung in plaats daarvan een voorheen veilig apparaat genomen en het in gevaar gebracht..." - Ouderbericht
"...Dus op dit moment is het midden november 2012 en geen enkel apparaat dat getroffen is door de defecte eMMC van Samsung heeft een kernelfix ontvangen. Terwijl de inspanningen van de gemeenschap de schadecijfers VEEL lager hebben, zolang de officiële kernels van Samsung dat zijn kwetsbaar, ik krijg nog steeds elke paar dagen een PM van een Superbricked-gebruiker die hulp nodig heeft en die ik niet kan hulp..." - Ouderbericht
"...Half augustus besloot ik tegen beter weten in te gaan en een Note 10.1 (WiFi-variant - GT-N8013) aan te schaffen. Ik dacht dat het een redelijk veilige gok zou zijn, omdat het een SoC deelde met de I9300...
Nu had ik dit bevestigd, zowel door de niet-functionaliteit van de wifi-driver, als door verschillende stringvergelijkingen met de back-up stock-kernel, dat de vrijgegeven bronnen voor elke N80xx-variant NIET overeenkwamen met de stock-kernels (ze hadden allemaal dezelfde kapotte wifi driver en andere mensen die met de bronnen werkten, klaagden over soortgelijke problemen.), heb ik de kwestie ter sprake gebracht bij mijn contactpersoon op Samsung...
Ze hebben iemand opgespoord en het antwoord van die persoon was: Samsung was niet verplicht om een bron te leveren die overeenkwam met de UEALGB-build voor GT-N8013, aangezien dat geen officiële build was. Ja, dat klopt, iemand eigenlijk durfde te beweren dat de firmware die vooraf was geïnstalleerd op elke GT-N8013-eenheid die in de Verenigde Staten werd verkocht, een LEKKAGE was. Dit was de derde keer dat iemand binnen Samsung Mobile schaamteloos in het gezicht van mijn contactpersoon had gelogen..." - Ouderbericht
"...Dus daartussen, andere dingen (zie eerdere afleveringen van deze saga voor veel voorbeelden), en Superbrick, vrijwel alle Exynos4-onderhouders waren bij Samsung en vooral bij de grenzen van uitputting Exynos4.
Ik gaf aan dat de Note 10.1 mijn laatste apparaat zou worden, en ik wist niet zeker hoe lang ik bij de I777 en N7000 zou blijven, aangezien ik op dit punt ook uitgeput was.
Ik was het zat om maanden achter te lopen op de rest van het Cyanogenmod-team, omdat ik met apparaten werkte die meer blobs en meer interface-onderbrekingen in de blobs hadden dan welk ander apparaat dan ook
(Behalve Tegra3-apparaten, maar mensen wisten al dat ze deze moesten vermijden, tenzij ze in een Nexus zaten.)..." - Ouderbericht
"... Tegen het einde [van BABBQ 2012] was Samsung's presentatie over ontwikkelaarsrelaties. Dit was waar ze beloofden de kwaliteit van de referentiebroncode en documentatie voor Exynos4 te verbeteren, waardoor in theorie de zorgen van de gemeenschap zouden worden weggenomen. De daadwerkelijke inhoud van de presentatie beloofde weinig - bijna alles wat ze aankondigden was materiaal dat technisch al bestond, maar weinig tot geen nut had omdat het verouderd of simpelweg niet-functioneel was..." - Ouderbericht
Dit alles is gewoon het zoveelste voorbeeld van Samsung die praat en beloftes doet en deze niet nakomt, net zoals ze al meer dan een jaar praten en beloftes doen. Ontwikkelborden worden verondersteld een voorsprong te hebben op handsets - ze hoeven zich niet bezig te houden met carrier-tests, draadloze certificeringen, of een van de dingen die gewoonlijk berucht zijn omdat ze de handset tegenhouden updates. Bovendien zijn hun beoogde doelwit ONTWIKKELAARS, dus zij zouden de "bloedrand" moeten zijn. Dit is wat de referentiebron van Qualcomm en TI is: het is absoluut het nieuwste, vóór alles wat op handsets te zien is. Wat we van Samsung krijgen is meer dan zes maanden verouderd - ICS voor een SoC die in een handset zat die met ICS werd gelanceerd in het voorjaar van 2012, en die begin oktober een officiële Jellybean-update ontving (goedkeuringen van providers/draadloze certificaten en al) 2012... Maar ze werken nog steeds aan ICS als referentiebron???
- Ouderbericht
De serie werd afgesloten met een samenvattende post die hier te vinden is hier. We raden alle gebruikers aan deze te lezen voordat ze verder gaan.
Het startpunt van dit artikel was om te proberen uit te leggen waarom Exynos-apparaten meestal tekortschieten in termen van op AOSP gebaseerde ontwikkeling in vergelijking met Qualcomm-apparaten. De hierboven genoemde en geciteerde G+ postreeks benadrukte de moeilijkheden waarmee een onderhouder van een Exynos-apparaat wordt geconfronteerd. Het bericht dateert uit de periode 2011-2013, dus hebben we contact opgenomen met een aantal van de genoemde ontwikkelaars om erachter te komen hoe de situatie er momenteel voor staat. In de mobiele wereld kan er immers in 3 jaar tijd veel veranderen.
Niet voor Samsung en zijn ondersteuning voor AOSP, zo lijkt het.
Vraag: Waarom duurt het zo lang voordat AOSP ROM's beschikbaar zijn voor Exynos-apparaten, vergeleken met bijvoorbeeld Qualcomm-apparaten?
A: XDA Senior erkende ontwikkelaar codewerkx:
Qualcomm geeft altijd up-to-date broncode vrij die nodig is om alle componenten van hun platform werkend te krijgen op aosp. Zien hier.
Samsung doet niets.
XDA Senior erkende ontwikkelaar Entropie512:
"Qualcomm CAF is enorm superieur in termen van traceerbaarheid naar/van OEM-releases (ik heb nog nooit een ander OEM-apparaat gezien dan een Nexus dat niet gemakkelijk terug te traceren was naar een CAF-tag op CodeAurora), kwaliteit van de code en frequentie van updates Insignaal (die geen KitKat heeft voor de "Arndale Octa" en niets nieuwer dan ICS voor de Exynos4.) Behalve dat het verouderd is, is er absoluut geen traceerbaarheid tussen de OEM's van Samsung Mobile releases en de Exynos-referentiebron, terwijl alle OEM's een redelijk behoorlijke mate van traceerbaarheid hebben terug naar CAF (HTC en Samsung iets minder dan andere, maar nog steeds veel beter dan wat dan ook Exynos)
Wacht, ze hebben uiteindelijk JB uitgebracht voor de Origen Quad? Pas toen KitKat bijna uit was... En wat zij JB noemden, kwam waarschijnlijk dicht in de buurt van de nutteloze ramp die hun overkwam Peperkoek "ICS"
Exynos3, ook bekend als Hummingbird, was een heel ander verhaal dankzij de Nexus S, maar Samsung heeft er sindsdien een punt van gemaakt om nooit meer een chipset te delen tussen Nexus-apparaten en een van hun andere apparaten. (Galaxy Nexus was OMAP4, terwijl al het andere uit die tijd, op een paar uitzonderingen na, Exynos4 was, Nexus 10 en de Samsung Chromebook waren twee van de weinige Exynos 5250-apparaten die ooit zouden worden verzonden, Exynos 54xx schakelde over van Mali GPU naar PowerVR, samen met een hele reeks andere veranderingen, dus manta was nutteloos voor I9500, enz.)"
Vraag: Wat is de toekomst van Exynos Development? Welke stappen kan Samsung ondernemen om zichzelf ontwikkelvriendelijker te maken?
A: Codewerkx:
Er is geen toekomst. Alle ontwikkelaars die je hebt geschreven, zijn al lang geleden gestopt met werken op exynos-apparaten. De meesten van hen stopten zelfs met werken op Samsung-apparaten in het algemeen.
We hebben meer dan eens om de broncode gevraagd, maar er gebeurde niets. Ze geven simpelweg niets om de gemeenschap. Het enige waar ze om geven is $$$
Het is duidelijk dat de situatie vrijwel identiek is aan die van ruim drie jaar geleden. Samsung-apparaten, met name gebaseerd op Exynos, blijven slechte voorbeelden van het presenteren van het werk van de ontwikkelingsgemeenschap buiten de op Touchwiz gebaseerde voorbeelden. Alle ontwikkelingen voor het apparaat blijven grotendeels beperkt tot aanpassingen aan Touchwiz, met maatwerk ROM's draaien om het toevoegen of verwijderen van functies uit de gesloten source OS-skin van Samsung via reverse engineering.
Dit wil niet zeggen dat Exynos-apparaten helemaal geen ondersteuning krijgen voor AOSP ROM's. AOSP Roms, zoals CM en dergelijke, doen dat wel eventueel komen op deze apparaten terecht, maar deze komen na veel hackerij op laag niveau en extreme inspanningen van beheerders die dapper genoeg zijn om al hun vrije tijd te besteden aan het repareren van wat Samsung kapot heeft gemaakt. Zelfs dan is het eindresultaat niet de AOSP-ervaring die je normaal zou verwachten, en hiervoor kun je Samsung gerust de schuld geven.
De wonden van Superbrick liggen nog vers op degenen die zich met hart en ziel inzetten voor een gebroken zaak die zichzelf Samsung noemt. Als je op zoek bent naar een apparaat met als eerste criterium aangepaste ROM-ontwikkeling en ondersteuning voor ROM-ontwikkelaars van derden, volg dan de wijze woorden die door Codeworkx worden gedeeld:
Stop met het ondersteunen van dergelijke bedrijven door hun apparaten te kopen.
Neem een Sony- of Nexus-apparaat, ontvang hoogwaardige aosp-roms, goede community-ondersteuning en wees gewoon gelukkig.