Samsung, Exynos och AOSP Explained: A Story of Betrayal

Kom ihåg, kom ihåg, den första av noten, ICS-utgåvan och handlingen

Jag vet ingen anledning till varför Superbrick-förräderiet någonsin skulle glömmas

Äldre forummedlemmar och Android-användare av tidiga Samsung-enheter minns kanske svagt Superbrick fiasko. Händelserna som leder fram till Superbrick är långa och komplexa. För korthetens skull, en tl; dr förklaring är att en läckt ICS-uppdatering för några bärarvarianter av Galaxy S2 i9100 och Galaxy Note N7000 orsakade en permanent tegel. Detta var ingen vanlig hård tegelsten, eftersom en påverkad enhet inte kunde återupplivas via en JTAG och var helt död och inte svarade. Superbricken påverkade enhetens eMMC, och därför kunde reparationer endast göras med ett fullständigt moderkortsbyte.

Friskrivningsklausulen som i allmänhet går med "läckor" gällde även i detta fall, att läckor i huvudsak är "icke-utgivna" programvara som kan eller kanske inte är lämplig för offentlig konsumtion. Men för att komplicera saken, tog sig denna superbricking ICS-kärna faktiskt till Galaxy Note N7000 som en officiell release tillgänglig via Kies- och OTA-uppdateringar.

Superbrick-fiaskot och det åtföljande dramat som följde till följd av Samsungs attityd gentemot utvecklare lyftes fram i en serie med 13 inlägg av Andrew Dodd aka XDA Senior Recognized Developer Entropy512 på sin Google+. Du kan hitta början på den här inläggsserien här. Vi rekommenderas starkt att läsare tar lite ledigt och läser hela serien av inlägg för att samla in fullständig kontextuell medvetenhet och förstå allvaret i situationen som inträffade 2012-13.

För att lyfta fram några viktiga punkter, här är några utdrag (med extra betoning) från inläggen:

"...Självklart är nästan alla som följer mig medvetna om den senaste sociala mediestormen till följd av frustrationen över tredje parts Android firmware community (särskilt CyanogenMod-användare och utvecklare) har upplevt med Samsung. "Superbrick" fiaskot, bristen på dokumentation av Samsungs Exynos4 SoC jämfört med Qualcomm och TI: s SoCs, och en tvättlista med andra problem - allt har nyligen kommit till en spets med beslutet av alla för närvarande aktiva Exynos4-enhetsunderhållare att inte ta på sig några nya enheter..." - Föräldrainlägg.

"...I november släppte Samsung XWKK5 för I9100 och UCKK6 för I777. Bluetooth HID på dessa builds skulle inte fungera med några källbyggda kärnor - bara med binärfiler associerade med dessa builds. Samsung släppte aldrig en annan Gingerbread-källuppdatering för I9100, även om deras binärer visade tydliga bevis på en funktionell förändring av källan. På samma sätt släpptes inte I777 UCKK6-källan förrän vid en okänd tidpunkt i mitten av 2012 - jag är ganska säker inte förrän efter att I9100 ICS släpptes i bästa fall. Det stämmer - Samsung bröt mot GPL med I777 UCKK6 och varje I9100 Gingerbread byggd från XWKK5 (november 2011) tills de officiellt släppte I9100 ICS (mars 2012) - Faktiskt, tekniskt sett är de fortfarande, eftersom Gingerbread-källan som motsvarar dessa kärnor aldrig släpptes, men det spelar egentligen ingen roll. Mer..."

"...Ungefär samtidigt lanserade Samsung Tab 7.0 Plus och Tab 7.7, båda baserade på samma Exynos 4210 SoC som finns i GS2...Dessa enheter använde ett wifi-chip från Atheros AR6000-serien. Intressant nog tillhandahåller Atheros källa för dessa enheter under en dubbellicens, GPL och BSD. (Eftersom Atheros innehar full upphovsrätt till alla komponenter i deras referensdrivrutin är detta lagligt.) Samsung valde BSD-licensen för denna drivrutin. Slutresultatet är, när du tillfrågas om wifi-drivrutinkälla (som inte fanns i källdroppar för dessa enheter), Samsung svarade med "koden är GPL eller BSD med dubbla licenser. Vi väljer BSD [över GPL]"..." - Föräldrapost

"...Om det fanns någon uppenbar slutsats att dra från ICS på GT-I9100, så var det att tillverkarens skinn håller inte. Efter att ha kört I9100 ICS-firmware på I777 (främst genom att omvända de utbytta mikrofonkanalerna på denna enhet, som tog det mesta av en helgs arbete...), var det uppenbart att Touchwizz återställde många av fördelarna med ICS. Delar av firmware var "nya", delar var "legacy Gingerbread", och de ständiga diskontinuiteterna var skakiga... - Föräldrapost

Ännu värre... Officiell ICS lanserad för N7000 med XXLPY. Vi trodde att Samsung aldrig skulle låta en sådan här hemsk bugg komma in i en släppt kärna, men vi hade fel...

- Föräldrapost

