Dlaczego jest tak wiele różnych jąder Androida (proszę o odpowiedź techniczną)

Czy Android nie jest powszechnym jądrem używanym na wszystkich urządzeniach? Na przykład CentOS zostanie zainstalowany na Dell, HP i wielu innych urządzeniach. Jasne, że istnieją różne moduły, ale mimo to jest to CentOS.

Jaki jest powód, dla którego CyanogenMod jest zawsze „zepsuty”? Zawsze słyszę na forach, że pracują nad przeniesieniem tego sterownika lub tego sterownika. Gdyby korzystali z tego samego jądra, czy sterowniki po prostu nie działałyby z nim? Widzę też milion różnych rodzajów jąder dla różnych urządzeń.

Jądra różnią się w zależności od producenta. Wiele z tych jąder pochodzi z czystej linii jądra źródeł znalezionych na CAF, a producenci ci pobierają te źródła, modyfikują je w celu dopasowania do stosowanej płyty / chipsetu, a także implementują własne sterowniki.

Rozejrzyj się wokół siebie, są różne ekrany dotykowe, odmiany chipsetów WiFi, nie wspominając o akcelerometrze, czujnikach, bateriach, kompasie, dźwięku, grafice.

Biorąc jedno źródło jądra na przykład HTC nie będzie działać na Samsungu i odwrotnie.

Producenci mogą swobodnie wybierać lub wymieniać różne bity, które zostają wbudowane w płytkę drukowaną. Nie ma w tym żadnych sztywnych ani szybkich zasad. Stąd mnóstwo hakowania / modyfikacji, aby jądro działało poprawnie.

Nie wolno ci nigdy porównywać się z jądrowymi dystrybucjami Linuksa, w których ma on PCI, PCI-Express, SATA, VGA, SVGA, USB, Ethernet, ponieważ są one zupełnie inną grą typu ball-park. Główne różnice między CentOS i jądrem Linuksa Androida są następujące - WSZYSTKIE sterowniki są kompilowane jako moduły lub wbudowane, dlatego każda dystrybucja Linuksa będzie po prostu „działać od razu po wyjęciu z pudełka”. Ponownie, w przypadku dystrybucji Linuksa na komputery stacjonarne - masz jedną architekturę - x86, stąd jedno jądro Linuksa, powiedzmy, komputer Dell, może działać od razu po wyjęciu z pudełka na Lenovo, pod warunkiem, że skompilowane zostaną standardowe sterowniki.

Nie zapominaj, że w świecie Androida istnieją odmiany jądra zbudowane dla określonych układów ARM, takich jak ARMv6, ARMv7, jest TEGRA, jest EXYNOS i są one binarnie niekompatybilne. Dlatego jeśli jądro jest skompilowane dla TEGRA, zapomnij o nim, nie będzie działać na ARMv7!

Powodem, dla którego niektóre jądra na Androidzie wyglądają na „zepsute”, jest producent. Niektóre (Zte to jeden bardzo dobry przykład) wypuszczają zaśmiecone źródło, które może się kompilować ze źródła, ale nie uruchamia się z powodu brakującego sterownika, który nie jest objęty licencją GPLv2 lub GPLv3. To jest problem, dlatego niektórzy hakerzy muszą przeszukiwać github w poszukiwaniu wskazówek; niektórzy producenci, jeśli nie wszyscy, przestrzegają tego. Obecne wcielenie źródła Zte ma podobno 2.6.35.7, ale w rzeczywistości jego baza źródłowa 2.6.32.9 z wieloma modyfikacjami nie reprezentuje prawdziwego źródła jądra dla 2.6.35.7!

W tym miejscu producenci muszą udostępnić odpowiednie źródła, nie tylko z powodu niezgodności z GPLv2 lub nowszą wersją, ale także ze względu na możliwość modyfikacji przez społeczność, na przykład poprzez dodanie możliwości podkręcania.

W związku z tym za kulisami kryje się hackowanie i wiele zamieszania z kierowcami próbującymi uruchomić go, a także nie jest to łatwe do debugowania. Niektóre sterowniki mogą być licencjonowane krzyżowo, ALE nie można ich dystrybuować w zależności od klauzuli i warunków, takich jak negocjowane.

Na szczęście wszystko to zmieniło się teraz wraz z linią źródeł jądra 3.xx, ponieważ sterowniki Androida są teraz zintegrowane ze źródłami głównego nurtu. Ale jest gotcha!

