Samsung, Exynos și AOSP explicate: O poveste de trădare

Amintiți-vă, amintiți-vă, primul din Notă, lansarea ICS și complot

Nu știu niciun motiv pentru care trădarea Superbrick ar trebui vreodată uitată

Membrii mai vechi ai forumului și utilizatorii Android ai dispozitivelor Samsung timpurii își pot aminti vag Fiasco Superbrick. Evenimentele care duc la Superbrick sunt lungi și complexe. De dragul conciziei, un tl; explicația dr este că o actualizare ICS scursă pentru câteva variante de transport ale Galaxy S2 i9100 și Galaxy Note N7000 a provocat o caramida permanenta. Aceasta nu era o cărămidă dură obișnuită, deoarece un dispozitiv afectat nu putea fi reînviat printr-un JTAG și era complet mort și nu răspundea. Superblock a afectat eMMC-ul dispozitivului și, prin urmare, reparațiile s-au putut face doar cu o schimbare completă a plăcii de bază.

Disclaimerul care se însoțește în general cu „scurgeri” a fost valabil și în acest caz, că scurgerile sunt în esență software „nelansat” care poate fi sau nu potrivit pentru consumul public. Cu toate acestea, pentru a complica lucrurile, acest nucleu ICS superb și-a făcut drumul către Galaxy Note N7000 ca o versiune oficială disponibilă prin actualizările Kies și OTA.

Fiasco-ul Superbrick și drama însoțitoare care a urmat datorită atitudinii Samsung față de dezvoltatori au fost evidențiate într-o serie de 13 postări de Andrew Dodd alias XDA Senior Recognized Developer Entropia512 pe Google+ lui. Puteți găsi începutul acestei serii de postări Aici. Noi recomand cu caldura că cititorii să-și ia puțin timp liber și să citească întreaga serie de postări pentru a aduna o conștientizare completă a contextului și a înțelege gravitatea deplină a situației care s-a întâmplat în 2012-2013.

Pentru a evidenția câteva puncte importante, iată câteva fragmente (cu accent suplimentar) din postări:

"...În mod evident, aproape oricine mă urmărește este conștient de recenta furtună din rețelele sociale rezultată din frustrarea Comunitatea de firmware Android terță parte (în special utilizatorii și dezvoltatorii CyanogenMod) se confruntă cu Samsung. Fiasco-ul „Superbrick”, lipsa documentației SoC-ului Exynos4 de la Samsung în comparație cu SoC-urile Qualcomm și TI și o listă generală de alte probleme - totul a ajuns recent la un cap cu decizia tuturor întreținătorilor de dispozitive Exynos4 activi în prezent de a nu prelua niciun dispozitiv nou..." - Postarea părintelui.

"...În noiembrie, Samsung a lansat XWKK5 pentru I9100 și UCKK6 pentru I777. Bluetooth HID pe aceste versiuni nu ar funcționa cu niciun nuclee construit din sursă - doar cu binare asociate cu acele versiuni. Samsung nu a lansat niciodată o altă actualizare a sursei Gingerbread pentru I9100, chiar dacă binarele lor au arătat dovezi clare ale unei schimbări funcționale a sursei. În mod similar, sursa I777 UCKK6 nu a fost lansată până la un moment necunoscut la mijlocul anului 2012 - sunt destul de sigur că nu abia după ce I9100 ICS a fost lansat în cel mai bun caz. Așa este - Samsung încălca GPL cu I777 UCKK6 și fiecare versiune I9100 Gingerbread de la XWKK5 (noiembrie 2011) până când au lansat oficial I9100 ICS (martie 2012) - De fapt, din punct de vedere tehnic, încă mai sunt, deoarece sursa de turtă dulce corespunzătoare acelor sâmburi nu a fost niciodată lansată, dar pur și simplu nu contează cu adevărat Mai mult..."

"...Aproximativ în aceeași perioadă, Samsung a lansat Tab 7.0 Plus și Tab 7.7, ambele bazate pe același SoC Exynos 4210 găsit în GS2...Aceste dispozitive foloseau un cip wifi din seria Atheros AR6000. Interesant este că Atheros oferă sursa pentru aceste dispozitive sub o licență duală, GPL și BSD. (Deoarece Atheros deține drepturi de autor depline asupra tuturor componentelor driverului de referință, acest lucru este legal.) Samsung a ales licența BSD pentru acest driver. Rezultatul final este, atunci când este cerută sursa driverului wifi (care nu era prezentă în picăturile sursei pentru aceste dispozitive), Samsung a răspuns cu „codul este dublă licență GPL sau BSD. Alegem BSD [peste GPL]"..." - Postarea părintelui

