Gondolkozott már azon, hogy az Exynos eszközök miért nem kapják meg a legjobb AOSP támogatást? Tudja meg eseményeink összefoglalójából!
Emlékezz, ne feledd, az első a Note, az ICS kiadás és a cselekmény
Nem tudok okot arra, hogy a Superbrick árulást miért kellene valaha is elfelejteni
Az idősebb fórumozók és a korai Samsung készülékek Android-felhasználói halványan emlékezhetnek a Superbrick fiaskó. A Superbrickhez vezető események hosszúak és összetettek. A tömörség kedvéért egy tl; A dr magyarázat az, hogy a Galaxy S2 i9100 és a Galaxy Note N7000 néhány szolgáltatóváltozatához kiszivárgott ICS frissítés állandó tégla. Ez nem egy szokványos kemény tégla, mivel az érintett eszközt nem lehetett újraéleszteni JTAG-on keresztül, és teljesen halott volt, és nem reagált. A szupertégla az eszköz eMMC-jét érintette, így a javítást csak teljes alaplapcserével lehetett elvégezni.
Erre az esetre is érvényes volt az általában a "szivárgással" járó felelősségkizárás, miszerint a kiszivárogtatások alapvetően "nem kiadott" szoftverek, amelyek alkalmasak vagy nem nyilvános fogyasztásra. A helyzet bonyolítása végett azonban ez a szuperbricking ICS kernel ténylegesen eljutott a Galaxy Note N7000-hez, mint a Kies és az OTA frissítéseken keresztül elérhető hivatalos kiadás.
A Superbrick-kudarcra és az azt kísérő drámára, amely a Samsung fejlesztőihez való hozzáállásának köszönhetően következett be, Andrew Dodd, más néven XDA Senior Recognized Developer egy 13 bejegyzésből álló sorozatban emelte ki. Entrópia512 a Google+-ján. A bejegyzéssorozat elejét megtalálod itt. Mi erősen ajánlott hogy az olvasók vegyenek egy kis szünetet, és olvassák el a bejegyzések teljes sorozatát, hogy teljes kontextuális tudatosságot szerezzenek, és megértsék a 2012–2013-ban történt helyzet teljes súlyát.
Néhány fontos pont kiemelésére álljon itt néhány részlet (kiemelt hangsúllyal) a bejegyzésekből:
"...Nyilvánvaló, hogy szinte mindenki, aki követ engem, tisztában van a közösségi média közelmúltbeli viharával, amelyet a harmadik féltől származó Android firmware közösség (különösen a CyanogenMod felhasználók és fejlesztők) tapasztalt Samsung. A „Superbrick” kudarc, a Samsung Exynos4 SoC-jének dokumentációjának hiánya a Qualcomm és a TI SoC-jaihoz képest, valamint egyéb problémák mosodai listája – mindez a közelmúltban a fejébe került az összes jelenleg aktív Exynos4 eszközkarbantartó döntése, hogy nem vesznek fel új eszközöket..." - Szülői bejegyzés.
"...Novemberben a Samsung kiadta az XWKK5-öt I9100-hoz és az UCKK6-ot az I777-hez. A Bluetooth HID ezeken a buildeken nem működik semmilyen forrásból felépített kernel esetén – csak az ezekhez a buildekhez társított binárisokkal. A Samsung soha nem adott ki újabb Gingerbread forrásfrissítést az I9100-hoz, annak ellenére, hogy binárisai egyértelmű bizonyítékot mutattak a forrás funkcionális változására. Hasonlóképpen, az I777 UCKK6 forrás csak 2012 közepén jelent meg egy ismeretlen időpontban – egészen biztos vagyok benne, hogy legfeljebb az I9100 ICS megjelenése után. Így van – a Samsung megsértette a GPL-t I777 UCKK6-tal és minden I9100 Gingerbread builddel az XWKK5-től (2011. november) egészen az I9100 ICS hivatalos megjelenéséig (2012. március) – Valójában technikailag még mindig azok, mivel az ezeknek a kerneleknek megfelelő Gingerbread forrást soha nem adták ki, de ez nem igazán számít. több..."
"...Körülbelül ugyanebben az időben a Samsung piacra dobta a Tab 7.0 Plus-t és a Tab 7.7-et, mindkettő ugyanazon az Exynos 4210 SoC-n alapul, mint a GS2-ben...Ezek az eszközök Atheros AR6000-es sorozatú wifi chipet használtak. Érdekes módon az Atheros forrást biztosít ezekhez az eszközökhöz kettős licenc, GPL és BSD alatt. (Mivel az Atheros teljes szerzői joggal rendelkezik referencia-illesztőprogramjának minden összetevőjére, ez törvényes.) A Samsung a BSD licencet választotta ehhez az illesztőprogramhoz. A végeredmény az, hogy amikor megkérdezik a wifi-illesztőprogram forrását (ami nem volt jelen ezeknél az eszközöknél a forrásbejegyzésekben), A Samsung így válaszolt: „a kód kettős licencű GPL vagy BSD. A BSD-t választjuk [GPL helyett]"..." - Szülőbejegyzés
"...Ha a GT-I9100-as ICS-ből bármi nyilvánvaló következtetést lehetett levonni, az az volt, hogy a gyártói skinek nem tartósak. Miután az I9100 ICS firmware futott az I777-en (elsősorban a felcserélt mikrofoncsatornák visszatervezésével ezt az eszközt, amely egy hétvége nagy részét dolgozta...), nyilvánvaló volt, hogy a Touchwizz visszafordította a ICS. A firmware egyes részei "újak", részei "örökölt Gingerbread" voltak, és az állandó megszakítások felkavaróak voltak... - Szülőbejegyzés
Még rosszabb... Hivatalos ICS indult az N7000-hez XXLPY-val. Azt hittük, a Samsung soha nem engedi, hogy egy ilyen szörnyű hiba bekerüljön egy kiadott kernelbe, de tévedtünk...
- Szülőbejegyzés
"...A Samsung egyik kapcsolattartója végre elismerte, hogy tisztában vannak a helyzettel, és "szorgalmasan dolgoznak" rajta... Végül a Samsung „megoldását” tárták elénk. Chainfire NEM örült a javasolt "megoldásnak", én sem... Nem tartalmazott kernel szintű védelmet, és gyengébb volt, mint amit már a BOARD_SUPPRESS_EMMC_WIPE CM-ben alkalmaztunk. Ezen kívül arra kértek minket, hogy ne terjesszük a megoldást, és irányítsuk át hozzájuk a megoldást kereső kernelfejlesztőket..."
"...a Samsung sem volt hajlandó megvitatni a rendszerbetöltőkkel kapcsolatos megoldásokat... Az értelmetlen érvelés az volt, hogy az eMMC-hiba előtti egyedi firmware miatti jótállási igényük szinte mindegyike a rendszerbetöltő meghibásodása miatt merült fel... Ennek persze semmi értelme, hiszen meg akartuk vitatni a rendszerbetöltő korrupcióból való helyreállítás módszereit, amelyek megszüntetnék a Samsung garanciális költségeinek többségét.. Még azt is felajánlottuk, hogy a tervezés és a megoldások bevezetésének nagy részét magunk végezzük el, amíg a Samsung csak adott néhány apró alkatrészt, amire Dominiknak és Adamnek szüksége volt..."
"...A Samsung egy hónapi "szorgalmas munka" után gránátot dob az arcunkba
Július elején kiszivárgott az XXLQ5 az I9100-hoz. Egy napon belül számos bejelentés gyűlt össze téglákról. Nem sokkal később az XWLPM élőben indult a Kies-en, és az emberek jobbra-balra falaztak ezzel az építménnyel is.
Annak ellenére, hogy azt állítják szorgalmasan dolgozik ezen a problémán ehelyett a Samsung egy korábban biztonságos eszközt vett el és veszélyeztette..." - Szülőbejegyzés
"...Tehát ezen a ponton - 2012. november közepe van, és egyetlen olyan eszköz sem kapott kerneljavítást, amelyet a Samsung hibás eMMC-je érintett. Míg a közösség erőfeszítései miatt a károk mértéke NAGYON lecsökkent, addig a Samsung hivatalos kerneléié sebezhető, továbbra is néhány naponta kapok egy PM-et egy Superbricked felhasználótól, akinek segítségre van szüksége, akitől nem tudok Segítség..." - Szülőbejegyzés
"...Augusztus közepén úgy döntöttem, hogy szembeszállok a józan belátással, és veszek egy Note 10.1-et (WiFi változat - GT-N8013). Arra gondoltam, hogy mivel megosztott egy SoC-t az I9300-zal, ez meglehetősen biztonságos fogadás lenne...
Most, hogy megerősítettem, mind a wifi-illesztőprogram nem működőképessége, mind a különböző karakterlánc-összehasonlítások a biztonsági másolattal készlet kernel, hogy a kiadott források egyik N80xx változathoz NEM egyeztek meg a törzskernelekkel (mindegyikben ugyanaz a hibás wifi volt sofőr, és más, a forrásokkal együttműködő személyek hasonló problémákra panaszkodtak.), felvetettem a problémát kapcsolattartómmal a következő címen: Samsung...
Lenyomoztak valakit, és az illető válasza a következő volt: a Samsungnak nem volt kötelessége olyan forrást megadni, amely megegyezik a GT-N8013 UEALGB buildjével, mivel az nem volt hivatalos build. Igen, ez igaz – valaki valójában mertem azt állítani, hogy az Egyesült Államokban eladott minden GT-N8013 egységre előre telepített firmware szivárgás volt.. Ez volt a harmadik alkalom, hogy valaki a Samsung Mobile-on belül nyíltan az ismerősöm arcába hazudott..." - Szülőbejegyzés
"...Tehát ezek között más dolgok (sok példát lásd a saga korábbi részeit), és a Superbrick, nagyjából az összes Exynos4 karbantartó a kimerültség határán volt a Samsunggal és különösen a Samsunggal Exynos4.
Jeleztem, hogy a Note 10.1 lesz az utolsó készülékem, és nem voltam benne biztos, hogy meddig maradok az I777-nél és az N7000-nél, mivel ezen a ponton is kimerültem.
Belefáradtam abba, hogy hónapokkal lemaradtam a Cyanogenmod csapat többi tagjától, mert olyan eszközökkel dolgoztam, amelyek több blobot tartalmaztak és több interfész-törést tartalmaztak, mint bármely más eszközön.
(Kivéve a Tegra3 készülékeket, de az emberek már tudták, hogy ezeket kerülni kell, hacsak nem Nexusban voltak.)..." - Szülőbejegyzés
"...A [BABBQ 2012] vége felé volt a Samsung fejlesztői kapcsolatok bemutatója. Itt azt ígérték, hogy javítják az Exynos4 referenciaforráskódjának és dokumentációjának minőségét, elméletileg enyhítve a közösség aggodalmait. A tényleges prezentáció tartalma keveset ígért - szinte minden, amit bejelentettek, olyan cucc volt, ami műszakilag már létezett, de elavult vagy egyszerűen nem működőképes volta miatt alig volt hasznuk..." - Szülőbejegyzés
Mindez csak egy újabb eset, amikor a Samsung beszél, ígéreteket tesz, és nem teljesíti, mint ahogyan több mint egy éve beszélnek és ígérnek. A fejlesztői tábláknak állítólag ELŐRE kell menniük a készülékeknél – nem kell szolgáltatótesztekkel foglalkozniuk, vezeték nélküli tanúsítványok, vagy bármely olyan dolog, amely általában a kézibeszélő visszatartásáról híres frissítéseket. Ráadásul a célpontjuk a FEJLESZTŐK, tehát nekik kell lenniük a "vérző élnek". Ez az, ami a Qualcomm és a TI referenciaforrása – ez az abszolút legújabb, megelőzve a készülékeken látottakat. Amit a Samsungtól kapunk, az több mint 6 hónapja elavult – ICS egy olyan SoC-hez, amely az ICS-sel elindított készülékben volt 2012 tavaszán, és amely hivatalos Jellybean frissítést kapott (szolgáltatói jóváhagyások/vezeték nélküli tanúsítványok és minden) október elején 2012... De még mindig dolgoznak az ICS-en a referenciaforrásukhoz???
- Szülőbejegyzés
A sorozatot egy összefoglaló bejegyzés zárta, amely megtalálható itt. Javasoljuk, hogy minden felhasználó olvassa el, mielőtt folytatná.
Ennek a cikknek a kiindulópontja az volt, hogy megpróbáljuk elmagyarázni, hogy az Exynos-eszközök általában miért hiányoznak az AOSP-alapú fejlesztésből a Qualcomm-eszközökhöz képest. A fent említett és idézett G+ bejegyzéssorozat rávilágított azokra a nehézségekre, amelyekkel egy Exynos eszköz karbantartója szembesül. A bejegyzés a 2011-2013-as időszakra datált, ezért megkerestük néhány említett fejlesztőt, hogy kiderítsük, hogy áll a jelenlegi helyzet. Végül is sok minden megváltozhat 3 év alatt a mobil világban.
Úgy tűnik, nem a Samsung és az AOSP támogatása.
K: Miért tart olyan sokáig az AOSP ROM-ok megjelenése az Exynos eszközök esetében, mint mondjuk a Qualcomm eszközöknél?
V: XDA elismert vezető fejlesztő codeworkx:
A Qualcomm mindig naprakész forráskódot ad ki, amely szükséges ahhoz, hogy platformjuk minden összetevője működjön az AOSP-n. Lát itt.
A Samsung nem csinál semmit.
XDA elismert vezető fejlesztő Entrópia512:
"Qualcomm CAF nagymértékben jobb az OEM-kiadások nyomon követhetősége szempontjából (soha nem láttam olyan OEM-eszközt, mint egy Nexus, amely nem volt könnyen visszavezethető egy CAF-címkére CodeAurora), a kód minősége és a frissítések gyakorisága Insignal (amelyben nincs KitKat az "Arndale Octa"-hoz, és semmi sem újabb, mint az ICS az Exynos4-hez.) Amellett, hogy elavult, teljesen nulla a nyomon követhetőség a Samsung Mobile OEM-jei között kiadások és az Exynos referenciaforrás, miközben minden OEM-nek meglehetősen tisztességes visszakövethetősége van a CAF-ig (a HTC és a Samsung valamivel kevésbé, mint mások, de még mindig mindennél jobb Exynos)
Várj, végül kiadták a JB-t az Origen Quadhoz? Egészen addig, amíg a KitKat majdnem ki nem jött... És amit JB-nek hívtak, valószínűleg közel volt ahhoz a haszontalan katasztrófához, ami az övék volt Mézeskalács "ICS"
Az Exynos3, azaz a Hummingbird egy teljesen más történet volt a Nexus S-nek köszönhetően, de a Samsung arra törekedett, hogy azóta soha ne ossza meg chipkészletet a Nexus készülékek és más készülékeik között. (A Galaxy Nexus OMAP4 volt, míg a korszak többi része néhány kivétellel az Exynos4, a Nexus 10 és a Samsung Chromebook pedig az egyetlen A valaha szállítandó Exynos 5250 eszközök, az Exynos 54xx Mali GPU-ról PowerVR-re váltott egy csomó egyéb változtatással együtt, így a manta használhatatlan volt az I9500-nál, stb.)"
K: Mi az Exynos Development jövője? Milyen lépéseket tehet a Samsung, hogy fejlesztőbarátabbá tegye magát?
V: Codeworkx:
Nincs jövő. Az összes fejlesztő, amelyet írt, már régen leállt az exynos eszközökön. A legtöbben általában abbahagyták a Samsung eszközökön való munkát.
Többször kértük a forráskódot, de semmi sem történt. Egyszerűen nem törődnek a közösséggel. Csak a $$$ érdekli őket
Nyilvánvaló, hogy a helyzet szinte teljesen megegyezik a több mint 3 évvel ezelőtti helyzettel. A Samsung készülékek, különösen az Exynos alapú készülékek továbbra is gyenge példák a fejlesztői közösség munkájának bemutatására a Touchwiz alapú példákon kívül. Az eszköz minden fejlesztése nagyrészt a Touchwiz módosításaira korlátozódik, az egyedi színtérrel A ROM-ok a Samsung zárt forráskódú operációs rendszerének „bőréből” való hozzáadásával vagy eltávolításával kapcsolatos funkciók visszafordításával mérnöki.
Ez nem jelenti azt, hogy az Exynos eszközök egyáltalán nem támogatják az AOSP ROM-okat. Az AOSP Romok, mint a CM és hasonlók, igen végül is ezeken az eszközökön landolnak, de ezek a sok alacsony szintű hackerkedés és a karbantartók extrém erőfeszítései után jöttek, akik elég bátrak voltak ahhoz, hogy minden szabad idejüket a Samsung által elrontott dolgok javítására fordítsák. A végeredmény még akkor sem egy olyan AOSP-élmény, amilyenre általában számítana, és ezért nyugodtan hibáztathatja a Samsungot.
A Superbrick sebei még mindig frissek azokon, akik szívüket-lelküket összeadva egy összetört ügyért dolgoznak, amely Samsungnak nevezi magát. Ha olyan eszközt szeretne beszerezni, amelynek első feltétele az egyéni ROM fejlesztés és a harmadik féltől származó ROM fejlesztői támogatás, kövesse a Codeworkx által megosztott bölcsesség szavait:
Ne támogassa az ilyen cégeket eszközeik megvásárlásával.
Vegyünk egy Sony vagy Nexus eszközt, szerezzünk be minőségi aosp romokat, jó közösségi támogatást, és egyszerűen csak boldogok.