Wybór narzędzi
Metoda, którą tu prezentuję, opiera się na kodzie źródłowym CyanogenMod na Androida.
Chociaż Google AOSP udostępnia jedynie narzędzie do budowania ten boot.imgplik, CyanogenMod dodaje również unpackbootimgnarzędzia pozwalające na rozpakowanie go. To narzędzie nie wydaje się specjalnie zaprojektowane dla CyanogenMod w jakikolwiek sposób, więc istnieje duże prawdopodobieństwo, że zadziała ono również na inne ROMy.
Istnieje jednak stosunkowo duża liczba opcji rozpakowania boot.imgpliku, które działają mniej więcej tak samo.
Zasadniczo takie narzędzie do rozpakowywania wyodrębni zawartość boot.imgpliku i wyświetli zestaw parametrów, które musisz przekazać do mkbootimgnarzędzia Google, aby utworzyć plik, którego konfiguracja (głównie parametry jądra i adresy pamięci) będą pasować do oryginalnego.
Oto kilka przykładów, nie testowałem ich osobiście, więc nie mogę ich polecić i przedstawiam je wyłącznie w celach informacyjnych:
Wszystkie te narzędzia (i inne, które można znaleźć w dowolnej wyszukiwarce) powinny działać w ten sam sposób, ale niektóre mogą działać lepiej niż inne w obsłudze niektórych szczególnych przypadków, które możesz napotkać na własnym urządzeniu. Jednak większość z nich, przynajmniej na arenie open source, nie wydaje się regularnie utrzymywana, więc moim zdaniem najlepszym rozwiązaniem jest posiadanie działających, utrzymywanych i udokumentowanych narzędzi, jeśli chodzi o narzędzia CyanogenMod.
Niektórzy producenci produkują pamięci ROM, które są mniej więcej dalekie od standardu AOSP (nietypowe adresy, nagłówki, format pliku itp.). Jeśli poniższa standardowa procedura nie działa, być może jedno z tych alternatywnych programów może załatwić sprawę. W przeciwnym razie będziesz musiał sprawdzić problemy specyficzne dla twojego urządzenia: niektóre wydają się wymagać określonej procedury lub nawet konkretnych narzędzi ( na przykład zadaj to pytanie dotyczące urządzeń MediaTek).
Instalacja narzędzi
Kompilowanie zestawu narzędzi CyanogenMod do boot.imgpakowania i rozpakowywania jest dość proste.
- Jeśli masz już zainstalowane pełne drzewo kodów źródłowych Androida (możesz sprawdzić moją drugą odpowiedź, aby uzyskać więcej informacji na ten temat), przejdź do
system/core/mkbootimg/katalogu (jako przypomnienie, kod źródłowy AOSP Google zapewnia tylko narzędzie do budowy boot.imgpliku, nie dostarczyć dowolne narzędzie do rozpakowywania),
Jeśli nie potrzebujesz i nie potrzebujesz tego w żadnym innym celu, łatwiejszym i szybszym rozwiązaniem jest klonowanie tylko repozytorium android_system_core CyanogenMod :
git clone https://github.com/CyanogenMod/android_system_core.git
cd android_system_core/mkbootimg/
Gdy znajdziesz się we właściwym katalogu, skompiluj i zainstaluj:
gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/
Należy pamiętać, że Google jest zastąpienie C mkbootimgz wersji Pythona , więc w przyszłych wersjach kompilacja nie może być już potrzebne do tego polecenia.
Będziesz także musiał zainstalować narzędzia Android na swoim komputerze, aby umożliwić komunikację z telefonem. Będziesz potrzebować adb(Android Debug Bridge, narzędzie powłoki pozwalające na komunikację z podsystemem debugowania Androida), adbd(powiązany demon) i fastboot(narzędzie powłoki pozwalające na komunikację z systemem bootloadera twojego telefonu).
Twoja ulubiona dystrybucja Linuksa może dostarczać je w jednym lub osobnym pakiecie, ale zwykle są one zawsze nazywane „android-tools”:
- Debian / Ubuntu:
sudo apt-get install android-tools-{adb,adbd,fastboot}
- Fedora / CentOS:
sudo yum install android-tools
- openSUSE:
sudo zypper install android-tools
Pobierz boot.imgplik
Wyodrębnij plik boot.img z pliku .zip ROM lub bezpośrednio z urządzenia:
- Z podstawowego pliku .zip ROM: niektóre aplikacje, takie jak SuperSU, mogą modyfikować boot.img bezpośrednio na urządzeniu, zastępując go standardowym, który zepsuje takie aplikacje.
- Bezpośrednio z urządzenia: niektóre osoby zgłaszają problem z czytaniem prowadzący do uszkodzenia
boot.img. IMO, te problemy są najprawdopodobniej związane ze stosowaniem złych kabli USB lub koncentratora USB i można ich po prostu uniknąć, stosując dobrej jakości kable łączące bezpośrednio telefon z komputerem. Potrzebujesz także możliwości uruchamiania ADB w trybie root (w zależności od używanej pamięci ROM, może to być trywialne lub nie).
Pierwsza metoda jest bardzo oczywista: rozpakuj plik .zip dowolnym oprogramowaniem ZIP, boot.imgplik powinien znajdować się w katalogu głównym archiwum.
W przypadku drugiej metody musisz najpierw określić (niestety specyficzną dla urządzenia) ścieżkę do urządzenia pamięci masowej, skąd boot.imgmożna pobrać zawartość. Znam dwie metody:
ls /dev/block/platform/*/by-name/(gdzie *okładki jeszcze inna nazwa folderu specyficzny dla urządzenia, są szanse, że jest to jedyny katalog poniżej platform/), dokładna nazwa do wyszukiwania jest również zależne od platformy, ale sprawia, że zwykły sens (kilka przykładów: boot, LNX(skrót dla „Linux”)). Pliki w tym katalogu są w rzeczywistości dowiązaniami symbolicznymi, a niektórzy starają się ręcznie przejść do celu, ale zalecam trzymanie się ścieżki opartej na nazwie wyższego poziomu, która, chociaż dłużej, pozostaje mniej podatna na błędy. Skończysz z taką ścieżką /dev/block/platform/sdhci-tegra.3/by-name/LNX.- Na niektórych (starszych?) Urządzeniach można znaleźć właściwe urządzenie, badając dane wyjściowe
cat /proc/mtd. Jeśli zobaczysz urządzenie mtd2powiązane z "boot"etykietą, użyjesz ścieżki /dev/mtd2.
Teraz:
- Z menu programisty telefonu:
- Włącz debugowanie w telefonie,
- Zezwól na dostęp root do ADB (ten krok dotyczy telefonów z CynogenMod, inne urządzenia mogą wymagać potencjalnie bardziej skomplikowanej procedury),
- Podłącz go do swojego komputera (a stamtąd do gościa VM, jeśli uruchamiasz narzędzia Android z poziomu maszyny wirtualnej).
Jeśli nie zostało to jeszcze zrobione, zalecam ręczne uruchomienie serwera ADB po stronie komputera, pozwoli to na bezpośrednią weryfikację klucza RSA po stronie urządzenia bez wpływu na zachowanie następujących poleceń ADB:
adb start-server
Następnie przełącz ADB w tryb root:
adb root
Na koniec powinieneś być w stanie bezpośrednio wyodrębnić boot.imgplik z urządzenia za pomocą takiego polecenia (ścieżka źródłowa i docelowa oraz nazwy podano jako przykłady, dostosuj je do swoich potrzeb i preferencji):
adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img
Polecenie skopiuje całą partycję, zarówno używaną, jak i wolną przestrzeń, więc nie dziw się, że wynikowy boot.imgplik będzie większy niż oryginalny boot.imgplik dostarczany ze standardowym plikiem .zip ROM, sama zawartość pozostaje podobna.
Po zakończeniu przesyłania odłącz telefon i nie zapomnij wyłączyć debugowania i dostępu do konta root z menu programisty.
Rozpakuj oryginalny boot.imgplik
Rozpakuj boot.imgsam plik, używając wcześniej skompilowanego polecenia:
unpackbootimg -i ./boot.img
Spowoduje to wyświetlenie kilku informacji niezbędnych do przebudowy nowego boot.imgo właściwej strukturze w stosunku do zapasów boot.img. Nie spiesz się jednak w swoim notatniku, ponieważ CyanogenMod's upackbootimgzapisuje te same informacje w kilku plikach, których będziemy używać później.
To polecenie generuje kilka plików z konkretnymi przyrostkami dodanymi do nazwy pliku wejściowego:
*-second: Jest to program ładujący drugiego etapu, opcjonalny i rzadko używany w telefonach użytkowników końcowych. Jeśli ten plik jest pusty (najczęstszy przypadek), bootloader telefonu bezpośrednio wywoła jądro Linuksa.*-zImage: To jest jądro Linuksa.*-ramdisk.gzlub *-ramdisk.lz4: dysk RAM używany do zapełniania katalogu głównego urządzenia. Rozszerzenie różni się w zależności od zastosowanego algorytmu kompresji.*-dt: Drzewo urządzeń, zapełnianie /dev.- Reszta to małe pliki, z których każdy przechowuje jedną z wartości wyświetlanych na
unpackbootimgwyjściu. Te wartości definiują parametr wiersza polecenia, który ma być przekazywany do jądra systemu Linux, oraz adresy, pod którymi bootloader będzie musiał załadować każdy obiekt w czasie uruchamiania.
Najczęściej rozpakowuje się, boot.imgaby móc edytować zawartość katalogu głównego telefonu. Jak widać powyżej, ta zawartość jest przechowywana w pliku *-ramdisk.gzlub *-ramdisk.lz4i można ją wyodrębnić za pomocą poniższych poleceń:
mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd
W przypadku dysku RAM skompresowanego LZ4 zamień ostatni krok na lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd.
Przed kontynuowaniem możesz teraz wykonać dowolną modyfikację. Warto jednak raz wykonać pełną procedurę rozpakowywania - przepakowywania - rozruchu bez zmiany czegokolwiek, aby upewnić się, że narzędzia działają zgodnie z oczekiwaniami. W przeciwnym razie w przypadku problemu nie będziesz mieć pewności, czy przyczyną jest twoja modyfikacja, czy też niekompatybilność (zobacz moje uwagi na początku dotyczące niektórych producentów wymagających niestandardowych procedur lub narzędzi).
Przebuduj, aby uzyskać nowy new-boot.imgplik
Proces budowania pamięci ROM CyanogenMod opiera się na wewnętrznym narzędziu, mkbootfsktóre tworzy boot.imgplik (dzieje się tak w build / tools / releasetools / common.py ). Jednak kroki w celu zbudowania tego narzędzia wydają mi się bezużytecznie skomplikowane, podczas gdy korzystanie z dostarczonego systemu cpiowydaje się działać równie dobrze. Główną różnicą między nimi, zgodnie z moim zrozumieniem po (bardzo) szybkim sprawdzeniu mkbootfskodu souce, wydaje się być to, że ten drugi stosuje pewne środki bezpieczeństwa, nie włączając plików kropkowych i /rootkatalogu do wynikowego archiwum, podczas gdy cpioprocedura oparta na poniższej procedurze po prostu ślepo umieści całe wybrane drzewo katalogów w archiwum.
Wniosek: niepotrzebnie skomplikowany w kompilacji z kilkoma zaletami, więc trzymajmy się narzędzi dostarczonych przez system!
Rozpocznij od utworzenia nowego dysku RAM, z ramdiskkatalogu utworzonego powyżej wpisz:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Lub, jeśli chcesz wygenerować archiwum LZ4:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4
Celem jest tutaj utworzenie nowego pliku dysku RAM o właściwościach jak najbliższych oryginalnemu (na przykład ustawienie właściciela często nie pojawia się w procedurach udostępnianych na forach i blogach, jednak było to wymagane na moim urządzeniu).
Przejdź teraz do katalogu nadrzędnego, aby wygenerować new-boot.imgsam plik.
cd ..
Jak widać powyżej, unpackbootimgpolecenie CyanogenMod generuje plik pasujący do każdego parametru oczekiwanego przez mkbootimg. Dlatego wszystko, co musisz zrobić, to wydać a, mkbootimg -haby uzyskać listę wszystkich parametrów, a następnie ustawić dla każdego z nich odpowiednią wartość za pomocą pasującego pliku. Zauważ, że niektóre parametry oczekują ścieżki do pliku, podczas gdy inne oczekują, że zawartość pliku zostanie przyjęta jako wartość. Zobacz przykład wynikowego polecenia poniżej:
mkbootimg --kernel ./boot.img-zImage \
--ramdisk ./new-boot.img-ramdisk.gz \
--second ./boot.img-second \
--cmdline "$(cat ./boot.img-cmdline)" \
--base "$(cat ./boot.img-base)" \
--pagesize "$(cat ./boot.img-pagesize)" \
--dt ./boot.img-dt \
--ramdisk_offset "$(cat ./boot.img-ramdisk_offset)"
--second_offset "$(cat ./boot.img-second_offset)" \
--tags_offset "$(cat ./boot.img-tags_offset)" \
--output ./new-boot.img
Nie ustawiono tutaj tylko dwóch parametrów:
--board: Według mojego zrozumienia, jest to tylko pole informacyjne, które pozwala wstawić nazwę modelu na obrazie wynikowym.--id: Ten nie oczekuje żadnej wartości, po prostu drukuje unikalny identyfikator po zbudowaniu obrazu (łącząc znacznik czasu i sumę kontrolną).
Prześlij new-boot.imgplik na urządzenie
- Uruchom urządzenie w trybie fastboot (inaczej tryb rozruchowy, zwykle przytrzymując przyciski zasilania i zwiększania głośności).
- Podłącz kabel USB.
Sprawdź, czy urządzenie zostało poprawnie wykryte:
sudo fastboot devices
Spróbuj uruchomić komputer za pomocą nowej pamięci ROM (jeszcze go nie flashując, więc w razie problemu wystarczy ponownie uruchomić telefon, aby odzyskać go na ścieżce, zastąp ./new-boot.imgnazwę pliku własną):
sudo fastboot boot ./new-boot.img
Jeśli telefon działa poprawnie z nowym obrazem rozruchowym, wróć do trybu szybkiego uruchamiania i trwale flashuj:
sudo fastboot flash boot ./new-boot.img
sudo fastboot reboot
Wniosek
Ta procedura może początkowo wydawać się zniechęcająca, ale gdy ją otrzymasz, zobaczysz, że tak naprawdę nie jest.
Aspekt „zniechęcający” wynika z faktu, że nie ma jednego „systemu Android”: wielu producentów i dostawców pamięci ROM wprowadza zmiany, które mogą wahać się od subtelnej różnicy ścieżek do całkowicie niestandardowego środowiska.
Co musisz zrobić, to określić postawę konkretnego urządzenia, a następnie kilka poleceń, które są odpowiednie w twoim przypadku. Gdy je zdobędziesz, możesz się do nich przykleić, a nawet łatwo napisać skrypt, jeśli będziesz ich często potrzebować.
Czasami podchodziłem do szczegółów stosunkowo niskiego poziomu, ponieważ ułatwi to rozwiązywanie problemów. Jeśli użyjesz jakiegoś „łatwiejszego” nieprzezroczystego narzędzia do zbudowania i flashowania nowego boot.imgpliku i zobaczysz, że urządzenie nie może się z nim zacząć, trudniej będzie ci ustalić, który krok poszedł źle. Tutaj, na każdym kroku, będziesz mógł porównać dane, którymi manipulujesz, z danymi pochodzącymi z oryginalnego boot.imgpliku lub danymi widocznymi na telefonie, lub spróbować na przykład odbudować boot.imgplik z oryginalnym lub nowo wygenerowanym Plik dysku RAM, aby sprawdzić, czy to robi jakąkolwiek różnicę (pozwala to ustalić, czy problem pochodzi z boot.imgprocedury generowania pliku dysku RAM lub).
