Samsung, Exynos e AOSP spiegati: una storia di tradimento

Ricorda, ricorda, la prima nota, il rilascio e la trama di ICS

Non conosco alcun motivo per cui il tradimento di Superbrick debba mai essere dimenticato

I membri più anziani del forum e gli utenti Android dei primi dispositivi Samsung potrebbero ricordare vagamente il Il fiasco dei Superbrick. Gli eventi che portano a Superbrick sono lunghi e complessi. Per brevità, un tl; La nostra spiegazione è che un aggiornamento ICS trapelato per alcune varianti dell'operatore del Galaxy S2 i9100 e del Galaxy Note N7000 ha causato un mattone permanente. Non si trattava di un normale mattone duro, poiché un dispositivo interessato non poteva essere resuscitato tramite un JTAG ed era completamente morto e non rispondeva. Il superbrick ha interessato l'eMMC del dispositivo e, quindi, le riparazioni potevano essere eseguite solo con una sostituzione completa della scheda madre.

La dichiarazione di non responsabilità che generalmente accompagna i "leak" era valida anche in questo caso, ovvero che i leak sono essenzialmente software "inedito" che può o meno essere adatto al consumo pubblico. Tuttavia, per complicare le cose, questo kernel ICS superbricking è effettivamente arrivato sul Galaxy Note N7000 come versione ufficiale disponibile tramite Kies e aggiornamenti OTA.

Il fiasco di Superbrick e il dramma che ne seguì, per gentile concessione dell'atteggiamento di Samsung nei confronti degli sviluppatori, sono stati evidenziati in una serie di 13 post da Andrew Dodd aka XDA Senior Recognized Developer Entropia512 sul suo Google+. Puoi trovare l'inizio di questa serie di post Qui. Noi altamente raccomandato che i lettori si prendano una pausa e leggano l'intera serie di post per acquisire una completa consapevolezza contestuale e comprendere tutta la gravità della situazione accaduta nel 2012-2013.

Per evidenziare alcuni punti importanti, ecco alcuni frammenti (con maggiore enfasi) dei post:

"...Ovviamente, quasi tutti quelli che mi seguono sono consapevoli della recente tempesta sui social media derivante dalla frustrazione la community di firmware Android di terze parti (in particolare gli utenti e gli sviluppatori di CyanogenMod) ha sperimentato SAMSUNG. Il fiasco del "Superbrick", la mancanza di documentazione del SoC Exynos4 di Samsung rispetto ai SoC di Qualcomm e TI e una lunga lista di altri problemi: tutto è recentemente giunto al culmine con la decisione di tutti i manutentori dei dispositivi Exynos4 attualmente attivi di non assumere alcun nuovo dispositivo..." - Posta principale.

"...A novembre, Samsung ha rilasciato XWKK5 per I9100 e UCKK6 per I777. Bluetooth HID su queste build non funzionerebbe con nessun kernel creato dal codice sorgente, solo con i binari associati a tali build. Samsung non ha mai rilasciato un altro aggiornamento del sorgente Gingerbread per l'I9100, anche se i suoi file binari mostravano una chiara prova di un cambiamento funzionale al sorgente. Allo stesso modo, la sorgente I777 UCKK6 non è stata rilasciata fino a un momento sconosciuto a metà del 2012 - sono abbastanza certo non prima del rilascio di I9100 ICS, nella migliore delle ipotesi. Esatto: Samsung stava violando la GPL con I777 UCKK6 e ogni build I9100 Gingerbread da XWKK5 (novembre 2011) fino al rilascio ufficiale di I9100 ICS (marzo 2012) - In realtà, tecnicamente lo sono ancora, dato che il sorgente Gingerbread corrispondente a quei kernel non è mai stato rilasciato, ma non ha molta importanza Di più..."

"...Più o meno nello stesso periodo, Samsung ha lanciato il Tab 7.0 Plus e il Tab 7.7, entrambi basati sullo stesso SoC Exynos 4210 presente nel GS2...Questi dispositivi utilizzavano un chip wifi Atheros serie AR6000. È interessante notare che Atheros fornisce i sorgenti per questi dispositivi con doppia licenza, GPL e BSD. (Poiché Atheros detiene il pieno copyright di tutti i componenti del driver di riferimento, ciò è legale.) Samsung ha scelto la licenza BSD per questo driver. Il risultato finale è che, quando viene richiesta la fonte del driver Wi-Fi (che non era presente nei sorgenti per questi dispositivi), Samsung ha risposto con "il codice è a doppia licenza GPL o BSD. Scegliamo BSD [rispetto a GPL]"..." - Posta genitore