"...En kontakt på Samsung hade äntligen erkänt att de var medvetna om situationen och "jobbade flitigt" med det... Så småningom presenterades Samsungs "lösning" för oss. Chainfire var INTE nöjd med den föreslagna "lösningen", inte heller jag... Det innebar inget skydd på kärnnivå och var sämre än vad vi redan hade på plats med BOARD_SUPPRESS_EMMC_WIPE i CM. Dessutom bad de oss att inte distribuera lösningen och att omdirigera kärnutvecklare som letade efter en lösning till dem..."

"...Samsung vägrade också ganska mycket att diskutera några lösningar som involverade bootloaders... Resonemanget, som inte var meningsfullt, var att nästan alla deras garantianspråk på grund av anpassad firmware före detta eMMC-defekt berodde på korruption av bootloader... Naturligtvis är detta ingen mening, eftersom vi ville diskutera metoder för att återhämta sig från korruption i bootloader, vilket skulle eliminera majoriteten av dessa garantikostnader för Samsung. Vi erbjöd oss ​​till och med att göra större delen av konstruktionen och lösningsdistributionen själva, så länge Samsung bara gav oss några specifika små komponenter som Dominik och Adam behövde..."

"...Samsung, efter att ha "jobbat flitigt" i en månad, kastar en granat i ansiktet på oss

I början av juli läckte XXLQ5 för I9100. Inom ett dygn hade många rapporter om tegelstenar hopat sig. Inte alltför länge efteråt gick XWLPM live på Kies, och folk murade åt vänster och höger med den här konstruktionen också.

Trots att man påstår sig vara det arbetar flitigt på detta problem, istället tog Samsung en tidigare säker enhet och äventyrade den..." - Föräldrapost

"...Så, vid det här laget - det är mitten av november 2012, och inte en enda enhet som påverkas av Samsungs defekta eMMC har fått en kärnfix. Samtidigt som samhällets ansträngningar har sämre skador, så länge Samsungs officiella kärnor är det sårbar, jag kommer fortfarande att få ett PM med några dagars mellanrum från en Superbricked-användare som behöver hjälp som jag inte kan hjälp..." - Föräldrapost

"...I mitten av augusti bestämde jag mig för att gå emot bättre omdöme och köpa en Note 10.1 (WiFi-variant - GT-N8013). Jag tänkte att eftersom det delade en SoC med I9300, skulle det vara ett ganska säkert kort...

Nu när jag hade bekräftat, både genom att wifi-drivrutinen inte fungerar, och olika strängjämförelser med den säkerhetskopierade lagerkärna, att de släppta källorna för någon N80xx-variant INTE matchade lagerkärnorna (alla hade samma trasiga wifi föraren och andra personer som arbetade med källorna klagade över liknande problem.), tog jag upp frågan med min kontakt på Samsung...

De spårade någon, och den personens svar var: Samsung var inte skyldig att tillhandahålla källa som matchade UEALGB-bygget för GT-N8013, eftersom det inte var ett officiellt bygge. Ja, det stämmer – någon faktiskt vågade hävda att den fasta programvaran som var förinstallerad på varje GT-N8013-enhet som säljs i USA var en LÄKA. Detta var tredje gången någon inom Samsung Mobile uppenbart ljugit för min kontakts ansikte..." - Föräldrapost

"...Så mellan det, andra saker (se tidigare delar av den här sagan för många exempel), och Superbrick, i stort sett alla Exynos4-underhållare var på gränsen för utmattning med Samsung och särskilt med Exynos4.

Jag indikerade att Note 10.1 skulle bli min sista enhet, och jag var inte säker på hur länge jag skulle stanna med I777 och N7000, eftersom jag också var utmattad vid det här laget.

Jag var trött på att vara månader efter resten av Cyanogenmod-teamet eftersom jag arbetade med enheter som hade fler blobbar och fler gränssnittsavbrott i blobbarna än någon annan enhet

(Förutom Tegra3-enheter, men folk visste redan att de skulle undvika dessa om de inte fanns i en Nexus.)" - Föräldrapost

"...Nära slutet [av BABBQ 2012] var Samsungs presentation av utvecklarrelationer. Det var här de lovade att förbättra kvaliteten på referenskällkoden och dokumentationen för Exynos4, vilket i teorin skulle lindra samhällets oro. Själva presentationsinnehållet lovade lite - nästan allt de tillkännagav var saker som redan existerade tekniskt men var till liten eller ingen nytta på grund av att det var föråldrat eller helt enkelt inte fungerade..." - Föräldrapost

Allt detta har bara varit ännu ett fall av att Samsung pratar och lovar och misslyckas med att leverera, precis som de har pratat och lovat i över ett år. Utvecklingskort är tänkta att vara FÖRE för telefoner - de behöver inte ta itu med operatörstester, trådlösa certifieringar, eller något av det som vanligtvis är ökänt för att hålla tillbaka luren uppdateringar. Plus att deras avsedda mål är UTVECKLARE, så de borde vara den "blödande kanten". Detta är vad Qualcomm och TI referenskälla är - Det är det absolut senaste, före allt som sett på telefoner. Det vi får från Samsung är mer än 6 månader inaktuellt - ICS för en SoC som fanns i en telefon som lanserades med ICS våren 2012, och som fick en officiell Jellybean-uppdatering (operatörsgodkännanden/trådlösa certifikat och allt) i början av oktober 2012... Men de jobbar fortfarande på ICS för sin referenskälla???

