หน้านี้ให้รายละเอียดกระบวนการสร้าง เคอร์เนล แบบกำหนดเองสำหรับอุปกรณ์ Android คำแนะนำเหล่านี้จะแนะนำคุณตลอดกระบวนการในการเลือกแหล่งที่มาที่เหมาะสม การสร้างเคอร์เนล และการฝังผลลัพธ์ลงในอิมเมจระบบที่สร้างจาก Android Open Source Project (AOSP)
คุณสามารถรับแหล่งเคอร์เนลที่ใหม่กว่าได้โดยใช้ Repo ; สร้างโดยไม่ต้องกำหนดค่าเพิ่มเติมโดยเรียกใช้ build/build.sh
จากรูทของการชำระเงินต้นทางของคุณ
กำลังดาวน์โหลดแหล่งที่มาและสร้างเครื่องมือ
สำหรับเคอร์เนลล่าสุด ให้ใช้ repo
เพื่อดาวน์โหลดซอร์ส, toolchain และสร้างสคริปต์ เคอร์เนลบางตัว (เช่น เคอร์เนล Pixel 3) ต้องการแหล่งที่มาจากที่เก็บ git หลายแห่ง ในขณะที่บางเมล็ด (เช่น เคอร์เนลทั่วไป) ต้องการแหล่งที่มาเพียงแหล่งเดียว การใช้แนวทาง repo
ช่วยให้แน่ใจว่าการตั้งค่าไดเร็กทอรีต้นทางถูกต้อง
ดาวน์โหลดแหล่งข้อมูลสำหรับสาขาที่เหมาะสม:
mkdir android-kernel && cd android-kernel
repo init -u https://android.googlesource.com/kernel/manifest -b BRANCH
repo sync
ตารางต่อไปนี้แสดงรายการชื่อ BRANCH สำหรับเมล็ดที่พร้อมใช้งานผ่านวิธีนี้
อุปกรณ์ | เส้นทางไบนารีในต้นไม้ AOSP | สาขา Repo |
---|---|---|
พิกเซล 6 (oriole) Pixel 6 Pro (กา) | อุปกรณ์/google/raviole-kernel | android-gs-raviole-5.10-android12L |
Pixel 5a (บาร์บีคิว) | อุปกรณ์/google/barbet-kernel | android-msm-barbet-4.19-android12L |
พิกเซล 5 (redfin) Pixel 4a (5G) (หนาม) | อุปกรณ์/google/redbull-kernel | android-msm-redbull-4.19-android12L |
Pixel 4a (ปลาซันฟิช) | อุปกรณ์/google/sunfish-kernel | android-msm-sunfish-4.14-android12L |
พิกเซล 4 (เปลวไฟ) Pixel 4 XL (สีคอรัล) | อุปกรณ์/google/coral-kernel | android-msm-coral-4.14-android12L |
Pixel 3a (ซาร์โก้) Pixel 3a XL (โบนิโต) | อุปกรณ์/google/bonito-kernel | android-msm-bonito-4.9-android12L |
พิกเซล 3 (เส้นสีน้ำเงิน) Pixel 3 XL (แบบไขว้) | อุปกรณ์/google/crosshatch-kernel | android-msm-crosshatch-4.9-android12 |
พิกเซล 2 (ตาล) Pixel 2 XL (ไท่เหมิน) | อุปกรณ์/google/wahoo-kernel | android-msm-wahoo-4.4-android10-qpr3 |
พิกเซล (ปลาเซลฟิช) Pixel XL (มาร์ลิน) | อุปกรณ์/google/marlin-kernel | android-msm-marlin-3.18-pie-qpr2 |
Hikey960 | อุปกรณ์/linaro/hikey-เคอร์เนล | hikey-linaro-android-4.14 hikey-linaro-android-4.19 common-android12-5.4 |
บีเกิ้ล x15 | อุปกรณ์/ti/beagle_x15-kernel | omap-beagle-x15-android-4.14 omap-beagle-x15-android-4.19 |
เคอร์เนลทั่วไปของ Android | ไม่มี | ทั่วไป-android-4.4 common-android-4.9 common-android-4.14 common-android-4.19 common-android-4.19-stable common-android11-5.4 common-android12-5.4 common-android12-5.10 common-android-mainline |
การสร้างเคอร์เนล
จากนั้นสร้างเคอร์เนลด้วยสิ่งนี้:
build/build.sh
ไบนารีเคอร์เนล โมดูล และอิมเมจที่เกี่ยวข้องจะอยู่ในไดเร็กทอรี out/ BRANCH /dist
การสร้างโมดูล GKI
Android 11 เปิดตัว GKI ซึ่งแยกเคอร์เนลออกเป็นเคอร์เนลอิมเมจที่ดูแลโดย Google และโมดูลที่ดูแลโดยผู้ขายซึ่งสร้างขึ้นแยกต่างหาก
ตัวอย่างนี้แสดงคอนฟิกูเรชันอิมเมจเคอร์เนล:
BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh
ตัวอย่างนี้แสดงการกำหนดค่าโมดูล (Cuttlefish and Emulator):
BUILD_CONFIG=common-modules/virtual-device/build.config.cuttlefish.x86_64 build/build.sh
ใน Android 12 Cuttlefish และ Goldfish มาบรรจบกัน พวกมันจึงใช้เคอร์เนลเดียวกัน: virtual_device
ในการสร้างโมดูลของเคอร์เนลนั้น ให้ใช้การกำหนดค่าบิลด์นี้:
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.x86_64 build/build.sh
การรันเคอร์เนล
มีหลายวิธีในการเรียกใช้เคอร์เนลที่สร้างขึ้นเอง ต่อไปนี้เป็นวิธีที่ทราบแล้วซึ่งเหมาะสมกับสถานการณ์การพัฒนาต่างๆ
การฝังลงในการสร้างอิมเมจ Android
คัดลอก Image.lz4-dtb
ไปยังตำแหน่งไบนารีเคอร์เนลตามลำดับภายในแผนผัง AOSP และสร้างอิมเมจสำหรับเริ่มระบบใหม่
หรือกำหนดตัวแปร TARGET_PREBUILT_KERNEL
ในขณะที่ใช้ make bootimage
(หรือบรรทัดคำสั่ง make
อื่นๆ ที่สร้างอิมเมจสำหรับบูต) อุปกรณ์ทั้งหมดรองรับตัวแปรนี้เนื่องจากได้รับการตั้งค่าผ่าน device/common/populate-new-device.sh
ตัวอย่างเช่น:
export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb
กะพริบและบูตเมล็ดด้วย fastboot
อุปกรณ์ล่าสุดส่วนใหญ่มีส่วนขยาย bootloader เพื่อปรับปรุงกระบวนการสร้างและบูตอิมเมจสำหรับบูต
ในการบูตเคอร์เนลโดยไม่กระพริบ:
adb reboot bootloader
fastboot boot Image.lz4-dtb
เมื่อใช้วิธีนี้ เคอร์เนลจะไม่ถูกแฟลชจริง ๆ และจะไม่คงอยู่ในระหว่างการรีบูต
การปรับแต่งเคอร์เนล build
กระบวนการสร้างและผลลัพธ์สามารถได้รับอิทธิพลจากตัวแปรสภาพแวดล้อม ส่วนใหญ่เป็นทางเลือกและแต่ละสาขาเคอร์เนลควรมาพร้อมกับการกำหนดค่าเริ่มต้นที่เหมาะสม รายการที่ใช้บ่อยที่สุดแสดงไว้ที่นี่ สำหรับรายการทั้งหมด (และล่าสุด) อ้างถึง build/build.sh
ตัวแปรสภาพแวดล้อม | คำอธิบาย | ตัวอย่าง |
---|---|---|
BUILD_CONFIG | สร้างไฟล์กำหนดค่าจากตำแหน่งที่คุณเริ่มต้นสภาพแวดล้อมการสร้าง ต้องกำหนดตำแหน่งให้สัมพันธ์กับไดเรกทอรีรากของ Repo ค่าเริ่มต้น build.config บังคับสำหรับเมล็ดทั่วไป | BUILD_CONFIG=common/build.config.gki.aarch64 |
CC | แทนที่คอมไพเลอร์ที่จะใช้ ย้อนกลับไปที่คอมไพเลอร์เริ่มต้นที่กำหนดโดย build.config | CC=clang |
DIST_DIR | ไดเร็กทอรีเอาต์พุตฐานสำหรับการกระจายเคอร์เนล | DIST_DIR=/path/to/my/dist |
OUT_DIR | ไดเร็กทอรีเอาต์พุตฐานสำหรับการสร้างเคอร์เนล | OUT_DIR=/path/to/my/out |
SKIP_DEFCONFIG | ข้าม make defconfig | SKIP_DEFCONFIG=1 |
SKIP_MRPROPER | ข้าม make mrproper | SKIP_MRPROPER=1 |
การกำหนดค่าเคอร์เนลแบบกำหนดเองสำหรับบิลด์ในเครื่อง
หากคุณต้องการเปลี่ยนตัวเลือกการกำหนดค่าเคอร์เนลเป็นประจำ ตัวอย่างเช่น เมื่อทำงานกับคุณสมบัติ หรือหากคุณต้องการตัวเลือกที่จะตั้งค่าเพื่อวัตถุประสงค์ในการพัฒนา คุณสามารถบรรลุความยืดหยุ่นนั้นได้โดยคงไว้ซึ่งการปรับเปลี่ยนในเครื่องหรือสำเนาของการกำหนดค่าบิลด์
ตั้งค่าตัวแปร POST_DEFCONFIG_CMDS เป็นคำสั่งที่ประเมินทันทีหลังจากขั้นตอน make defconfig
ปกติเสร็จสิ้น เนื่องจากไฟล์ build.config
มีที่มาจากสภาพแวดล้อมการสร้าง ฟังก์ชันที่กำหนดไว้ใน build.config
สามารถเรียกเป็นส่วนหนึ่งของคำสั่ง post-defconfig
ตัวอย่างทั่วไปคือการปิดใช้งานการเพิ่มประสิทธิภาพเวลาลิงก์ (LTO) สำหรับเคอร์เนล crosshatch ระหว่างการพัฒนา แม้ว่า LTO จะเป็นประโยชน์สำหรับเคอร์เนลที่ปล่อยออกมา แต่ค่าใช้จ่าย ณ เวลาที่สร้างอาจมีนัยสำคัญ ข้อมูลโค้ดต่อไปนี้ที่เพิ่มใน build.config
โลคัลปิดใช้งาน LTO อย่างต่อเนื่องเมื่อใช้ build/build.sh
POST_DEFCONFIG_CMDS="check_defconfig && update_debug_config"
function update_debug_config() {
${KERNEL_DIR}/scripts/config --file ${OUT_DIR}/.config \
-d LTO \
-d LTO_CLANG \
-d CFI \
-d CFI_PERMISSIVE \
-d CFI_CLANG
(cd ${OUT_DIR} && \
make O=${OUT_DIR} $archsubarch CC=${CC} CROSS_COMPILE=${CROSS_COMPILE} olddefconfig)
}
การระบุเวอร์ชันเคอร์เนล
คุณสามารถระบุรุ่นที่ถูกต้องเพื่อสร้างจากสองแหล่งที่มา: แผนผัง AOSP และอิมเมจระบบ
เวอร์ชันเคอร์เนลจากต้นไม้ AOSP
แผนผัง AOSP มีเวอร์ชันเคอร์เนลที่สร้างไว้ล่วงหน้า บันทึก git เปิดเผยเวอร์ชันที่ถูกต้องซึ่งเป็นส่วนหนึ่งของข้อความยืนยัน:
cd $AOSP/device/VENDOR/NAME
git log --max-count=1
หากเวอร์ชันเคอร์เนลไม่อยู่ในบันทึก git ให้ดาวน์โหลดจากอิมเมจระบบตามที่อธิบายไว้ด้านล่าง
เวอร์ชันเคอร์เนลจากอิมเมจระบบ
ในการพิจารณาเวอร์ชันเคอร์เนลที่ใช้ในอิมเมจระบบ ให้รันคำสั่งต่อไปนี้กับไฟล์เคอร์เนล:
file kernel
สำหรับไฟล์ Image.lz4-dtb
ให้เรียกใช้:
grep -a 'Linux version' Image.lz4-dtb
การสร้างภาพบูต
เป็นไปได้ที่จะสร้างอิมเมจสำหรับบูตโดยใช้สภาพแวดล้อมการสร้างเคอร์เนล ในการดำเนินการนี้ คุณต้องมีไบนารี ramdisk ซึ่งสามารถรับได้โดยการดาวน์โหลดอิมเมจสำหรับบูต GKI และเปิดออก อิมเมจสำหรับบูต GKI จากรุ่น Android ที่เกี่ยวข้องจะใช้งานได้
tools/mkbootimg/unpack_bootimg.py --boot_img=boot-5.4-gz.img
mv tools/mkbootimg/out/ramdisk gki-ramdisk.lz4
โฟลเดอร์เป้าหมายคือไดเร็กทอรีระดับบนสุดของเคอร์เนลทรี (ไดเร็กทอรีการทำงานปัจจุบัน)
หากคุณกำลังพัฒนาด้วย AOSP master คุณสามารถดาวน์โหลด ramdisk-recovery.img
build artifact จาก aosp_arm64 build บน ci.android.com และใช้เป็นไบนารี ramdisk ของคุณ
เมื่อคุณมีไบนารี ramdisk และได้คัดลอกไปยัง gki-ramdisk.lz4
ในไดเร็กทอรีรูทของเคอร์เนลบิลด์ คุณสามารถสร้างอิมเมจสำหรับบูตได้โดยดำเนินการ:
BUILD_BOOT_IMG=1 SKIP_VENDOR_BOOT=1 KERNEL_BINARY=Image GKI_RAMDISK_PREBUILT_BINARY=gki-ramdisk.lz4 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
หากคุณกำลังทำงานกับสถาปัตยกรรมที่ใช้ x86 ให้แทนที่ Image
ด้วย bzImage
และ aarch64
ด้วย x86_64
:
BUILD_BOOT_IMG=1 SKIP_VENDOR_BOOT=1 KERNEL_BINARY=bzImage GKI_RAMDISK_PREBUILT_BINARY=gki-ramdisk.lz4 BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh
ไฟล์นั้นอยู่ในไดเร็กทอรีสิ่งประดิษฐ์ $KERNEL_ROOT/out/$KERNEL_VERSION/dist
ภาพบูตอยู่ที่ out/<kernel branch>/dist/boot.img