"AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk." - Koush
AnyKernel2 pushes the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables.
A working script based on DirtyV Kernel for Galaxy Nexus (tuna) is included for reference.
kernel.string=KernelName by YourName @ xda-developers
do.devicecheck=1
do.modules=1
do.cleanup=1
do.cleanuponabort=0
device.name1=maguro
device.name2=toro
device.name3=toroplus
block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device or ro.build.product for your device. There is support for up to 5 device.name# properties.
do.modules=1 will push the contents of the module directory to the same location relative to root (/) and apply 644 permissions.
do.cleanup=0 will keep the zip from removing it's working directory in /tmp/anykernel - this can be useful if trying to debug in adb shell whether the patches worked correctly.
do.cleanuponabort=0 will keep the zip from removing it's working directory in /tmp/anykernel in case of installation abort.
block=auto instead of a direct block filepath enables detection of the device boot partition for use with broad, device non-specific zips. Also accepts specifically boot or recovery.
is_slot_device=1 enables detection of the suffix for the active boot partition on slot-based devices and will add this to the end of the supplied block= path. Also accepts auto for use with broad, device non-specific zips.
ramdisk_compression=auto allows automatically repacking the ramdisk with the format detected during unpack, changing auto to gz, lzo, lzma, xz, bz2, lz4, or lz4-l (for lz4 legacy) instead forces the repack as that format.
dump_boot
split_boot
unpack_ramdisk
backup_file <file>
restore_file <file>
replace_string <file> <if search string> <original string> <replacement string>
replace_section <file> <begin search string> <end search string> <replacement string>
remove_section <file> <begin search string> <end search string>
insert_line <file> <if search string> <before|after> <line match string> <inserted line>
replace_line <file> <line replace string> <replacement line>
remove_line <file> <line match string>
prepend_file <file> <if search string> <patch file>
insert_file <file> <if search string> <before|after> <line match string> <patch file>
append_file <file> <if search string> <patch file>
replace_file <file> <permissions> <patch file>
patch_fstab <fstab file> <mount match name> <fs match type> <block|mount|fstype|options|flags> <original string> <replacement string>
patch_cmdline <cmdline entry name> <replacement string>
patch_prop <prop file> <prop name> <new prop value>
patch_ueventd <ueventd file> <device node> <permissions> <chown> <chgrp>
repack_ramdisk
flash_boot
write_boot
reset_ak
flash_dtbo
"if search string" is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists. "cmdline entry name" behaves somewhat like this as a match check for the name of the cmdline entry to be changed/added by the patch_cmdline function, followed by the full entry to replace it. "prop name" also serves as a match check in patch_prop for a property in the given prop file, but is only the prop name as the prop value is specified separately.
Similarly, "line match string" and "line replace string" are the search strings that locate where the modification needs to be made for those commands, "begin search string" and "end search string" are both required to select the first and last lines of the script block to be replaced for replace_section, and "mount match name" and "fs match type" are both required to narrow the patch_fstab command down to the correct entry.
"before|after" requires you simply specify "before" or "after" for the placement of the inserted line, in relation to "line match string".
"block|mount|fstype|options|flags" requires you specify which part (listed in order) of the fstab entry you want to check and alter.
dump_boot and write_boot are the default method of unpacking/repacking, but for more granular control, or omitting ramdisk changes entirely ("OG AK" mode), these can be separated into split_boot; unpack_ramdisk and repack_ramdisk; flash_boot respectively. flash_dtbo can be used to flash a dtbo image. It is automatically included in write_boot but can be called separately if using "OG AK" mode or creating a dtbo only zip.
Multi-partition zips can be created by removing the ramdisk and patch folders from the zip and including instead "-files" folders named for the partition (without slot suffix), e.g. boot-files + recovery-files, or kernel-files + ramdisk-files (on some Treble devices). These then contain zImage, and ramdisk, patch, etc. subfolders for each partition. To setup for the next partition, simply set block= and ramdisk_compression= for the new target partition and use the reset_ak command.
backup_file may be used for testing to ensure ramdisk changes are made correctly, transparency for the end-user, or in a ramdisk-only "mod" zip. In the latter case restore_file could also be used to create a "restore" zip to undo the changes, but should be used with caution since the underlying patched files could be changed with ROM/kernel updates.
You may also use ui_print "<text>" to write messages back to the recovery during the modification process, and file_getprop "<file>" "<property>" and contains "<string>" "<substring>" to simplify string testing logic you might want in your script.
The AK2 repo includes my latest static ARM builds of mkbootimg, unpackbootimg,busybox, xz and lz4 by default to keep the basic package small. Builds for other architectures and optional binaries (see below) are available from my latest AIK-mobile and FlashIt packages, respectively, here:
https://forum.xda-developers.com/showthread.php?t=2073775 (Android Image Kitchen thread)
https://forum.xda-developers.com/showthread.php?t=2239421 (Odds and Ends thread)
Optional supported binaries which may be placed in /tools to enable built-in expanded functionality are as follows:
mkbootfs- for broken recoveries, or, booted flash support for a script/app via bind mount to /tmp (deprecated/use with caution)flash_erase,nanddump,nandwrite- MTD block device support for devices where theddcommand is not sufficientpxa-unpackbootimg,pxa-mkbootimg- Samsung/Marvell PXA1088/PXA1908 boot.img format variant supportdumpimage,mkimage- DENX U-Boot uImage format supportunpackelf- Sony ELF kernel.elf format support, repacking as AOSP standard boot.img for unlocked bootloaderselftool,unpackelf- Sony ELF kernel.elf format support, repacking as ELF for older Sony devicesmkmtkhdr- MTK device boot image section headers supportfutility+chromeostest keys directory - Google ChromeOS signature supportBootSignature_Android.jar+avbkeys directory - Google Android Verified Boot (AVB) signature supportblobpack- Asus SignBlob signature supportdhtbsign- Samsung/Spreadtrum DHTB signature supportrkcrc- Rockchip KRNL ramdisk image support
-
Place zImage in the root (dtb and/or dtbo should also go here for devices that require custom ones, each will fallback to the original if not included)
-
Place any required ramdisk files in /ramdisk and modules in /modules (with the full path like /modules/system/lib/modules)
-
Place any required patch files (generally partial files which go with commands) in /patch
-
Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for included ramdisk files, and use methods for any required ramdisk modifications (optionally, also place banner and/or version files in the root to have these displayed during flash)
-
zip -r9 UPDATE-AnyKernel2.zip * -x .git README.md *placeholder
If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here:
Not required, but any tweaks you can't hardcode into the source (best practice) should be added with an additional init.tweaks.rc or bootscript.sh to minimize the necessary ramdisk changes.
It is also extremely important to note that for the broadest AK2 compatibility it is always better to modify a ramdisk file rather than replace it.
If running into trouble when flashing an AK2 zip, the suffix -debugging may be added to the zip's filename to enable creation of a debug .tgz of /tmp for later examination while booted or on desktop.
For further support and usage examples please see the AnyKernel2 XDA thread: https://forum.xda-developers.com/showthread.php?t=2670512
Have fun!