"...Se c'era una conclusione ovvia da trarre da ICS sul GT-I9100, era questa le skin del produttore non durano. Dopo aver eseguito il firmware I9100 ICS sull'I777 (principalmente eseguendo il reverse engineering dei canali microfonici scambiati su questo dispositivo, che ha richiesto gran parte di un fine settimana di lavoro...), era ovvio che Touchwizz ripristinasse molti dei vantaggi di ICS. Parti del firmware erano "nuove", parti erano "legacy Gingerbread" e le continue discontinuità erano stridenti... - Posta genitore

Persino peggio... Lancio ufficiale di ICS per l'N7000 con XXLPY. Pensavamo che Samsung non avrebbe mai permesso che un bug orribile come questo entrasse in un kernel rilasciato, ma ci sbagliavamo...

- Posta genitore

"...Un contatto di Samsung ha finalmente ammesso di essere a conoscenza della situazione e di "lavorare diligentemente" su di essa... Alla fine ci è stata presentata la "soluzione" di Samsung. Chainfire NON era soddisfatto della "soluzione" proposta, nemmeno io... Non prevedeva alcuna protezione a livello di kernel ed era inferiore a quella già utilizzata con BOARD_SUPPRESS_EMMC_WIPE in CM. Inoltre ci hanno chiesto di non distribuire la soluzione e di reindirizzare gli sviluppatori del kernel che cercavano una soluzione a loro..."

"...Samsung si è praticamente rifiutata di discutere qualsiasi soluzione che coinvolga i bootloader... Il ragionamento, che non aveva senso, era che quasi tutte le richieste di garanzia dovute al firmware personalizzato prima di questo difetto eMMC erano dovute alla corruzione del bootloader... Naturalmente, questo non ha senso, da allora volevamo discutere dei metodi di ripristino dal danneggiamento del bootloader, che eliminerebbero la maggior parte dei costi di garanzia per Samsung. Ci offrivamo addirittura di occuparci noi stessi della maggior parte della progettazione e dell'implementazione della soluzione, a patto che Samsung ci fornisse solo alcuni piccoli componenti specifici di cui Dominik e Adam avevano bisogno..."

"...Samsung, dopo aver "lavorato diligentemente" per un mese, ci lancia una granata in faccia

All'inizio di luglio è trapelato XXLQ5 per l'I9100. Nel giro di un giorno si erano accumulate numerose segnalazioni di mattoni. Non molto tempo dopo, XWLPM fu pubblicato su Kies e Anche la gente stava murando a destra e a sinistra con questa build.

Nonostante affermi di esserlo lavorando diligentemente su questo problema, invece, Samsung ha preso un dispositivo precedentemente sicuro e lo ha messo in pericolo..." - Posta genitore

"...Quindi, a questo punto, siamo a metà novembre 2012 e nessun dispositivo affetto dall'eMMC difettoso di Samsung ha ricevuto una correzione del kernel. Sebbene gli sforzi della comunità abbiano tassi di danno MOLTO bassi, a patto che lo siano i kernel ufficiali di Samsung vulnerabile, riceverò comunque un PM ogni pochi giorni da un utente Superbricked che ha bisogno di aiuto e io non posso aiuto..." - Posta genitore

"...A metà agosto, ho deciso di andare contro ogni giudizio e acquistare un Note 10.1 (variante WiFi - GT-N8013). Ho pensato che, poiché condivideva un SoC con l'I9300, sarebbe stata una scommessa abbastanza sicura...

Adesso ne avevo la conferma, sia attraverso la non funzionalità del driver wifi, sia attraverso vari confronti di stringhe con il backup kernel stock, che i sorgenti rilasciati per qualsiasi variante N80xx NON corrispondevano ai kernel stock (tutti avevano lo stesso wifi rotto driver e altre persone che lavoravano con le fonti si sono lamentate di problemi simili.), ho sollevato la questione con il mio contatto all'indirizzo SAMSUNG...