Spróbuj przenieść jądro 3.xx do istniejącego telefonu, który ma około 12-18 miesięcy; Nie ma szansy na śnieżkę w piekle, czy to zadziałałoby, ponieważ, z powodu różnych czynników, źródła 3.xx różnią się znacznie od źródła 2.6.x i wymagałyby dużo hakowania, aby to działało - powinienem wiedzieć, próbowałem przeniesienie źródła 2.6.38.6 dla Zte Blade i nie powiodło się.

Podobnie, najnowsze wydanie jądra 3.0.1 - pracując nad projektem ics4blade nad Modaco, podjęło liczne próby przeniesienia go, ale to tylko dlatego, że Zte zrobił bardzo zły bałagan ze źródła, który uniemożliwił przeniesienie .

Architektura PC zbudowana jest wokół części towarowych, ponieważ początkowo była klonem określonego produktu, IBM PC, który został specjalnie zaprojektowany, aby być z nim kompatybilny, a zatem ze sobą. Ogólnie rzecz biorąc, możesz pobrać program lub urządzenie peryferyjne z jednego komputera kompatybilnego z komputerem i umieścić je w innym, i oczekiwać, że zadziała. Ta umiejętność jest na tyle użyteczna, że ​​ludzie wciąż jej wymagają, nawet w miarę rozwoju technologii. Możesz umieścić kartę PCI Express na dowolnym nowoczesnym komputerze PC, tak jak wtedy możesz umieścić kartę ISA w dowolnym klonie komputera.

Smartfony nie mają takiej historii. Są zaprojektowane jako produkty monolityczne, kompletny system składający się ze sprzętu i oprogramowania, który „po prostu działa” taki, jaki jest. Nie oczekuje się, że ludzie wyjmują części z jednego telefonu i umieszczają je w innym, więc inżynierowie nie muszą brać pod uwagę interoperacyjności podczas projektowania swoich produktów.

Nawet w drzewie źródeł jądra Linuksa występuje duża fragmentacja sterowników sterowników platform ARM . Ponieważ telefony są zwykle projektowane za zamkniętymi drzwiami, zespoły inżynieryjne w różnych firmach często kończą się powielaniem prac, projektując zasadniczo ten sam sprzęt co ich konkurenci, a następnie pisząc własne sterowniki do własnego projektu. Po zakończeniu i wypuszczeniu produktu, idą od razu do pracy nad kolejnym; nie warto wracać i refaktoryzować sterowników do poprzednich produktów ani łączyć ich ze sterownikami konkurencji. Rezultatem jest mnóstwo jednorazowych sterowników dla urządzeń, które są podobne, ale nie do końca takie same.

Ponadto smartfony są zwykle oparte na SOC, które mają zintegrowany sprzęt specjalistyczny zintegrowany z procesorem. W niektórych przypadkach może być więcej niż kwestia, czy załadować określonego sterownika, czy nie; jądro jako całość może wymagać zbudowania ze specjalnymi opcjami konfiguracji do uruchamiania na jednym SOC, które są niezgodne ze specjalnymi opcjami potrzebnymi do uruchomienia na innym SOC.

Powodem jest to, że jądro Linuksa Androida na ogół nie jest kompilowane na samym Androidzie, a zamiast tego musiało być kompilowane krzyżowo z innego komputera. Powoduje to różne problemy, ponieważ konfiguracja urządzenia nie jest dostępna w czasie kompilacji i nie jest możliwe skompilowanie ogólnego jądra ze wszystkimi sterownikami ze względu na ograniczoną przestrzeń (podczas gdy w większości dystrybucji na pulpicie wszystkie sterowniki zostały po prostu skompilowane w moduły załadowane z initramfs) . Dlatego programiści musieli ustalić, które sterowniki należy spakować dla każdego urządzenia. Co więcej, każdy sterownik ma zwykle kilkanaście opcji czasu kompilacji do przełączania różnych funkcji sterowników, a producenci zwykle nie publikują swojej oficjalnej konfiguracji (najgorsze przestępcy nawet nie otwierają swoich sterowników lub nie utrzymywali wcześniejszych wersji) kopia sterowników na bieżąco).

Programowanie sterowników jest znacznie trudniejsze niż programowanie aplikacji, ponieważ nie ma jądra, które chroniłoby cię przed kapryśnym sprzętem, który ma określone wymagania czasowe w czasie rzeczywistym i tym podobne, a to oznacza, że ​​nawet inna charakterystyka wydajności może spowodować, że sterownik przeoczy niektóre trudne zdarzenia w czasie rzeczywistym ze sprzętu; błędy te mogą pojawić się jako błędy lub problemy z wydajnością.