- Föräldrapost

Serien avslutades med ett sammanfattande inlägg som finns här. Vi rekommenderar att alla användare läser den innan de fortsätter.

Utgångspunkten för den här artikeln var att försöka förklara varför Exynos-enheter vanligtvis saknar AOSP-baserad utveckling jämfört med Qualcomm-enheter. Ovannämnda och citerade G+-postserie belyste svårigheterna för en underhållare av en Exynos-enhet. Inlägget är daterat för tidsperioden 2011-2013, så vi tog kontakt med några av de nämnda utvecklarna för att ta reda på hur situationen ser ut just nu. Trots allt kan mycket förändras på 3 år i den mobila världen.

Inte för Samsung och dess stöd för AOSP, verkar det som.

F: Varför tar AOSP ROM så lång tid att komma för Exynos-enheter, jämfört med exempelvis Qualcomm-enheter?

A: XDA Senior Recognized Developer codeworkx:

Qualcomm släpper alltid uppdaterad källkod som behövs för att få alla komponenter i deras plattform att fungera på aosp. Ser här.

Samsung gör ingenting.

XDA Senior Recognized Developer Entropy512:

"Qualcomm CAF är mycket överlägsen när det gäller spårbarhet till/från OEM-utgåvor (jag har aldrig sett en annan OEM-enhet än en Nexus som inte var lätt att spåra tillbaka till en CAF-tagg på CodeAurora), kodkvalitet och uppdateringsfrekvens till Insignal (som inte har någon KitKat för "Arndale Octa" och inget nyare än ICS för Exynos4.) Förutom att vara föråldrad finns det absolut noll spårbarhet mellan Samsung Mobiles OEM releaser och Exynos referenskälla, medan alla OEM har en ganska anständig mängd spårbarhet tillbaka till CAF (HTC och Samsung något mindre än andra, men fortfarande mycket bättre än något annat Exynos)

Vänta, släppte de till slut JB för Origen Quad? Inte förrän KitKat nästan var slut... Och det de kallade JB var förmodligen nära den värdelösa katastrofen som var deras Pepparkaks "ICS"

Exynos3 aka Hummingbird var en helt annan historia tack vare Nexus S, men Samsung har gjort en poäng av att aldrig dela ett chipset mellan Nexus-enheter och någon av deras andra enheter sedan dess. (Galaxy Nexus var OMAP4 medan allt annat från den eran med några få undantag var Exynos4, Nexus 10 och Samsung Chromebook var två av de enda Exynos 5250-enheter som någonsin skulle levereras, Exynos 54xx bytte från Mali GPU till PowerVR tillsammans med en hel massa andra förändringar så manta var värdelös för I9500, etc.)"

F: Vad är framtiden för Exynos Development? Vilka åtgärder kan Samsung vidta för att göra sig mer utvecklarvänliga?

A: Codeworkx:

Det finns ingen framtid. Alla devs du har skrivit till har slutat fungera på exynos-enheter för länge sedan. De flesta av dem slutade till och med att arbeta på samsung-enheter i allmänhet.

Vi har bett mer än en gång om källkod och ingenting hände. De bryr sig helt enkelt inte om samhället. Allt de bryr sig om är $$$

Det är tydligt att situationen är nästan identisk med vad den var för mer än 3 år sedan. Samsung-enheter, specifikt Exynos-baserade, är fortfarande dåliga exempel på att visa upp utvecklingsgemenskapens arbete utanför Touchwiz-baserade exempel. All utveckling för enheten förblir i stort sett begränsad till modifieringar av Touchwiz, med skräddarsydda scen ROM-skivor som kretsar kring att lägga till eller ta bort funktioner från Samsungs "skin" med sluten källkod genom omvänd teknik.

Detta är inte att säga att Exynos-enheter får absolut inget stöd alls för AOSP ROM. AOSP-rom, som CM och liknande, gör det så småningom landar på dessa enheter, men dessa kommer efter mycket hackeri på låg nivå och extrema ansträngningar från underhållare som är modiga nog att ägna all sin lediga tid åt att fixa det som Samsung gick sönder. Inte ens då är slutresultatet en AOSP-upplevelse som du normalt kan förvänta dig, och för detta kan du säkert skylla på Samsung.

Superbricks sår är fortfarande färska på dem som lägger ihop sitt hjärta och sin själ i arbetet mot en trasig sak som kallar sig Samsung. Om du letar efter en enhet där det första kriteriet är anpassad ROM-utveckling och 3:e parts ROM-utvecklarstöd, följ de visdomsord som delas av Codeworkx:

Sluta stödja sådana företag genom att köpa deras enheter.

Ta en sony- eller nexus-enhet, få aosp-roms av hög kvalitet, bra community-support och var helt enkelt nöjd.