"...Dacă a existat vreo concluzie evidentă de făcut din ICS pe GT-I9100, aceasta a fost aceea skin-urile producătorului nu durează. După ce rulează firmware-ul I9100 ICS pe I777 (în primul rând prin inginerie inversă a canalelor microfonului schimbate pe acest dispozitiv, care a luat cea mai mare parte a unui weekend de lucru...), era evident că Touchwizz a revenit multe dintre beneficiile ICS. Părți ale firmware-ului erau „noi”, părțile erau „turtă dulce moștenită”, iar discontinuitățile constante erau discontinue... - Postarea părintelui

Chiar mai rau... ICS oficial lansat pentru N7000 cu XXLPY. Ne-am gândit că Samsung nu va lăsa niciodată un bug oribil ca acesta să intre într-un nucleu lansat, dar ne-am înșelat...

- Postarea părintelui

"...Un contact de la Samsung a recunoscut în sfârșit că sunt conștienți de situație și că „lucrează cu sârguință” la ea... Până la urmă, ne-a fost prezentată „soluția” Samsung. Chainfire NU a fost mulțumit de „soluția propusă”, nici eu... Nu a implicat nicio protecție la nivel de kernel și a fost inferior față de ceea ce aveam deja în vigoare cu BOARD_SUPPRESS_EMMC_WIPE în CM. În plus, ne-au cerut să nu distribuim soluția și să redirecționăm dezvoltatorii de kernel care caută o soluție către ei..."

"...Samsung a refuzat, de asemenea, să discute despre orice soluție care implică bootloadere... Raționamentul, care nu avea sens, a fost că aproape toate cererile lor de garanție din cauza firmware-ului personalizat înainte de acest defect eMMC s-au datorat coruperii bootloader-ului... Desigur, acest lucru nu are sens, din moment ce am vrut să discutăm despre metode de recuperare din corupția bootloaderului, care ar elimina majoritatea acestor costuri de garanție pentru Samsung. Ne-am oferit chiar să facem noi înșine majoritatea ingineriei și implementării soluțiilor, atâta timp cât Samsung ne-a oferit niște componente mici specifice de care Dominik și Adam aveau nevoie..."

"...Samsung, după ce „a muncit cu sârguință” timp de o lună, ne aruncă o grenadă în față

La începutul lunii iulie, XXLQ5 s-a scurs pentru I9100. În decurs de o zi, s-au adunat numeroase rapoarte despre cărămizi. Nu prea mult timp după aceea, XWLPM a intrat live pe Kies și oamenii au făcut cărămidă în stânga și în dreapta și cu această construcție.

În ciuda faptului că a pretins că este lucrând cu sârguință pe această problemă, în schimb, Samsung a luat un dispozitiv anterior sigur și l-a pus în pericol..." - Postarea părintelui

"... Deci, în acest moment - Este jumătatea lunii noiembrie 2012 și niciun dispozitiv afectat de eMMC defect de la Samsung nu a primit o remediere a nucleului. În timp ce eforturile comunității au rate de daune CU Scădere, atâta timp cât sunt nucleele oficiale ale Samsung vulnerabil, voi primi un PM la fiecare câteva zile de la un utilizator Superbricked care are nevoie de ajutor pe care nu îl pot Ajutor..." - Postarea părintelui

"...La mijlocul lunii august, am decis să merg împotriva unei judecăți mai bune și să cumpăr un Note 10.1 (varianta WiFi - GT-N8013). M-am gândit că, deoarece împărtășește un SoC cu I9300, ar fi un pariu destul de sigur...

Acum, că am confirmat, atât prin nefuncționalitatea driverului wifi, cât și prin diverse comparații de șiruri cu backup-ul nucleul stoc, că sursele lansate pentru orice variantă N80xx NU se potriveau cu nucleele stoc (toate aveau același wifi stricat șoferul și alte persoane care lucrau cu sursele s-au plâns de probleme similare.), am ridicat problema contactului meu la Samsung...

