Har du nogensinde undret dig over, hvorfor Exynos-enheder ikke får den bedste AOSP-understøttelse? Find ud af det i vores opsummering af begivenheder!
Husk, husk, den første af noten, ICS-udgivelsen og plottet
Jeg kender ingen grund til, hvorfor Superbrick-forræderiet nogensinde skulle blive glemt
Ældre forummedlemmer og Android-brugere af tidlige Samsung-enheder husker muligvis svagt Superbrick fiasko. Begivenhederne, der fører op til Superbrick, er lange og komplekse. For kortheds skyld er en tl; dr forklaring er, at en lækket ICS-opdatering til et par bærervarianter af Galaxy S2 i9100 og Galaxy Note N7000 forårsagede en permanent mursten. Dette var ikke en almindelig hård mursten, da en berørt enhed ikke kunne genoplives via en JTAG og var fuldstændig død og reagerede ikke. Superbricken påvirkede enhedens eMMC, og derfor kunne reparationer kun udføres med et komplet bundkortskift.
Ansvarsfraskrivelsen, der generelt går med "lækager", var også gyldig i denne sag, at lækager i det væsentlige er "uudgivet" software, der måske eller måske ikke er egnet til offentligt forbrug. Men for at komplicere sagerne kom denne superbricking ICS-kerne faktisk til Galaxy Note N7000 som en officiel udgivelse tilgængelig via Kies- og OTA-opdateringer.
Superbrick-fiaskoen og det medfølgende drama, der fulgte med høflighed af Samsungs holdning til udviklere, blev fremhævet i en serie med 13 indlæg af Andrew Dodd alias XDA Senior Recognized Developer Entropi512 på hans Google+. Du kan finde begyndelsen af denne postserie her. Vi Stærkt anbefale at læserne tager lidt fri og læser hele rækken af indlæg for at samle fuldstændig kontekstuel bevidsthed og forstå den fulde alvor af den situation, der skete tilbage i 2012-13.
For at fremhæve et par vigtige punkter er her et par uddrag (med ekstra vægt) fra indlæggene:
"...Det er klart, næsten alle, der følger mig, er klar over den seneste sociale mediestorm, der skyldes frustrationen over tredjeparts Android-firmwarefællesskab (især CyanogenMod-brugere og -udviklere) har oplevet med Samsung. "Superbrick"-fiaskoen, manglen på dokumentation af Samsungs Exynos4 SoC sammenlignet med Qualcomm og TI's SoC'er og en vaskeri liste over andre problemer - det er alt sammen for nylig kommet til spidsen med beslutningen fra alle aktuelt aktive Exynos4-enhedsvedligeholdere om ikke at påtage sig nogen nye enheder..." - Forældrepost.
"...I november udgav Samsung XWKK5 til I9100 og UCKK6 til I777. Bluetooth HID på disse builds ville ikke fungere med nogen kildebyggede kerner - kun med binære filer forbundet med disse builds. Samsung udgav aldrig en anden Gingerbread-kildeopdatering til I9100, selvom deres binære filer viste tydelige beviser på en funktionel ændring af kilden. På samme måde blev I777 UCKK6-kilden ikke udgivet før et ukendt tidspunkt i midten af 2012 - jeg er ret sikker på, at først efter I9100 ICS blev frigivet i bedste fald. Det er rigtigt - Samsung overtrådte GPL med I777 UCKK6 og hver I9100 Gingerbread bygget fra XWKK5 (november 2011) indtil de officielt udgav I9100 ICS (marts 2012) - Faktisk, teknisk set er de det stadig, da Gingerbread-kilden svarende til de kerner aldrig blev udgivet, men det betyder bare ikke rigtig noget. mere..."
"...Omkring samme tid lancerede Samsung Tab 7.0 Plus og Tab 7.7, begge baseret på den samme Exynos 4210 SoC, som findes i GS2...Disse enheder brugte en Atheros AR6000-serie wifi-chip. Interessant nok leverer Atheros kilde til disse enheder under en dobbeltlicens, GPL og BSD. (Da Atheros har fuld ophavsret til alle komponenter i deres referencedriver, er dette lovligt.) Samsung valgte BSD-licensen til denne driver. Slutresultatet er, når du bliver bedt om wifi-driverkilde (som ikke var til stede i kildedråberne for disse enheder), Samsung svarede med "koden er GPL eller BSD med dobbelt licens. Vi vælger BSD [over GPL]"..." - Forældrepost
"...Hvis der var nogen åbenlys konklusion at drage fra ICS på GT-I9100, så var det, at fabrikantens skind holder ikke. Efter at have fået I9100 ICS-firmware til at køre på I777 (primært ved omvendt konstruktion af de ombyttede mikrofonkanaler på denne enhed, som tog det meste af en weekends arbejde...), var det tydeligt, at Touchwizz vendte mange af fordelene ved ICS. Dele af firmwaren var "nye", dele var "legacy Gingerbread", og de konstante diskontinuiteter var skurrende... - Forældrepost
Værre endnu... Officiel ICS lanceret til N7000 med XXLPY. Vi troede, at Samsung aldrig ville lade en forfærdelig fejl som denne komme ind i en frigivet kerne, men vi tog fejl...
- Forældrepost
"...En kontakt hos Samsung havde endelig erkendt, at de var opmærksomme på situationen og "arbejdede ihærdigt" på det... Til sidst blev Samsungs "løsning" præsenteret for os. Chainfire var IKKE tilfreds med den foreslåede "løsning", det var jeg heller ikke... Det involverede ingen beskyttelse på kerneniveau og var ringere end det, vi allerede havde på plads med BOARD_SUPPRESS_EMMC_WIPE i CM. Derudover bad de os om ikke at distribuere løsningen og omdirigere kerneudviklere på udkig efter en løsning til dem..."
"...Samsung nægtede også stort set at diskutere nogen løsninger, der involverede bootloadere... Begrundelsen, som ikke gav mening, var, at næsten alle deres garantikrav på grund af tilpasset firmware før denne eMMC-defekt skyldtes bootloader-korruption... Det giver selvfølgelig ingen mening, da vi ønskede at diskutere metoder til at gendanne fra bootloader-korruption, hvilket ville eliminere størstedelen af disse garantiomkostninger for Samsung. Vi tilbød endda at udføre størstedelen af ingeniør- og løsningsimplementeringen selv, så længe Samsung bare gav os nogle specifikke små komponenter, Dominik og Adam havde brug for..."
"...Samsung, efter at have "arbejdet flittigt" i en måned, kaster en granat i vores ansigter
I begyndelsen af juli lækket XXLQ5 til I9100. Inden for et døgn havde talrige rapporter om mursten hobet sig op. Ikke for længe efter gik XWLPM live på Kies, og folk murede også til venstre og højre med denne bygning.
På trods af at han hævder at være det arbejder flittigt på dette problem tog Samsung i stedet en tidligere sikker enhed og satte den i fare..." - Forældrepost
"...Så på dette tidspunkt - Det er midten af november 2012, og ikke en eneste enhed, der er påvirket af Samsungs defekte eMMC, har modtaget en kernerettelse. Mens indsatsen fra fællesskabet har skadesraterne MEGET nede, så længe Samsungs officielle kerner er det sårbar, vil jeg stadig få en PM med få dages mellemrum fra en Superbricked-bruger, der har brug for hjælp, som jeg ikke kan Hjælp..." - Forældrepost
"...I midten af august besluttede jeg at gå imod bedre vidende og købe en Note 10.1 (WiFi-variant - GT-N8013). Jeg regnede med, at da det delte en SoC med I9300, ville det være et ret sikkert bud...
Nu hvor jeg havde bekræftet, både via wifi-driverens manglende funktionalitet og forskellige strengsammenligninger med den sikkerhedskopierede lagerkerne, at de frigivne kilder til enhver N80xx-variant IKKE matchede lagerkernerne (alle havde den samme ødelagte wifi chauffør og andre personer, der arbejdede med kilderne, klagede over lignende problemer.), rejste jeg problemet med min kontakt på Samsung...
De sporede nogen, og denne persons svar var: Samsung var ikke forpligtet til at levere kilde, der matchede UEALGB-bygningen til GT-N8013, da det ikke var en officiel build. Ja, det er rigtigt - nogen faktisk turde påstå, at firmwaren, der var forudinstalleret på hver GT-N8013-enhed solgt i USA, var en LÆK. Dette var tredje gang, nogen inden for Samsung Mobile åbenlyst løj for min kontakts ansigt..." - Forældrepost
"...Så mellem det, andre ting (se tidligere dele af denne saga for mange eksempler), og Superbrick, stort set alle Exynos4-vedligeholdere var ved grænsen af udmattelse med Samsung og især med Exynos4.
Jeg angav, at Note 10.1 ville være min sidste enhed, og jeg var ikke sikker på, hvor længe jeg ville blive hos I777 og N7000, da jeg også var udmattet på dette tidspunkt.
Jeg var træt af at være måneder bagefter resten af Cyanogenmod-teamet, fordi jeg arbejdede med enheder, der havde flere klatter og flere grænsefladebrud i klatterne end nogen anden enhed
(Med undtagelse af Tegra3-enheder, men folk vidste allerede, at de skulle undgå disse, medmindre de var i en Nexus..." - Forældrepost
"...Nær slutningen [af BABBQ 2012] var Samsungs præsentation af udviklerrelationer. Det var her, de lovede at forbedre kvaliteten af referencekildekoden og dokumentationen til Exynos4, hvilket i teorien afbøder fællesskabets bekymringer. Selve præsentationsindholdet lovede lidt - næsten alt, hvad de annoncerede, var ting, der allerede eksisterede teknisk, men som var til ringe eller ingen nytte, fordi det var forældet eller simpelthen ikke-funktionelt..." - Forældrepost
Alt dette har blot været endnu et tilfælde af, at Samsung har talt og givet løfter og undladt at levere, ligesom de har talt og givet løfter i over et år. Udviklingstavler formodes at være FORAN for håndsæt - de behøver ikke beskæftige sig med operatørtest, trådløse certificeringer, eller nogen af de ting, der normalt er berygtede for at holde håndsættet tilbage opdateringer. Plus deres tilsigtede mål er UDVIKLERE, så de bør være "bleeding edge". Dette er, hvad Qualcomm og TI-referencekilden er - Det er den absolut seneste, foran alt, der er set på håndsæt. Det, vi får fra Samsung, er mere end 6 måneder forældet - ICS for en SoC, der var i et håndsæt, der blev lanceret med ICS i foråret 2012, og som modtog en officiel Jellybean-opdatering (operatørgodkendelser/trådløse certifikater og det hele) i begyndelsen af oktober 2012... Men de arbejder stadig på ICS som deres referencekilde???
- Forældrepost
Serien blev afsluttet med et opsummerende indlæg, som kan findes her. Vi anbefaler, at alle brugere læser den, før de fortsætter.
Udgangspunktet for denne artikel var at forsøge at forklare, hvorfor Exynos-enheder normalt mangler med hensyn til AOSP-baseret udvikling sammenlignet med Qualcomm-enheder. Ovennævnte og citerede G+ post-serie fremhævede de vanskeligheder, som en vedligeholder af en Exynos-enhed står over for. Indlægget er dateret til tidsperioden 2011-2013, så vi nåede ud til et par af de nævnte udviklere for at finde ud af, hvordan situationen er i øjeblikket. Der kan trods alt ændre sig meget på 3 år i den mobile verden.
Ikke for Samsung og dets understøttelse af AOSP, ser det ud til.
Q: Hvorfor tager AOSP ROM'er så lang tid at komme for Exynos-enheder, sammenlignet med eksempelvis Qualcomm-enheder?
A: XDA Senior Anerkendt Udvikler kodeværkx:
Qualcomm udgiver altid opdateret kildekode, som er nødvendig for at få alle komponenter på deres platform til at fungere på aosp. Se her.
Samsung gør ingenting.
XDA Senior anerkendt udvikler Entropi512:
"Qualcomm CAF er langt overlegen med hensyn til sporbarhed til/fra OEM-udgivelser (jeg har aldrig set en anden OEM-enhed end en Nexus, der ikke let kunne spores tilbage til et CAF-tag på CodeAurora), kvaliteten af koden og hyppigheden af opdateringer til Insignal (som ikke har nogen KitKat til "Arndale Octa" og intet nyere end ICS til Exynos4.) Ud over at være forældet, er der absolut ingen sporbarhed mellem Samsung Mobiles OEM udgivelser og Exynos referencekilden, mens alle OEM'er har en ret anstændig mængde sporbarhed tilbage til CAF (HTC og Samsung noget mindre end andre, men stadig langt bedre end noget andet Exynos)
Vent, de udgav til sidst JB til Origen Quad? Ikke før KitKat var næsten ude... Og det, de kaldte JB, var sandsynligvis tæt på den ubrugelige katastrofe, der var deres Honningkage "ICS"
Exynos3 aka Hummingbird var en helt anden historie takket være Nexus S, men Samsung har gjort et punkt for aldrig at dele et chipset mellem Nexus-enheder og nogen af deres andre enheder siden da. (Galaxy Nexus var OMAP4, mens alt andet fra den æra med nogle få undtagelser var Exynos4, Nexus 10 og Samsung Chromebook var to af de eneste Exynos 5250-enheder nogensinde at sende, Exynos 54xx skiftede fra Mali GPU til PowerVR sammen med en hel masse andre ændringer, så manta var ubrugelig for I9500, etc.)"
Q: Hvad er fremtiden for Exynos Development? Hvilke skridt kunne Samsung tage for at gøre sig selv mere udviklervenlige?
A: Codeworkx:
Der er ingen fremtid. Alle dev'er, du har skrevet til, er holdt op med at arbejde på exynos-enheder for længe siden. De fleste af dem stoppede endda for at arbejde på samsung-enheder generelt.
Vi har bedt om kildekode mere end én gang, og der skete ikke noget. De er simpelthen ligeglade med fællesskabet. Det eneste, de bekymrer sig om, er $$$
Det er tydeligt, at situationen er næsten identisk med, hvad den var for mere end 3 år siden. Samsung-enheder, specifikt Exynos-baserede, er stadig dårlige eksempler på at fremvise udviklingssamfundets arbejde uden for Touchwiz-baserede eksempler. Al udvikling af enheden forbliver stort set begrænset til ændringer af Touchwiz, med scenen for brugerdefinerede ROM'er drejer sig om tilføjelse eller fjernelse af funktioner fra Samsungs lukkede kilde OS "skin" gennem omvendt ingeniørarbejde.
Dette er ikke til at sige, at Exynos-enheder overhovedet ikke får support til AOSP ROM'er. AOSP Roms, som CM og lignende, gør til sidst lander på disse enheder, men disse kommer efter en masse hackeri på lavt niveau og ekstrem indsats fra vedligeholdere, der er modige nok til at bruge al deres fritid på at rette op på det, Samsung brød. Selv da er slutresultatet ikke en AOSP-oplevelse, som du normalt ville forvente, og for dette kan du roligt give Samsung skylden.
Superbricks sår er stadig friske på dem, der sætter deres hjerte og sjæl sammen i arbejdet mod en ødelagt sag, der kalder sig Samsung. Hvis du ønsker at få en enhed, hvor det første kriterium er brugerdefineret ROM-udvikling og 3. parts ROM-udviklersupport, så følg de visdomsord, der deles af Codeworkx:
Stop med at støtte sådanne virksomheder ved at købe deres enheder.
Tag en sony- eller nexus-enhed, få kvalitets-aosp-roms, god fællesskabssupport og bare vær glad.