W jaki sposób programiści, bez kodu źródłowego, uzyskują komponenty sprzętowe, takie jak kamery, działające w niestandardowych pamięciach ROM? Odpowiedź to BLOB, podkładka i mnóstwo debugowania.
Wraz z wydaniem Androida Oreo i wielu urządzeń, takich jak Xiaomi Redmi Uwaga 3, Google Nexusie 5 I inni nieoficjalnie to otrzymali, prawdopodobnie warto się zastanowić, dlaczego te same funkcje (głównie aparat) zwykle się psują, gdy programiści przenoszą ROM oparty na Android Open Source Project (AOSP). Prawdopodobnie widziałeś wątki na forum XDA dotyczące ROM-ów z długą listą uszkodzonych funkcji na górze. „Co działa”, po którym następuje lista działających funkcji, a na dole kultowe „Co nie działa? Ty mi powiedz!" to dwa popularne refreny na naszych forach, które praktycznie stały się memami w miejscach takich jak Reddit i Twitter.
Dlaczego tak wiele funkcji jest uszkodzonych, gdy programista próbuje przenieść pamięć ROM AOSP na swoje urządzenie? Podstawowa odpowiedź jest taka, że ponieważ funkcje zmieniają się w różnych wersjach Androida, stare sterowniki urządzeń spakowane jako obiekty BLOB nie będą działać z nowszymi wersjami Androida, a nawet tylko ze standardowym AOSP. Aby temu zaradzić, programiści korzystają z tak zwanej „podkładki”, ale proces ten jest skomplikowany, czasochłonny, a czasem bardzo trudny do debugowania.
W tym artykule opiszemy działanie podkładek, szczególnie w odniesieniu do prawidłowego działania kamery na pamięciach ROM opartych na AOSP. Jako przykład posłużymy się OnePlus 3T. Należy pamiętać, że trudność związana z uruchomieniem tych funkcji jest w dużym stopniu zależna od urządzenia.
OnePlus 3T z systemem OxygenOS. Chociaż telefony OnePlus są znane ze swojej łatwości programowania na zamówienie, programiści wykonują dużo pracy za kulisami, aby stworzyć stabilne porty AOSP.
Co to jest podkładka lub BLOB?
Aby w ogóle zacząć rozumieć część tego, czym zajmują się programiści, musimy najpierw wyjaśnić kilka rzeczy. Chociaż system operacyjny Android jest systemem open source (nie bez powodu nazywany jest projektem Android Open Source), oprogramowanie (bez jądra) dostarczane na tysiące urządzeń z systemem Android nim nie jest. Programiści nie mają dostępu do kodu źródłowego Doświadczenia Samsunga, EMUI, OxygenOSlub dowolną inną wersję Androida innej firmy.
Teraz programiści przenoszący standardowe AOSP na urządzenia inne niż Google prawdopodobnie nie przejmują się kodem źródłowym tych skórek dla Androida, ponieważ nie będą modyfikowanie i budowanie tych ROM-ów. Byłaby to prawda, gdyby nie jeden, bardzo ważny powód: przede wszystkim części niezbędne do prawidłowego działania aparatu the kamera HAL (Warstwa abstrakcji sprzętu), są również zamknięte źródło.
Problem z posiadaniem zamkniętego źródła nie tylko warstwy HAL kamery, ale także pamięci ROM polega na tym, że programiści pracujący nad przeniesieniem AOSP na swoje urządzenie będą pracując na ślepo. Zamknięty kod źródłowy OEM ROM może dobrze współpracować z kamerą HAL, ponieważ producent OEM ma dostęp do źródła HAL kamery. Kamera HAL umożliwia ROMowi „rozmawianie” ze sprzętem kamery – bez niej kamera nie działałaby. Pomyśl o kamerze HAL jak o kierownicy i pedałach samochodu. Kierownica/pedały umożliwiają sterowanie wewnętrznymi komponentami pojazdu, zapewniając kierowcy zewnętrzny interfejs (ROM) umożliwiający korzystanie z wewnętrznych komponentów.
W miarę jak sprzęt aparatu staje się coraz bardziej złożony (np pojawienie się podwójnych aparatów), posiadanie dostępu do źródła HAL kamery znacznie ułatwiłoby przeniesienie pamięci ROM AOSP z funkcjonalną kamerą.
Jednakże producenci OEM z różnych powodów nie zapewniają dostępu do źródła HAL kamery. Po pierwsze, jeśli nie mają wszystkich praw własności do kamery HAL (na przykład w przypadku wykorzystania własności intelektualnej innych firm), nie mogą rozpowszechniać źródła. Po drugie, udostępnienie źródła HAL kamery może zagrozić ich własności intelektualnej. Wreszcie, firmy nie mają prawnego obowiązku udostępniania tego kodu źródłowego (w przeciwieństwie do kodu źródłowego jądra, którym są zobowiązany do wydania na licencji GPL), dlatego nie mają motywacji, aby go wypuścić. Zatem bez dostępu do źródła HAL kamery, jak dokładnie programiści sprawiają, że kamera działa na ROMach AOSP? Odpowiedź to BLOB, podkładka i mnóstwo debugowania.
Urządzenie KROPELKA (Binary Large OBject) zawiera wstępnie spakowane pliki binarne, które są skompilowaną formą oprogramowania. W tym przypadku źródło HAL kamery jest kompilowane przez producenta OEM i dostarczane na urządzeniach w postaci plików binarnych. Kiedy programiści mówią o obiektach BLOB, mają na myśli te pliki binarne dostarczane na aktywnych urządzeniach, które są w stanie wyodrębnić. Teraz pojawił się temat „BLOBów z kamer”. od dawna nękany OnePlus przez wiele miesięcy, ale prawda jest taka, że programiści zawsze mieli dostęp do obiektów BLOB kamer. The Kod źródłowy kamery HAL to złoty bilet dla programistów tutaj, ale to będzie nigdy, przenigdy nie zostać uwolnionym ze względu na zagrożenie prawne, na jakie naraziłoby to firmy takie jak OnePlus.
Dlatego programistom chcącym przenieść AOSP na urządzenie pozostają jedynie obiekty BLOB HAL kamery, dla których nie mają dostępu do kodu źródłowego. Rzadko, jeśli w ogóle, programista może sparować swój kod AOSP ROM z kamerą HAL BLOB i oczekiwać, że zadziała, więc aby wypełnić lukę między nimi, programiści tworzą tak zwany „Podkładka.”
„Podkładka” oznacza „klinowanie (czegoś) lub wypełnienie przestrzeni”. To jest faktycznie to, co robi programista, kiedy pisanie podkładki — dodają kod umożliwiający BLOB-owi komunikację z kodem źródłowym AOSP, nad którym pracują z. Podkładki służą do tego, aby wszelkiego rodzaju obiekty BLOB działały z AOSP, ale zazwyczaj to obiekt BLOB kamery wymaga najwięcej podkładek. Jak wspomnieliśmy wcześniej, podkładka jest wymagana nie tylko przy przenoszeniu nowszych wersji Androida na urządzenie (takie jak wszystkie te nieoficjalne ROMy Androida Oreo), ale są również potrzebne podczas przenoszenia AOSP tej samej wersji Androida na to urządzenie.
Rekomendowane lektury: Od sklepu do półki: dogłębna kapitulacja wyjaśniająca, dlaczego urządzenia MSM8974 są wykluczone z oferty Nougat
Swoje otrzymał na przykład OnePlus 2 ostatnia oficjalna większa aktualizacja systemu operacyjnego w postaci Androida 6.0 Marshmallow. Urządzenie jednak tak naprawdę ma w pełni działające niestandardowe ROM-y oparte na AOSP oparty na systemie Android Nougat, a to dzięki ciężkiej pracy programistów i ich podkładek. Omówimy kilka przykładów podkładek, ale najpierw musimy porozmawiać o tym, jak dokładnie działają podkładki.
Jak działa podkładanie?
Ponieważ programiści nie mają dostępu do warstwy HAL kamery ani źródła ROM OEM (a jedynie do prekompilowanych plików binarnych), nie mogą wiedzieć, jakich funkcji oczekuje HAL kamery. Z tego powodu często występuje rozbieżność między nazwą funkcji, której szuka HAL kamery, a rzeczywistą nazwą funkcji w kodzie AOSP, z którym pracuje programista.
Aby rozwiązać ten problem, programista po prostu tworzy nową funkcję, która używa tej samej nazwy funkcja, której oczekuje kamera HAL BLOB, ale ta nowa funkcja po prostu wykonuje to, czego chce programista to do. Ta nowa funkcja, która działa jako pośrednik pomiędzy obiektem BLOB i AOSP, to podkładka. Ten konkretny scenariusz, w którym obiekt BLOB nie znajduje funkcji, której szuka, jest jednym z najczęstszych, gdy potrzebna jest podkładka.
Być może sytuacja będzie miała nieco większy sens na hipotetycznym przykładzie dotyczącym OnePlus 3T. Stworzymy przykład z wykorzystaniem OxygenOS i aparatu OnePlus. Jeśli użyjemy obiektów BLOB kamery pobranych z OxygenOS Nougat dla OnePlus 3T do zbudowania pamięci ROM Nougat opartej na AOSP, możemy napotkać problemy. Dzieje się tak dlatego, że obiekty BLOB kamery (które zostały pierwotnie skompilowane przez producenta OEM) będą mogły odwoływać się do wszystkich potrzebnych funkcji w systemie OxygenOS, ale ponieważ skompilowana pamięć ROM AOSP może nie mieć tych funkcji lub mogła zostać skompilowana pod inną nazwą (co prowadzi do niezgodności symboli funkcji), wystąpi błąd błąd. Można to naprawić, tworząc nową funkcję w pamięci ROM AOSP o nazwie, której oczekuje BLOB – nasza podkładka.
Symbole w kontekście programowania służą do odwoływania się do określonych funkcji w kodzie. Symbole są konieczne, ponieważ pozycja funkcji może się zmienić podczas edycji kodu, a zatem aby uniknąć zakodowania na stałe odniesienia do funkcji, kompilator tworzy tabelę symboli, których inne funkcje mogą używać, aby zawsze odnosić się do prawej strony funkcjonować. Kiedy zmienisz nazwę funkcji przed kompilacją, zmieni się także jej symbol, a więc w zasadzie wszelkie zmiany które producent OEM wprowadza do kamery jako źródło HAL przed kompilacją, będzie wymagało od programistów utworzenia nowego Podkładka.
Z dotychczasowych wyjaśnień wynika, że tworzenie podkładek jest łatwe. Zmiana kilku nazw funkcji tu i tam nie brzmi zbyt trudno, prawda? Gdyby to było takie proste. Rzeczywistość podkładek obejmuje coś więcej niż tylko zmianę nazw funkcji. Rozmawialiśmy z uznanym programistą XDA, Sultanxdą, który był w stanie dostarczyć nam przykład jednej z trudniejszych podkładek, nad którą pracował.
Shimming – nie tak proste, jak się wydaje
Dla tych, którzy nie znają OnePlus 3T, przedni aparat był początkowo raczej zepsuty Niestandardowe ROMy oparte na AOSP. Na początek próba zrobienia dowolnego zdjęcia o rozdzielczości większej niż 8 MP zakończy się niepowodzeniem upaść. Próbując rozwiązać ten problem, Sultanxda stworzył kilka podkładki aby umożliwić prawidłowe działanie przedniego aparatu OnePlus 3T.
Podkładka nr 1 – Zmiana nazwy pakietu kamery
Aby zapobiec awarii przedniego aparatu za każdym razem, gdy użytkownik zrobi zdjęcie o rozdzielczości większej niż 8 MP, Sultanxda zmusił kamerę HAL do identyfikowania wszystkich kamer jako aparatu OnePlus. Dzieje się tak, ponieważ OnePlus zdecydował się przeznaczyć funkcję pomocniczą dla niektórych aplikacji (isOnePlusCamera, isFacebookCameraitp.) z jakiegoś powodu. Sultanxda rozwiązało ten problem, przesuwając kamerę HAL, tak aby wskazywała nową funkcję, która zawsze zwraca wartość „true”, tak jakby użytkownik korzystał z kamery OnePlus — nawet jeśli tak nie jest.
Podkładka nr 2 – Wyłącz QuadraCfa
Przy kolejnej podkładce musiał wyłączyć QuadraCfa, która jest prawdopodobnie zastrzeżoną technologią Qualcomm związaną z kamerą. Mówimy „prawdopodobnie”, ponieważ ani ja, ani Sultanxda nie jesteśmy do końca pewni, czym jest QuadraCfa, ale Sultanxda wie, że za każdym razem, gdy był włączony, psuł przedni aparat.
Zauważył, że QuadraCfa w jakiś sposób sama się włączy, ale nie był pewien, dlaczego i jak to robi. Rozwiązanie tego problemu wymagało z jego strony dość niekonwencjonalnej modyfikacji. W konwencjonalnej podkładce funkcja podkładki po skompilowaniu dostarcza brakujący symbol, którego szuka obiekt BLOB. W tym przypadku obiekt BLOB miał już potrzebne symbole – te, które prawdopodobnie reprezentowały funkcje uruchamiające QuadraCfa.
Musiał więc zastąpić symbole używane przez kamerę HAL i w istocie sprawić, by takowe „brakowały”. jego podkładki zapewniłyby te „brakujące” symbole. Można to zrobić wyłącznie za pośrednictwem hex edycja samej kamery HAL. Edycja szesnastkowa polega w zasadzie na przeglądaniu niezorganizowanego bełkotu w postaci danych binarnych w celu znalezienia igły w stogu siana — albo funkcji, albo ciągu znaków, który chcesz edytować.
Edycja szesnastkowa funkcji jest znacznie trudniejsza niż edycja szesnastkowa ciągu, ale na szczęście Sultanxda mógł zamiast tego uniknąć konieczności edycji szesnastkowej funkcji za QuadraCfa hex edytując nazwy symboli, aby unieważnić te symbole.
Podkładka nr 3 — Naprawa awarii przy jasnym świetle
Następnie Sultanxda stwierdził, że zrobienie zdjęcia przednim aparatem w jasnym oświetleniu spowoduje awarię aparatu. Aby odtworzyć ten błąd na swoim własnym urządzeniu, właściwie Sultanxda włączył funkcję latarki w swoim OnePlus One i zaświecił światło przed przednią kamerą OnePlus 3T aby spowodować awarię i wygenerować użyteczne dzienniki! Gdy odkrył, która funkcja powoduje awarię, stworzył podkładkę, która wymusza na urządzeniu ciągłe używanie trybu słabego oświetlenia dla przedniego aparatu.
Podkładka nr 4 — Zdjęcia z przedniego aparatu w niskiej rozdzielczości
Po naprawieniu awarii jasnego światła za pomocą poprzedniej podkładki, Sultanxda odkrył kolejny błąd, który w rzeczywistości powstał bezpośrednio w wyniku tej podkładki: zdjęcia z przedniego aparatu o niskiej rozdzielczości. Zamiast robić zdjęcia w rozdzielczości żądanej przez użytkownika (np. 16MP), powstałe zdjęcie zostanie wykonane w rozdzielczości 4MP.
Rozwiązanie tego wymagało podkładania funkcji handleSuperResolution I isSuperResolution aby zawsze zwracać wartość true, ale TYLKO wtedy, gdy przedni aparat jest aktywny (w przeciwnym razie aparat zawieszałby się podczas robienia zdjęć z tylnego czujnika).
Wyciągnięta lekcja — podkładki mogą być trudne
Sultanxda przyznaje, że podkładki, które musiał stworzyć, aby przedni aparat OnePlus 3T działał, nie reprezentują typowego przykładu podkładki. Jest raczej dumny ze swojej podkładki, biorąc pod uwagę jej złożoność i rzadką konieczność edycji heksadecymalnej samego BLOB-a. Ale ten przykład tylko pokazuje, jak trudne może być uruchomienie sprzętu aparatu na niektórych urządzeniach.
Niech Twoje przygody z podkładkami do aparatu będą mniej bolesne niż moje. -Sułtanxda
Logi, logi i jeszcze raz logi. Bez spójnego sposobu odtworzenia awarii i bez dzienników programiści mają niewielkie szanse na znalezienie źródła problemu. Nawet jeśli znajdą przyczynę problemu, nie zawsze jest to proste rozwiązanie. Cały proces znajdowania i usuwania tych błędów może zająć dni lub tygodnie i dlatego naprawianie kamery na ROMach AOSP jest jednym z trudniejszych zadań.
Jeśli do Twojego urządzenia przeniesiono pamięć ROM AOSP z w pełni funkcjonalnym sprzętem, możesz zacząć doceniam wysiłek, jaki musieli przebyć ci programiści, aby je dostarczyć cechy. Doceniajmy ich za ich pracę, bo to nie jest łatwe. To mnóstwo pracy, której zdecydowana większość użytkowników nawet nie zauważy, ponieważ utalentowani programiści na naszych forach zajmują się wieloma niewidocznymi częściami Androida.
Chcielibyśmy szczególnie podziękować Sultanxdzie za liczne uwagi, które zasugerował podczas tworzenia tego artykułu.