Ei au găsit pe cineva, iar răspunsul acelei persoane a fost: Samsung nu avea nicio obligație să furnizeze sursa care se potrivește cu versiunea UEALGB pentru GT-N8013, deoarece aceasta nu era o versiune oficială. Da, așa este - de fapt cineva a îndrăznit să susțină că firmware-ul preinstalat pe fiecare unitate GT-N8013 vândută în Statele Unite a fost o Scurgere. Aceasta a marcat a treia oară când cineva din Samsung Mobile a mințit în mod flagrant pe fața contactului meu...” - Postarea părintelui

"...Deci, între acestea, alte lucruri (vezi versiunile anterioare ale acestei sagă pentru multe exemple) și Superbrick, aproape toți întreținerii Exynos4 au fost la limita epuizării cu Samsung și mai ales cu Exynos4.

Am indicat că Note 10.1 va fi ultimul meu dispozitiv și nu eram sigur cât timp voi rămâne cu I777 și N7000, deoarece și eu eram epuizat în acest moment.

M-am săturat să fiu cu câteva luni în urmă față de restul echipei Cyanogenmod pentru că am lucrat cu dispozitive care aveau mai multe blob-uri și mai multe întreruperi de interfață în blob-uri decât orice alt dispozitiv.

(Cu excepția dispozitivelor Tegra3, dar oamenii știau deja să le evite dacă nu se aflau într-un Nexus...)" - Postarea părintelui

"...Aproape de sfârșitul [BABBQ 2012] a fost prezentarea Samsung privind relațiile cu dezvoltatorii. Aici au promis că vor îmbunătăți calitatea codului sursă de referință și a documentației pentru Exynos4, atenuând teoretic preocupările comunității. Conținutul real al prezentării promite puțin - Aproape tot ceea ce au anunțat erau lucruri care existau deja din punct de vedere tehnic, dar nu erau de nici un folos, deoarece erau depășite sau pur și simplu nefuncționale..." - Postarea părintelui

Toate acestea au fost încă un caz în care Samsung a vorbit și a făcut promisiuni și nu a reușit să își respecte, la fel cum au vorbit și au făcut promisiuni de peste un an. Plăcile de dezvoltare ar trebui să fie ÎNAINTE față de telefoane - nu trebuie să se ocupe de testarea operatorului, certificări wireless sau oricare dintre lucrurile care sunt de obicei notorii pentru reținerea receptorului actualizări. În plus, ținta lor este DEZVOLTĂTORII, așa că ar trebui să fie „marginea de sânge”. Aceasta este sursa de referință Qualcomm și TI - Este cea mai recentă absolută, înaintea tuturor celor văzute pe telefoane. Ceea ce primim de la Samsung este învechit de peste 6 luni - ICS pentru un SoC care era într-un telefon care a fost lansat cu ICS în primăvara anului 2012 și care a primit o actualizare oficială Jellybean (aprobări de operator/certificații wireless și toate) la începutul lunii octombrie 2012... Dar încă lucrează la ICS pentru sursa lor de referință???

- Postarea părintelui

Seria s-a încheiat cu o postare rezumată care poate fi găsită Aici. Recomandăm tuturor utilizatorilor să o citească înainte de a continua.

Punctul de plecare al acestui articol a fost să încercăm să explicăm de ce dispozitivele Exynos lipsesc de obicei în ceea ce privește dezvoltarea bazată pe AOSP în comparație cu dispozitivele Qualcomm. Seria de postări G+ menționată și citată mai sus a evidențiat dificultățile cu care se confruntă un întreținător al unui dispozitiv Exynos. Postarea este datată pentru perioada 2011-2013, așa că am contactat câțiva dintre dezvoltatorii menționați pentru a ne da seama cum sta situația în prezent. La urma urmei, multe se pot schimba în 3 ani în lumea mobilă.

Nu pentru Samsung și suportul său pentru AOSP, se pare.

Î: De ce durează atât de mult timp să apară ROM-urile AOSP pentru dispozitivele Exynos, în comparație cu dispozitivele Qualcomm?

R: Dezvoltator recunoscut senior XDA codeworkx:

Qualcomm lansează cod sursă mereu actualizat, care este necesar pentru ca toate componentele platformei lor să funcționeze pe aosp. Vedea Aici.