Kolejną kwestią jest niezgodność binarna. Istnieją dwie przyczyny niekompatybilności binarnej, pierwsza to typ procesora, który został dobrze uwzględniony w t0mm13b, ale drugą kwestią, która jest bardziej istotna przy przenoszeniu, jest niezgodność ABI (binarny interfejs aplikacji). Jeśli producenci nie otwierają swoich sterowników, programiści musieli użyć skompilowanego modułu ze standardowej pamięci ROM. Rodzi to różne problemy z niekompatybilnością ABI, ponieważ same moduły sterowników mają określone oczekiwania dotyczące, na przykład, struktury struktur i parametrów wywoływania funkcji, a kiedy jądro jest kompilowane, nie ma pliku nagłówkowego opisującego ABI w czasie, gdy sterownik jest skompilowany, więc programiści musieli dokonać inżynierii wstecznej sterownika, aby utworzyć plik nagłówka, inaczej pliki nagłówkowe w drzewie źródłowym mogły zostać mocno zmodyfikowane, ponieważ sterownik jest skompilowany, a programiści musieli cofnąć te modyfikacje, aby jądro ponownie było kompatybilne z ABI sterownika. W przeciwieństwie do kompilacji ze źródła, kompilacja dla sterownika binarnego nie spowoduje błędu kompilacji z powodu niedopasowania parametrów funkcji lub niezgodności struktur, po prostu spowoduje awarię urządzenia podczas pracy, a debugowanie tych problemów jest bardzo trudne. W świecie komputerów PC znamy bałagan, który zostawili nam nVidia i ATi, ze względu na ich naleganie na wydawanie sterowników tylko binarnych, wyobraź sobie, że masz ten bałagan dla wszystkich sterowników, wyobraź sobie, jaką to „zabawę” tworzy.

Sprzęt komputerowy jest również ogólnie lepiej znormalizowany niż sprzęt mobilny, większość komputerów PC nie potrzebuje sterowników wibratorów, akcelerometru, żyroskopu, radia 3G, czujnika zbliżeniowego, NFC itp. Nawet na urządzeniach z 3G zwykle łączy się ze sprzętem za pomocą znormalizowanego połączenia takie jak PCMCIA lub PCI-E.

Cóż ... sterowniki i jądro nie są dokładnie takie same.

Sterowniki kontrolują antenę komórkową, Wi-Fi, Bluetooth itp. Są to zastrzeżone sterowniki, ponieważ producent musi stworzyć sposób (sterowniki) komunikowania się ze swoim sprzętem.

Jądro jest poziomem pośrednim między systemem operacyjnym / aplikacją a rzeczywistymi sterownikami (lub procesorem, pamięcią lub innym sprzętem). To właśnie pozwala twojemu systemowi / aplikacjom łączyć się z tymi elementami sprzętowymi.

Wszystkie miliony jąder, które widzisz, tak naprawdę nie różnią się tak bardzo od siebie. Zazwyczaj programista / modder bierze istniejące jądro i „poprawia” je, aby uzyskać różnicę w wydajności. Zasadniczo można powiedzieć, że dostosowują oni (w przeważającej części) „konfigurację” jądra. W świecie Androida te moddery patrzą przede wszystkim na: podkręcanie lub podkręcanie zegara procesora (ważne dla oszczędności czasu pracy baterii lub próby uruchomienia większości aplikacji intensywnie przetwarzających, takich jak emulatory gier wideo lub odtwarzanie wideo), lub patrzą na niedostateczne woltowanie (aby zaoszczędzić czas pracy baterii, uruchamiając procesor poza pierwotnie ustawionymi parametrami ... co różni się w zależności od osoby, ponieważ żadne dwa procesory nie są w 100% dokładnie takie same).

Telefony i inne wbudowane nie mają systemu BIOS zapewniającego abstrakcję między sprzętem a systemem operacyjnym, w wyniku czego system operacyjny jest kompilowany dla sprzętu, na którym jest wdrażany. Nawet urządzenia korzystające z tego samego zestawu układów mogą być konfigurowane na różne sposoby (przy użyciu alternatywnych magistral komunikacyjnych itp.) \ W rezultacie jądro musi zostać odpowiednio skompilowane. Ponieważ nie oczekuje się zmian w sprzęcie, nie jest wykonywane wykrywanie sprzętu. Jądro uruchamia się szybciej i w rezultacie jest mniejsze - jest to standardowa zasada wbudowanego systemu operacyjnego

CentOS instaluje się na innym sprzęcie, ale,

1. Wszystkie komputery różnią się mniej niż telefony,
2. Jądro Ubuntu, jądro Debiana i jądro podstawowe są różnymi źródłami jądra.

Jeśli chodzi o twój drugi punkt, zobacz odpowiedzi zamieszczone wcześniej.