답변:
여기에 제시된 방법은 CyanogenMod의 Android 소스 코드에 의존합니다.
구글의 AOSP 만 할 수있는 도구를 제공하지만 구축boot.img 파일을 사이 애 노젠 모드도 추가 unpackbootimg당신이 할 수 있도록 도구를 풀고 그것을. 이 도구는 CyanogenMod를 위해 특별히 설계된 것처럼 보이지 않으므로 다른 ROM에서도 작동 할 가능성이 높습니다.
그러나 boot.img파일의 압축을 풀기위한 비교적 많은 대안이 있지만 모두 동일한 방식으로 작동합니다.
기본적으로 이러한 압축 풀기 도구는 boot.img파일 의 컨텐츠를 추출하고 Google mkbootimg도구에 전달해야하는 매개 변수 세트를 표시 합니다.이 구성 (주로 커널 매개 변수 및 메모리 주소)이 원래 파일과 일치하는 파일을 빌드합니다.
다음은 몇 가지 예입니다. 개인적으로 테스트하지 않았으므로 추천 할 수 없으며 참조 목적으로 만 제시합니다.
몇 가지는 오픈 소스 또는 스크립트 기반입니다.
일부는 무료 비공개 소스 전용 바이너리입니다.
unmkbootimg 는 도움말 포럼에 자주 등장하며 이상한 경우를 처리하는 데 도움이되고 mkbootimg소스 코드 에서 일부 수정이 필요할 때 "사람이 읽을 수있는"영어 권장 사항을 출력 하고 이미지를 다시 작성하는 데 사용할 정확한 명령 줄을 표시하는 데 도움이됩니다.mkbootimg_tools 도 꽤 자주 언급 된 것으로 보이며 boot.img장치 트리 파일의 압축을 풀고 다시 포장 할 수 있습니다 dt.img. 이 GitHub의에서 호스팅되는 사실에 속지 마십시오 : 그것은 이다 닫힌 소스 독점적 인 바이너리 만 컴파일 된 바이너리가 저장소에서 사용할 수있는 (사실 난 저장소에 소스 코드 저장소를 사용하여 정확한 관심에 대해 궁금하네요 이진 얼룩이지만 다른 사람들, 다른 마음 ...).이러한 모든 도구 (및 검색 엔진에서 찾을 수있는 도구)는 모두 같은 방식으로 작동해야하지만 일부 장치는 자신의 장치를 사용하는 특정 엣지 케이스를 처리 할 때 다른 도구보다 더 효과적 일 수 있습니다. 그러나 대부분 오픈 소스 분야에서는 정기적으로 유지 관리되지 않는 것 같으므로 작업, 유지 관리 및 문서화 된 도구를 사용하는 것이 CyanogenMod의 도구와 함께하는 것이 가장 좋습니다.
일부 제조업체는 AOSP 표준 (특별한 주소, 헤더, 파일 형식 등)과 다소 다른 ROM을 생산합니다. 아래의 표준 절차가 작동하지 않으면 이러한 대체 소프트웨어 중 하나가 트릭을 수행 할 수 있습니다. 그렇지 않으면 장치와 관련된 문제를 확인해야합니다. 일부 절차에는 특정 절차 나 특정 도구가 필요한 것 같습니다 ( 예를 들어 MediaTek 장치와 관련된 이 질문에 해당).
boot.img포장 및 포장 풀기를 위한 CyanogenMod 툴셋 컴파일 은 매우 간단합니다.
system/core/mkbootimg/(디렉토리 알리미, 구글의 AOSP 소스 코드 만 구축하기 위해 도구를 제공하는 boot.img파일을, 그들은 할 수 없습니다 포장 풀기 도구 제공)다른 목적으로 이것을 필요로하지 않고 필요하지 않은 경우 더 쉽고 빠른 해결책은 CyanogenMod의 android_system_core 저장소 만 복제하는 것 입니다.
git clone https://github.com/CyanogenMod/android_system_core.git
cd android_system_core/mkbootimg/
올바른 디렉토리에 있으면 컴파일하고 설치하십시오.
gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/
Google은 C mkbootimg를 Python 버전으로 대체하고 있으므로 향후 버전에서는이 명령에 더 이상 컴파일이 필요하지 않을 수 있습니다.
휴대 전화와 통신 할 수 있도록 컴퓨터에 Android 도구를 설치해야합니다. 당신이 필요합니다 adb(안드로이드 디버그 브리지, 안드로이드의 디버그 서브 시스템과 통신 할 수 있도록 쉘 유틸리티), adbd(관련 데몬)과 fastboot(휴대 전화의 부트 로더 시스템과 통신 할 수 있도록 쉘 유틸리티).
선호하는 Linux 배포판은 단일 또는 별도의 패키지로 제공 할 수 있지만 일반적으로 항상 "android-tools"라고합니다.
sudo apt-get install android-tools-{adb,adbd,fastboot}sudo yum install android-toolssudo zypper install android-toolsboot.img파일을 가져옵니다ROM .zip 파일에서 또는 장치에서 직접 boot.img를 추출하십시오.
boot.img합니다. IMO는 이러한 문제가 USB 케이블 또는 USB 허브의 불량과 관련이있을 가능성이 높으며 전화를 컴퓨터에 직접 연결하는 양질의 케이블을 사용하면 피할 수 있습니다. 또한 루트 모드에서 ADB를 실행할 수있는 기능이 필요합니다 (사용 된 ROM에 따라 사소한 것일 수도 있습니다).첫 번째 방법은 매우 분명합니다. ZIP 소프트웨어로 .zip 파일을 추출하면 파일 boot.img이 아카이브의 루트에 있어야합니다.
두 번째 방법의 경우 먼저 boot.img컨텐츠를 검색 할 수있는 저장 장치에 대한 (슬픈 장치 별) 경로를 결정 해야합니다. 나는 이것에 대한 두 가지 방법을 알고있다 :
ls /dev/block/platform/*/by-name/(여기서는 *다른 장치 별 폴더 이름을 다루지 만 platform/검색 할 정확한 이름은 플랫폼에 따라 다르지만 일반적으로 의미가 있습니다 (일부 예 : boot, LNX( "Linux"의 약어)). 이 디렉토리의 파일은 실제로 심볼릭 링크이며 일부 사람들은 수동으로 대상으로 이동하는 것을 귀찮게하지만 더 긴 시간 동안 오류가 덜 발생하는 높은 수준의 이름 기반 경로를 사용하는 것이 좋습니다. 그래서 당신은 같은 경로로 끝날 것 /dev/block/platform/sdhci-tegra.3/by-name/LNX입니다.cat /proc/mtd. 레이블 mtd2과 관련된 장치가 표시 "boot"되면 경로를 사용합니다 /dev/mtd2.지금:
이 작업이 아직 완료되지 않은 경우 컴퓨터 측에서 ADB 서버를 수동으로 시작하는 것이 좋습니다. 이렇게하면 다음 ADB 명령의 동작에 영향을주지 않고 장치 측에서 RSA 키를 직접 확인할 수 있습니다.
adb start-server
그런 다음 루트 모드에서 ADB를 전환하십시오.
adb root
마지막으로 boot.img이러한 명령을 사용하여 장치 에서 파일 을 직접 추출 할 수 있어야합니다 (소스 및 대상 경로 및 이름은 예제로 제공되며 필요와 환경 설정에 맞게 조정).
adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img
이 명령은 사용 된 공간과 사용 가능한 공간 둘 다의 전체 파티션을 복사하므로 결과 boot.img파일이 boot.imgstock ROM .zip 파일과 함께 제공되는 원본 파일 보다 클 것이라는 사실에 놀라지 마십시오 . 내용 자체는 비슷하게 유지됩니다.
전송이 완료되면 전화 연결을 끊고 개발자 메뉴에서 디버깅 및 루트 액세스를 모두 비활성화하는 것을 잊지 마십시오.
boot.img파일의 압축을 풉니 다boot.img이전에 컴파일 된 명령을 사용하여 파일 자체의 압축을 푸십시오 .
unpackbootimg -i ./boot.img
이것은 boot.img주식과 관련하여 올바른 구조로 새로운 것을 재건하는 데 필수적인 몇 가지 정보를 출력 합니다 boot.img. 그러나 CyanogenMod upackbootimg는 나중에 사용할 여러 파일에 동일한 정보를 저장하기 때문에 메모장을 서두르지 마십시오 .
이 명령은 입력 파일 이름에 특정 접미사가 추가 된 여러 파일을 생성합니다.
*-second: 이것은 2 단계 부트 로더이며, 선택 사항이며 최종 사용자 전화에는 거의 사용되지 않습니다. 이 파일이 비어 있으면 (가장 일반적인 경우) 전화의 부트 로더가 Linux 커널을 직접 호출합니다.*-zImage: 이것은 Linux 커널입니다.*-ramdisk.gz또는 *-ramdisk.lz4: 장치의 루트 디렉토리를 채우는 데 사용되는 RAM 디스크. 확장명은 사용 된 압축 알고리즘에 따라 다릅니다.*-dt: 장치 트리가 채워 /dev집니다.unpackbootimg출력에 표시된 값 중 하나를 저장하는 작은 파일 입니다. 이 값은 명령 행 매개 변수를 정의하여 Linux 커널로 전달하고 부트 로더가 부트시 각 오브젝트를로드해야하는 주소를 정의합니다.가장 자주, boot.img전화의 루트 디렉토리의 내용을 편집 할 수 있도록 압축을 풉니 다 . 위에서 본 것처럼이 컨텐츠는 *-ramdisk.gz또는 *-ramdisk.lz4파일에 저장되며 아래 명령을 사용하여 추출 할 수 있습니다.
mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd
LZ4 압축 RAM 디스크의 경우 마지막 단계를로 바꿉니다 lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd.
이제 진행하기 전에 원하는 수정을 자유롭게 할 수 있습니다. 그러나 도구가 예상대로 작동하는지 확인하기 위해 아무것도 변경하지 않고 전체 압축 풀기-재 포장-부팅 절차를 한 번 수행하는 것이 좋습니다. 그렇지 않으면 문제가 발생한 경우 원인이 수정 또는 비 호환성인지 확실하지 않습니다 (비표준 절차 또는 도구가 필요한 일부 제조업체에 대해서는 처음에 언급 한 내용 참조).
new-boot.img파일 을 얻기 위해 다시 빌드CyanogenMod ROM 빌드 프로세스 mkbootfs는 boot.img파일 을 생성하기 위해 내부 도구 를 사용 합니다 ( build / tools / releasetools / common.py에서 발생 ). 그러나이 도구를 작성하는 단계는 나에게 쓸모없는 것처럼 보이지만 시스템 제공을 사용하는 cpio것은 잘 작동 하는 것처럼 보입니다. mkbootfssouce 코드 에서 (매우) 빠른 검사 후 내 이해에 따라 두 가지의 주요 차이점 은 후자가 점진 파일과 /root디렉토리를 결과 아카이브에 포함시키지 않음으로써 cpio아래 의 기반 절차를 수행 하여 온 전성 조치를 적용하는 것으로 보입니다. 선택한 디렉토리 트리 전체를 맹목적으로 아카이브에 넣습니다.
결론 : 장점이 거의없이 컴파일하기가 불필요하게 복잡하므로 시스템 제공 도구를 고수합시다!
ramdisk위에서 만든 디렉토리 에서 새 RAM 디스크를 작성하여 시작하십시오 .
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
또는 LZ4 아카이브를 생성해야하는 경우 :
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4
여기서 목표는 가능한 한 원래 속성과 가까운 속성을 가진 새 RAM 디스크 파일을 만드는 것입니다 (예를 들어, 소유자 및 포럼에서 공유 된 절차에서 소유자를 설정하는 것이 종종 보이지만 장치에 필요했습니다).
new-boot.img파일 을 생성하려면 상위 디렉토리로 이동 하십시오.
cd ..
위에서 볼 수 있듯이 CyanogenMod의 unpackbootimg명령은에 필요한 각 매개 변수와 일치하는 파일을 생성합니다 mkbootimg. 따라서 mkbootimg -h모든 매개 변수 목록을 가져 오기 위해 a 를 발행 한 다음 일치하는 파일을 사용하여 각 매개 변수를 적절한 값으로 설정하면됩니다. 일부 매개 변수는 파일 경로를 필요로하는 반면 다른 매개 변수는 파일 내용을 값으로받을 것으로 예상합니다. 아래 결과 명령의 예를 참조하십시오.
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
여기에는 두 개의 매개 변수 만 설정되지 않습니다.
--board: 내 이해에 따르면, 이것은 결과 이미지에 모델 이름을 삽입 할 수있는 유익한 필드 일뿐입니다.--id: 이것은 값을 기대하지 않으며 이미지가 작성된 후에 (타임 스탬프와 체크섬을 결합하여) 고유 식별자를 인쇄합니다.new-boot.img장치에 파일을 플래시장치가 올바르게 감지되었는지 확인하십시오.
sudo fastboot devices
새 ROM을 사용하여 부팅을 시도하십시오 (아직 깜박이지 않고 문제가 발생하는 경우 휴대 전화를 다시 시작해야 트레일로 되돌릴 ./new-boot.img수 있습니다).
sudo fastboot boot ./new-boot.img
전화가 새 부팅 이미지로 성공적으로 작동하면 빠른 부팅 모드로 돌아가서 영구적으로 플래시합니다.
sudo fastboot flash boot ./new-boot.img
sudo fastboot reboot
이 절차는 처음에는 어려워 보일 수 있지만 일단 일단 받으면 실제로 그렇지 않다는 것을 알 수 있습니다.
"매우 어려운"측면은 단일 "Android 시스템"이 없다는 사실에서 비롯됩니다. 많은 제조업체와 ROM 제공 업체는 미묘한 경로 차이에서 완전히 비표준 환경에 이르기까지 범위를 변경할 수 있습니다.
당신이해야 할 일은 특정 장치의 자세를 결정한 다음 귀하의 경우에 적합한 몇 가지 명령입니다. 일단 당신이 그들을 얻으면, 당신은 그들을 고수하고 자주 필요할 때 쉽게 스크립트를 작성할 수 있습니다.
자발적으로 문제를보다 쉽게 해결할 수 있기 때문에 가끔 저수준의 세부 정보를 보았습니다. 새 boot.img파일 을 빌드하고 플래시하기 위해 "쉬운"불투명 한 유틸리티를 사용하고 장치가 해당 파일로 시작할 수 없는지 확인하면 어떤 단계가 잘못되었는지 결정하기가 더 어려워집니다. 여기에서 각 단계에서 조작하는 데이터와 원본 boot.img파일 에서 오는 데이터 또는 전화기에 표시되는 데이터를 비교하거나 예를 들어 boot.img원본 또는 새로 생성 된 파일을 사용하여 파일 을 다시 빌드 할 수 있습니다 RAM 디스크 파일을 확인하여 차이가 있는지 확인하십시오 (문제는 boot.imgRAM 디스크 파일 생성 절차에서 발생 했는지 여부를 정확하게 알 수 있음 ).
Android Kitchen을 사용하십시오 . boot.img의 압축을 풀고 다시 포장하는 옵션이 아래에 Advanced options있습니다.