Wyjaśnienie Samsunga, Exynos i AOSP: historia zdrady

Pamiętajcie, pamiętajcie, pierwsza część notatki, wydanie ICS i fabuła

Nie znam powodu, dla którego zdrada Superbrick miałaby kiedykolwiek zostać zapomniana

Starsi członkowie forum i użytkownicy Androida wczesnych urządzeń Samsung mogą słabo pamiętać Fiasko Superbricka. Wydarzenia, które doprowadziły do ​​powstania Superbrick, są długie i złożone. Dla zwięzłości, a tl; dr wyjaśnił, że wyciek aktualizacji ICS dla kilku wariantów operatorów Galaxy S2 i9100 i Galaxy Note N7000 spowodował cegła trwała. Nie była to zwykła twarda cegła, ponieważ uszkodzonego urządzenia nie można było wskrzesić za pomocą JTAG i było ono całkowicie martwe i nie reagowało. Superbrick wpłynął na eMMC urządzenia, dlatego naprawy można było wykonać tylko po całkowitej zmianie płyty głównej.

Zastrzeżenie, które zwykle towarzyszy „wyciekom”, miało zastosowanie również w tym przypadku, a mianowicie, że wycieki to zasadniczo „niewydane” oprogramowanie, które może, ale nie musi, nadawać się do użytku publicznego. Jednak, aby skomplikować sprawę, to superbrickujące jądro ICS faktycznie trafiło do Galaxy Note N7000 jako oficjalne wydanie dostępne za pośrednictwem Kies i aktualizacji OTA.

Fiasko Superbrick i towarzyszący mu dramat, który nastąpił dzięki podejściu Samsunga do programistów, został uwypuklony w 13-postowej serii autorstwa Andrew Dodda, znanego również jako starszy uznany programista XDA Entropia512 na swoim Google+. Możesz znaleźć początek tej serii postów Tutaj. My wysoce zalecane aby czytelnicy wzięli trochę wolnego i przeczytali całą serię postów, aby uzyskać pełną świadomość kontekstu i zrozumieć pełną powagę sytuacji, która miała miejsce w latach 2012–2013.

Aby podkreślić kilka ważnych punktów, oto kilka fragmentów (z dodatkowym podkreśleniem) z postów:

"...Oczywiście prawie każdy, kto mnie obserwuje, zdaje sobie sprawę z niedawnej burzy w mediach społecznościowych wynikającej z frustracji z czym spotkała się społeczność zewnętrznych firm zajmujących się oprogramowaniem sprzętowym Androida (zwłaszcza użytkownicy i programiści CyanogenMod). SAMSUNG. Fiasko „Superbrick”, brak dokumentacji SoC Exynos4 firmy Samsung w porównaniu z układami SoC Qualcomm i TI oraz lista innych problemów do prania – to wszystko ostatnio osiągnęło punkt kulminacyjny decyzja wszystkich aktualnie aktywnych opiekunów urządzeń Exynos4 o nieprzyjmowaniu żadnych nowych urządzeń..." - Post rodzica.

"...W listopadzie Samsung wypuścił XWKK5 dla I9100 i UCKK6 dla I777. Bluetooth HID w tych kompilacjach nie będzie działał z żadnymi jądrami zbudowanymi ze źródła - tylko z plikami binarnymi powiązanymi z tymi kompilacjami. Firma Samsung nigdy nie wydała kolejnej aktualizacji źródła Gingerbread dla modelu I9100, mimo że ich pliki binarne wykazały wyraźne dowody zmian funkcjonalnych w źródle. Podobnie źródło I777 UCKK6 zostało wypuszczone dopiero w nieznanym czasie w połowie 2012 roku – jestem całkiem pewien, że w najlepszym wypadku dopiero po wydaniu I9100 ICS. Zgadza się – Samsung naruszył GPL z I777 UCKK6 i każdą wersją I9100 Gingerbread od XWKK5 (listopad 2011) aż do oficjalnego wydania I9100 ICS (marzec 2012) - Właściwie, technicznie rzecz biorąc, nadal tak jest, ponieważ źródło Gingerbread odpowiadające tym jądrom nigdy nie zostało wydane, ale to po prostu nie ma znaczenia więcej..."