Hanno rintracciato qualcuno e la risposta di quella persona è stata: Samsung non aveva l'obbligo di fornire una fonte che corrispondesse alla build UEALGB per GT-N8013, poiché non era una build ufficiale. Sì, è vero, qualcuno in realtà ha osato affermare che il firmware preinstallato su ogni unità GT-N8013 venduta negli Stati Uniti fosse una PERDITA. Questa è stata la terza volta che qualcuno all'interno di Samsung Mobile ha mentito apertamente in faccia al mio contatto..." - Posta genitore

"...Quindi tra questo, altre cose (vedi i capitoli precedenti di questa saga per molti esempi) e Superbrick, praticamente tutti i manutentori di Exynos4 erano al limite dello sfinimento con Samsung e soprattutto con Exynos4.

Ho indicato che il Note 10.1 sarebbe stato il mio ultimo dispositivo e non ero sicuro di quanto tempo sarei rimasto con l'I777 e l'N7000, poiché anch'io ero esausto a questo punto.

Ero stanco di essere mesi indietro rispetto al resto del team Cyanogenmod perché lavoravo con dispositivi che avevano più blob e più interruzioni dell'interfaccia nei blob rispetto a qualsiasi altro dispositivo

(Tranne i dispositivi Tegra3, ma la gente già sapeva di evitarli a meno che non fossero in un Nexus.)..." - Posta genitore

"...Verso la fine [del BABBQ 2012] c'è stata la presentazione delle relazioni con gli sviluppatori di Samsung. È qui che hanno promesso di migliorare la qualità del codice sorgente di riferimento e della documentazione per Exynos4, in teoria alleviando le preoccupazioni della comunità. Il contenuto della presentazione vera e propria prometteva poco: quasi tutto ciò che annunciavano era materiale che già esisteva tecnicamente ma di scarsa o nessuna utilità perché obsoleto o semplicemente non funzionante..." - Posta genitore

Tutto questo è stato solo l'ennesimo caso in cui Samsung parla e fa promesse e non riesce a mantenerle, proprio come hanno parlato e fatto promesse per oltre un anno. Le schede di sviluppo dovrebbero essere AVANTI rispetto ai telefoni: non hanno bisogno di occuparsi dei test del gestore telefonico, certificazioni wireless o qualsiasi cosa che di solito è nota per trattenere il telefono aggiornamenti. Inoltre il loro obiettivo previsto sono gli SVILUPPATORI, quindi dovrebbero essere il "bordo sanguinante". Questa è la fonte di riferimento di Qualcomm e TI: è l'ultima novità assoluta, prima di qualsiasi cosa vista sui telefoni. Ciò che riceviamo da Samsung è obsoleto di oltre 6 mesi: ICS per un SoC presente in un telefono lanciato con ICS nella primavera del 2012 e che ha ricevuto un aggiornamento ufficiale di Jellybean (approvazioni degli operatori/certificati wireless e tutto il resto) all'inizio di ottobre 2012... Ma stanno ancora lavorando su ICS come fonte di riferimento???

- Posta genitore

La serie si è conclusa con un post riassuntivo che potete trovare Qui. Consigliamo a tutti gli utenti di leggerlo prima di procedere.

Il punto di partenza di questo articolo è stato cercare di spiegare perché i dispositivi Exynos di solito mancano in termini di sviluppo basato su AOSP rispetto ai dispositivi Qualcomm. La serie di post G+ sopra menzionata e citata ha evidenziato le difficoltà incontrate da un manutentore di un dispositivo Exynos. Il post è datato per il periodo 2011-2013, quindi abbiamo contattato alcuni degli sviluppatori citati per capire come è attualmente la situazione. Dopotutto, molto può cambiare in 3 anni nel mondo mobile.

Non per Samsung e il suo supporto per AOSP, a quanto pare.

D: Perché le ROM AOSP impiegano così tanto tempo ad arrivare per i dispositivi Exynos, rispetto, ad esempio, ai dispositivi Qualcomm?

R: Sviluppatore riconosciuto senior XDA codeworkx:

Qualcomm rilascia un codice sorgente sempre aggiornato, necessario per far funzionare tutti i componenti della propria piattaforma su aosp. Vedere Qui.

Samsung non fa nulla.

Sviluppatore senior riconosciuto XDA Entropia512:

"QualcommCAF è di gran lunga superiore in termini di tracciabilità da/verso le versioni OEM (non ho mai visto un dispositivo OEM diverso da un Nexus che non fosse facilmente riconducibile a un tag CAF su CodiceAurora), qualità del codice e frequenza degli aggiornamenti Segnale (che non ha KitKat per "Arndale Octa" e niente di più nuovo di ICS per Exynos4.) Oltre ad essere obsoleto, non c'è assolutamente tracciabilità tra l'OEM di Samsung Mobile versioni e la fonte di riferimento Exynos, mentre tutti gli OEM hanno una discreta quantità di tracciabilità fino a CAF (HTC e Samsung un po' meno di altri, ma comunque molto meglio di qualsiasi altra cosa Exynos)

Aspetta, alla fine hanno rilasciato JB per il Quad Origene? Non finché KitKat non era quasi uscito... E quello che chiamavano JB probabilmente era vicino all'inutile disastro che fu il loro Pan di zenzero "ICS"

Exynos3 aka Hummingbird è stata una storia completamente diversa grazie al Nexus S, ma da allora Samsung si è impegnata a non condividere mai un chipset tra i dispositivi Nexus e nessuno degli altri dispositivi. (Il Galaxy Nexus era OMAP4 mentre tutto il resto di quell'epoca, con poche eccezioni, era Exynos4, Nexus 10 e il Chromebook Samsung erano due dei pochi I dispositivi Exynos 5250 mai spediti, Exynos 54xx è passato dalla GPU Mali a PowerVR insieme a tutta una serie di altre modifiche, quindi manta era inutile per I9500, eccetera.)"

D: Qual è il futuro dello sviluppo di Exynos? Quali misure potrebbe intraprendere Samsung per rendersi più favorevole agli sviluppatori?

R: Codeworkx:

Non c'è futuro. Tutti gli sviluppatori a cui hai scritto hanno smesso di funzionare sui dispositivi Exynos molto tempo fa. La maggior parte di loro ha persino smesso di funzionare sui dispositivi Samsung in generale.

Abbiamo chiesto più di una volta il codice sorgente e non è successo nulla. Semplicemente non si preoccupano della comunità. A loro interessa solo $$$

È chiaro che la situazione è quasi identica a quella di più di 3 anni fa. I dispositivi Samsung, in particolare quelli basati su Exynos, rimangono scarsi esempi di come mostrare il lavoro della comunità di sviluppo al di fuori degli esempi basati su Touchwiz. Tutto lo sviluppo del dispositivo rimane in gran parte limitato alle modifiche a Touchwiz, con la scena della personalizzazione ROM che ruotano attorno all'aggiunta o alla rimozione di funzionalità dalla "skin" del sistema operativo closed source di Samsung tramite il contrario ingegneria.

Questo non vuol dire che i dispositivi Exynos non ricevano assolutamente alcun supporto per le ROM AOSP. I Rom AOSP, come CM e simili, lo fanno infine arrivano su questi dispositivi, ma questi arrivano dopo un sacco di hacker di basso livello e sforzi estremi da parte dei manutentori abbastanza coraggiosi da dedicare tutto il loro tempo libero a riparare ciò che Samsung ha rotto. Anche in questo caso, il risultato finale non è un’esperienza AOSP come ti aspetteresti normalmente, e per questo puoi tranquillamente incolpare Samsung.

Le ferite di Superbrick sono ancora fresche su coloro che hanno messo insieme cuore e anima nel lavorare per una causa distrutta che si fa chiamare Samsung. Se stai cercando un dispositivo il cui primo criterio sia lo sviluppo di ROM personalizzate e il supporto per sviluppatori ROM di terze parti, segui le parole di saggezza condivise da Codeworkx:

Smetti di supportare tali aziende acquistando i loro dispositivi.

Prendi un dispositivo Sony o Nexus, ottieni rom ASP di qualità, un buon supporto da parte della community e sii semplicemente felice.