Samsung nu face nimic.

Dezvoltator senior recunoscut XDA Entropia512:

"Qualcomm CAF este cu mult superioară în ceea ce privește trasabilitatea către/de la versiunile OEM (nu am văzut niciodată un dispozitiv OEM, altul decât un Nexus, care să nu fie ușor de urmărit la o etichetă CAF la CodAurora), calitatea codului și frecvența actualizărilor la Semnal (care nu are KitKat pentru „Arndale Octa” și nimic mai nou decât ICS pentru Exynos4.) Pe lângă faptul că este depășit, există absolut zero trasabilitate între OEM-ul Samsung Mobile versiuni și sursa de referință Exynos, în timp ce toți OEM-urile au o cantitate destul de decentă de trasabilitate înapoi la CAF (HTC și Samsung oarecum mai puțin decât alții, dar totuși mult mai bine decât orice Exynos)

Stai, în cele din urmă l-au lansat pe JB pentru Origen Quad? Nu până când KitKat a fost aproape afară... Și ceea ce ei au numit JB era probabil aproape de dezastrul inutil care a fost al lor Turtă dulce „ICS”

Exynos3, alias Hummingbird, a fost o poveste complet diferită datorită lui Nexus S, dar Samsung și-a propus să nu mai partajeze niciodată un chipset între dispozitivele Nexus și oricare dintre celelalte dispozitive ale lor de atunci. (Galaxy Nexus a fost OMAP4, în timp ce orice altceva din acea epocă, cu câteva excepții, a fost Exynos4, Nexus 10 și Samsung Chromebook au fost două dintre singurele Dispozitivele Exynos 5250 care urmează să fie livrate, Exynos 54xx a trecut de la Mali GPU la PowerVR împreună cu o grămadă de alte modificări, astfel încât manta a fost inutilă pentru I9500, etc.)"

Î: Care este viitorul Exynos Development? Ce pași ar putea face Samsung pentru a fi mai prietenoși cu dezvoltatorii?

A: Codeworkx:

Nu există viitor. Toți dezvoltatorii pentru care ai scris au încetat să mai funcționeze pe dispozitivele exynos cu mult timp în urmă. Cei mai mulți dintre ei chiar s-au oprit să lucreze pe dispozitive Samsung în general.

Am cerut de mai multe ori codul sursă și nu s-a întâmplat nimic. Pur și simplu nu le pasă de comunitate. Tot ce le pasă este $$$

Este clar că situația este aproape identică cu ceea ce era acum mai bine de 3 ani. Dispozitivele Samsung, în special bazate pe Exynos, rămân exemple slabe de prezentare a muncii comunității de dezvoltare în afara exemplelor bazate pe Touchwiz. Toată dezvoltarea pentru dispozitiv rămâne în mare măsură limitată la modificări la Touchwiz, cu scena personalizării ROM-uri care se învârt în jurul adăugării sau eliminării funcțiilor din „skinul” sistemului de operare cu sursă închisă a Samsung prin inversare Inginerie.

Acest lucru nu înseamnă că dispozitivele Exynos nu beneficiază deloc de suport pentru ROM-urile AOSP. Rom-urile AOSP, precum CM și altele, fac în cele din urmă aterizează pe aceste dispozitive, dar acestea vin după o mulțime de hackeri la nivel scăzut și eforturi extreme ale întreținătorilor suficient de curajoși pentru a-și dedica tot timpul liber reparând ceea ce Samsung a spart. Chiar și atunci, rezultatul final nu este o experiență AOSP la care te-ai aștepta în mod normal și, pentru aceasta, poți da vina pe Samsung în siguranță.

Rănile lui Superbrick sunt încă proaspete asupra celor care își pun inima și sufletul împreună pentru a lucra pentru o cauză distrusă care se numește Samsung. Dacă doriți să obțineți un dispozitiv cu primul criteriu să fie dezvoltarea personalizată a ROM-ului și asistența pentru dezvoltatori ROM terți, urmați cuvintele de înțelepciune împărtășite de Codeworkx:

Nu mai susțineți astfel de companii cumpărându-și dispozitivele.

Luați un dispozitiv Sony sau Nexus, obțineți rom-uri aosp de calitate, asistență bună pentru comunitate și pur și simplu fiți fericit.