"... Mniej więcej w tym samym czasie Samsung wypuścił na rynek karty Tab 7.0 Plus i Tab 7.7, oba oparte na tym samym układzie SoC Exynos 4210, który można znaleźć w modelu GS2... Urządzenia te korzystały z chipa Wi-Fi z serii Atheros AR6000. Co ciekawe, Atheros udostępnia źródła dla tych urządzeń na podstawie podwójnej licencji GPL i BSD. (Ponieważ Atheros posiada pełne prawa autorskie do wszystkich komponentów swojego sterownika referencyjnego, jest to legalne.) Firma Samsung wybrała dla tego sterownika licencję BSD. Efektem końcowym jest to, że na pytanie o źródło sterownika Wi-Fi (którego nie było w źródłach dla tych urządzeń), Samsung odpowiedział: „Kod to podwójna licencja GPL lub BSD. Wybieramy BSD [nad GPL]”…" - Poczta rodzica

"...Jeśli można było wyciągnąć jakiś oczywisty wniosek z układu ICS w GT-I9100, to właśnie taki Skórki producenta nie są trwałe. Po uruchomieniu oprogramowania sprzętowego ICS I9100 na I777 (głównie poprzez inżynierię wsteczną zamienionych kanałów mikrofonowych na to urządzenie, co zajęło większość weekendu w pracy...), było oczywiste, że Touchwizz przywrócił wiele korzyści płynących z ICS. Części oprogramowania były „nowe”, części „starego piernika”, a ciągłe nieciągłości były irytujące… - Poczta rodzica

Nawet gorzej... Wprowadzono oficjalny system ICS dla N7000 z XXLPY. Myśleliśmy, że Samsung nigdy nie pozwoli, aby taki okropny błąd dostał się do wydanego jądra, ale myliliśmy się…

- Poczta rodzica

"... Osoba kontaktowa w firmie Samsung w końcu przyznała, że ​​jest świadoma sytuacji i „pilnie nad nią pracuje”… Ostatecznie zaprezentowano nam „rozwiązanie” Samsunga. Chainfire NIE był zadowolony z proponowanego „rozwiązania”, ja też nie… Nie wymagało to ochrony na poziomie jądra i było gorsze od tego, co już mieliśmy w przypadku BOARD_SUPPRESS_EMMC_WIPE w CM. Ponadto poprosili nas, abyśmy nie rozpowszechniali rozwiązania i przekierowywali do nich programistów jądra szukających rozwiązania..."

"...Samsung również praktycznie odmówił dyskusji na temat jakichkolwiek rozwiązań obejmujących programy ładujące... Rozumowanie, które nie miało sensu, było takie, że prawie wszystkie ich roszczenia gwarancyjne z powodu niestandardowego oprogramowania sprzętowego sprzed tej wady eMMC wynikały z uszkodzenia programu ładującego… Oczywiście nie ma to sensu, ponieważ chcieliśmy omówić metody odzyskiwania danych po uszkodzeniu programu ładującego, co wyeliminowałoby większość kosztów gwarancji dla Samsunga. Zaproponowaliśmy nawet, że sami zajmiemy się większością prac inżynieryjnych i wdrażaniem rozwiązań, pod warunkiem, że Samsung dostarczy nam tylko kilka konkretnych małych komponentów, których potrzebowali Dominik i Adam…"

"...Samsung po miesiącu „pilnej pracy” rzuca nam granat w twarz

Na początku lipca wyciekł XXLQ5 dla I9100. W ciągu jednego dnia napłynęło wiele raportów o cegłach. Niedługo potem XWLPM został uruchomiony na Kies i ludzie też murowali na lewo i prawo przy tej kompilacji.

Pomimo twierdzenia, że ​​tak pilnie pracować zamiast tego Samsung wziął wcześniej bezpieczne urządzenie i naraził je na niebezpieczeństwo…” – Poczta rodzica

"...A zatem w tym momencie jest połowa listopada 2012 r. i żadne urządzenie dotknięte wadliwym modułem eMMC firmy Samsung nie otrzymało poprawki jądra. Chociaż wysiłki społeczności spowodowały ZNACZNIE niższy poziom uszkodzeń, o ile oficjalne jądra Samsunga są bezbronny, nadal będę co kilka dni otrzymywać PW od użytkownika Superbricked, który potrzebuje pomocy, a ja nie mogę pomoc..." - Poczta rodzica

"...W połowie sierpnia zdecydowałem się pójść wbrew rozsądkowi i kupić Note 10.1 (wariant WiFi - GT-N8013). Pomyślałem, że skoro ma wspólny SoC z I9300, będzie to dość bezpieczny zakład…

Teraz, gdy to potwierdziłem, zarówno poprzez niefunkcjonalność sterownika Wi-Fi, jak i różne porównania ciągów z kopią zapasową stockowe jądro, że udostępnione źródła dla dowolnego wariantu N80xx NIE pasują do standardowych jąder (wszystkie miały to samo uszkodzone Wi-Fi kierowca i inne osoby współpracujące ze źródłami skarżyły się na podobne problemy.), poruszyłem tę kwestię z moją osobą kontaktową pod adresem SAMSUNG...

Wyśledzili kogoś, a odpowiedź tej osoby była następująca: Samsung nie był zobowiązany do dostarczenia źródła odpowiadającego wersji UEALGB dla GT-N8013, ponieważ nie była to oficjalna wersja. Tak, zgadza się – faktycznie ktoś ośmieliłem się twierdzić, że oprogramowanie instalowane fabrycznie w każdym urządzeniu GT-N8013 sprzedawanym w Stanach Zjednoczonych było WYCIEKIEM. Był to już trzeci raz, kiedy ktoś z Samsung Mobile rażąco okłamał moją osobę kontaktową…” - Poczta rodzica

"...A więc między innymi (wiele przykładów można znaleźć w poprzednich częściach tej sagi) i Superbrick, prawie wszyscy opiekunowie Exynos4 byli na skraju wyczerpania, jeśli chodzi o Samsunga, a zwłaszcza o Exynos4.

Wskazałem, że Note 10.1 będzie moim ostatnim urządzeniem i nie byłem pewien, jak długo zostanę przy I777 i N7000, bo w tym momencie też byłem wyczerpany.

Miałem dość bycia miesiącami w tyle za resztą zespołu Cyanogenmod, ponieważ pracowałem z urządzeniami, które miały więcej plam i więcej przerw w interfejsie w plamach niż jakiekolwiek inne urządzenie

(Z wyjątkiem urządzeń Tegra3, ale ludzie już wiedzieli, aby ich unikać, chyba że byli w Nexusie.)…” – Poczta rodzica

"...Pod koniec [BABBQ 2012] odbyła się prezentacja relacji z deweloperami firmy Samsung. To tam obiecano poprawić jakość referencyjnego kodu źródłowego i dokumentacji dla Exynos4, teoretycznie łagodząc obawy społeczności. Rzeczywista treść prezentacji niewiele obiecywała - prawie wszystko, co ogłosili, było już technicznie istniejące, ale było mało przydatne, ponieważ było przestarzałe lub po prostu niefunkcjonalne…" - Poczta rodzica

Wszystko to to kolejny przypadek Samsunga, który mówił i składał obietnice, ale ich nie dotrzymywał, tak jak mówili i składali obietnice od ponad roku. Płytki rozwojowe mają być PRZED telefonami - nie muszą zajmować się testowaniem nośników, certyfikaty sieci bezprzewodowej lub inne rzeczy, które zwykle słyną z blokowania słuchawki aktualizacje. Poza tym ich zamierzonym celem są DEWELOPERY, więc to oni powinni być „krwawiącą krawędzią”. Oto, czym jest źródło referencyjne Qualcomma i TI – to absolutna nowość, wyprzedzająca wszystko, co można zobaczyć w telefonach. To, co otrzymujemy od Samsunga, jest nieaktualne od ponad 6 miesięcy – ICS dla SoC, który znajdował się w telefonie, który został uruchomiony z ICS wiosną 2012 r. i który otrzymał oficjalną aktualizację Jellybean (zezwolenia operatora/certyfikaty sieci bezprzewodowej i wszystko) na początku października 2012... Ale nadal pracują nad ICS jako źródłem odniesienia?

- Poczta rodzica

Cykl zakończył się postem podsumowującym, który można znaleźć Tutaj. Zalecamy, aby wszyscy użytkownicy przeczytali go przed kontynuowaniem.

Punktem wyjścia tego artykułu była próba wyjaśnienia, dlaczego urządzeniom Exynos zwykle brakuje możliwości rozwoju w oparciu o AOSP w porównaniu z urządzeniami Qualcomm. Wyżej wspomniana i cytowana seria postów na G+ uwypukliła trudności, jakie napotyka osoba utrzymująca urządzenie Exynos. Post jest datowany na lata 2011–2013, dlatego skontaktowaliśmy się z kilkoma wymienionymi programistami, aby dowiedzieć się, jak obecnie wygląda sytuacja. Przecież w mobilnym świecie przez 3 lata wiele może się zmienić.

Wygląda na to, że nie dla Samsunga i jego obsługi AOSP.

P: Dlaczego przygotowanie ROM-ów AOSP do urządzeń Exynos zajmuje tak dużo czasu w porównaniu, powiedzmy, do urządzeń Qualcomm?

Odp.: Starszy uznany programista XDA praca z kodemx:

Qualcomm publikuje zawsze aktualny kod źródłowy, który jest niezbędny, aby wszystkie komponenty ich platformy działały na aosp. Widzieć Tutaj.

Samsung nic nie robi.

Starszy uznany programista XDA Entropia512:

"Qualcomm CAF jest znacznie lepszy pod względem identyfikowalności do/z wydań OEM (nigdy nie widziałem urządzenia OEM innego niż Nexus, którego nie można było łatwo prześledzić wstecz do znacznika CAF w KodAurora), jakość kodu i częstotliwość aktualizacji Insygnalny (który nie ma KitKata dla „Arndale Octa” i niczego nowszego niż ICS dla Exynos 4). Oprócz tego, że jest przestarzały, nie ma absolutnie zerowej identyfikowalności pomiędzy producentami OEM Samsung Mobile wydaniach i źródle referencyjnym Exynos, podczas gdy wszyscy producenci OEM mają całkiem przyzwoitą identyfikowalność aż do CAF (HTC i Samsung nieco mniej niż inne, ale wciąż znacznie lepiej niż cokolwiek innego) Exynos)

Czekaj, w końcu wypuścili JB dla Origen Quad? Dopiero gdy KitKat prawie się skończył... A to, co nazywali JB, było prawdopodobnie bliskie bezużytecznej katastrofie, która ich spotkała Piernikowy „ICS”

Exynos3, czyli Hummingbird, to zupełnie inna historia dzięki Nexusowi S, ale Samsung od tego czasu postawił sobie za cel, aby nigdy nie udostępniać chipsetu pomiędzy urządzeniami Nexus i żadnym innym urządzeniem. (Galaxy Nexus to OMAP4, podczas gdy wszystko inne z tamtej epoki, z kilkoma wyjątkami, to Exynos 4, Nexus 10 i Samsung Chromebook były dwoma jedynymi Urządzenia Exynos 5250, jakie kiedykolwiek zostały wydane, Exynos 54xx przełączył się z procesora graficznego Mali na PowerVR wraz z całą masą innych zmian, więc manta była bezużyteczna dla I9500, itp.)"

P: Jaka jest przyszłość Exynos Development? Jakie kroki mógłby podjąć Samsung, aby stać się bardziej przyjaznym dla programistów?

O: Praca z kodemx:

Nie ma przyszłości. Wszyscy deweloperzy, o których pisałeś, dawno przestali pracować na urządzeniach Exynos. Większość z nich przestała nawet ogólnie działać na urządzeniach Samsung.

Wielokrotnie pytaliśmy o kod źródłowy i nic się nie działo. Po prostu nie zależy im na społeczeństwie. Jedyne na czym im zależy to $$$

Wiadomo, że sytuacja jest niemal identyczna jak ponad 3 lata temu. Urządzenia Samsung, w szczególności oparte na Exynos, pozostają kiepskimi przykładami prezentowania pracy społeczności programistów poza przykładami opartymi na Touchwiz. Cały rozwój urządzenia pozostaje w dużej mierze ograniczony do modyfikacji Touchwiz, ze sceną niestandardową ROMy skupiające się na dodawaniu lub usuwaniu funkcji ze „skórki” systemu operacyjnego Samsung o zamkniętym kodzie źródłowym w odwrotną stronę Inżynieria.

Nie oznacza to, że urządzenia Exynos w ogóle nie obsługują pamięci ROM AOSP. Romy AOSP, takie jak CM i tym podobne, tak w końcu lądują na tych urządzeniach, ale są one wynikiem wielu hackerów na niskim poziomie i ekstremalnych wysiłków opiekunów, którzy są na tyle odważni, aby poświęcić cały swój wolny czas na naprawianie tego, co zepsuł Samsung. Nawet wtedy efektem końcowym nie jest doświadczenie AOSP, jakiego można się spodziewać normalnie, i za to można bezpiecznie winić Samsunga.

Rany Superbrick są wciąż świeże na tych, którzy połączyli swoje serce i duszę, pracując na rzecz zniszczonej sprawy, która nazywa się Samsung. Jeśli szukasz urządzenia, którego pierwszym kryterium będzie tworzenie niestandardowej pamięci ROM i wsparcie dla programistów ROM innych firm, postępuj zgodnie ze słowami mądrości udostępnionymi przez Codeworkx:

Przestańcie wspierać takie firmy kupując ich urządzenia.

Weź urządzenie Sony lub Nexus, zdobądź wysokiej jakości ROMy AOSP, dobre wsparcie społeczności i po prostu bądź szczęśliwy.