• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[DEV][TEMPLATE] AnyKernel3 - Easily Mod ROM Ramdisk + Pack Image.gz [Flashable Zip]

Search This thread

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
14,912
33,757
Halifax
GT-i9250
Google Nexus 4
@osm0sis Hey man i hope you are fine, Any better way to detect if magisk is there (rooted device) in android 12 than *[ -d /data/adb/magisk ]* ?, Thanks.
In AK3 or in general? In general on a booted device probably yeah, or just run `magisk` or something. For recovery Magisk module installs I look for /data/adb/modules.

AK3 automatically checks the new ramdisk during repack and/or flash and performs actions:
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L214-L216
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L317-L346
 

negrroo

Senior Member
In AK3 or in general? In general on a booted device probably yeah, or just run `magisk` or something. For recovery Magisk module installs I look for /data/adb/modules.

AK3 automatically checks the new ramdisk during repack and/or flash and performs actions:
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L214-L216
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L317-L346
I was using the previous method with anykernel.sh to detect if magisk it will create a magisk module
but now i cannot detect if there is a magisk installed or not by it
 

negrroo

Senior Member
In AK3 or in general? In general on a booted device probably yeah, or just run `magisk` or something. For recovery Magisk module installs I look for /data/adb/modules.

AK3 automatically checks the new ramdisk during repack and/or flash and performs actions:
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L214-L216
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L317-L346
offcourse [ -d $ramdisk/.backup ] not working also
 

AnnoyingZlatan

Senior Member
Jun 5, 2012
355
794
Tuzla
Hey, how would I go about debugging patch_cmdline function? All of a sudden it stopped working (last time I used it few months ago and it worked fine) as in it won't patch existing cmdline params nor edit the already existing ones. First I thought it was A12 meme but even on A11 (where it worked before obviously else I wouldn't be using it) it fails. I'm sussing some of the security patches causing the issue but want to check if there's a way I can "make sure" that ak3 is doing it's thing properly.
 

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
14,912
33,757
Halifax
GT-i9250
Google Nexus 4
In AK3 or in general? In general on a booted device probably yeah, or just run `magisk` or something. For recovery Magisk module installs I look for /data/adb/modules.

AK3 automatically checks the new ramdisk during repack and/or flash and performs actions:
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L214-L216
https://github.com/osm0sis/AnyKernel3/blob/master/tools/ak3-core.sh#L317-L346

I'll put my OP9Pro on the 12 Beta after testing the upcoming TWRP release and check it out.

Okai let me know please, Thanks
Tried this with the pulled OOS 12 "stable", and Magisk detection still worked perfectly; it only needs to repatch if there's a new kernel in the zip, so it's based around that, see the links I listed.
 

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
14,912
33,757
Halifax
GT-i9250
Google Nexus 4
AOSP hdr v4 and Android 12 support is here!

Thanks to @topjohnwu for fixing magiskboot for boot v4 and to at least not mangle vendor_boot v4 anymore (though there are still some caveats, see below), and big thanks to @eng.stk for his contributions implementing stop-gap solutions for vendor_boot v4 (to be flashed whole until fully unpacking the v4 multi-ramdisk is supported in magiskboot) and vendor_dlkm (flashed as long as it's not larger than the original since it's a dynamic partition and nobody's worked out resizing an existing partition on-the-fly for AK3 yet; see the TODO comments in the flash_generic commit), spurring AK3 development on even though I've been winding things down as my becoming a parent rapidly approaches! 😬😊

My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!

Backend: support Android 12 .capex (compressed apex) files:
https://github.com/osm0sis/AnyKernel3/commit/d432fd5721512762db0a81e2fead95d818a3dcc2

AK3: add full vendor_boot.img flash support:
https://github.com/osm0sis/AnyKernel3/commit/146f9b27c5f48f7c5f68d73af1cdbd6d7b821609

AK3: add full vendor_dlkm.img flash support:
https://github.com/osm0sis/AnyKernel3/commit/2b7f6e8889e736940c766709f13cf68f242be7ef

Increment AK_BASE_VERSION for latest changes:
https://github.com/osm0sis/AnyKernel3/commit/ae28b9dc92b106a08d2d2f0d776666acec5652ef

tools: update magisk utils to e097c097(23015+) CI:
- adds partial hdr v4 support (cannot currently unpack vendor_boot v4 multi-ramdisk or bootconfig)
- use upstream CI build since it includes an AVBv2 signature padding fix, resolving all known regressions

https://github.com/osm0sis/AnyKernel3/commit/a312a2bdc9cf3183d8202489e9f242b0db3c91f3

AK3: add flash_generic to reduce code duplication:
https://github.com/osm0sis/AnyKernel3/commit/297d6c3b99e0088b93db970080e7422ec121f333

README: update for flash_generic and vendor_dlkm:
https://github.com/osm0sis/AnyKernel3/commit/89c8c54f4a9b463f2dc44d3672d6405dd7397b0e

README: update remaining flash_dtbo references:
https://github.com/osm0sis/AnyKernel3/commit/4950e80ca20e744ac57d979b1f68d81c5f9a587e

AK3: unbreak anykernel scripts using flash_dtbo directly:
https://github.com/osm0sis/AnyKernel3/commit/08a76000ad4f0993c91df8c0098fd988e5440536

AK3+Backend: grep cleanups:
https://github.com/osm0sis/AnyKernel3/commit/66f42c1951cb46f4452b1b9a32914593174772e7

AK3: add magiskboot KEEPVBMETAFLAG support:
- some devices fail to boot when magiskboot changes the vbmeta flag is set in the AVBv2 signature from 00 to 03, this allows disabling that behavior
- set keep_vbmeta_flag=1 in anykernel.sh to force it to keep whatever's there, =auto will take it from the existing image if Magisk-patched (Canary 23015 or later), and =0 will allow the default magiskboot behavior

https://github.com/osm0sis/AnyKernel3/commit/6e7fcd6d28be647e83ca2d97192f3e96418cf401

anykernel: add keep_vbmeta_flag:
https://github.com/osm0sis/AnyKernel3/commit/f7490f764cd400cdd312d89db012792e18cf997d

Example: add commented keep_vbmeta_flag to vendor_boot setup:
DO NOT MERGE if you have already updated your ramdisk properly for your device

https://github.com/osm0sis/AnyKernel3/commit/78f08d471e4eca9d0ddb09bd39922d9af966d823

AK3: better backwards compatibility for keep_vbmeta_flag (unset=auto):
https://github.com/osm0sis/AnyKernel3/commit/12baa2739addb25e2b50095fa8139969d808045b

Backend: fix devicecheck now that we can't abuse file_getprop with .*:
https://github.com/osm0sis/AnyKernel3/commit/1edb7e9f399ce00cbec96d47f43b7c458da86e1e

AK3: update KEEPVBMETAFLAG -> PATCHVBMETAFLAG for Canary 23016+:
https://github.com/osm0sis/AnyKernel3/commit/fb5fbb15160c0ebc8696228c259ace1f5d6a250d

anykernel: change keep_vbmeta_flag -> patch_vbmeta_flag:
https://github.com/osm0sis/AnyKernel3/commit/d7d7aebf7a516d379de7dde2816384a721caba9c

Example: change commented vendor_boot setup to patch_vbmeta_flag:
DO NOT MERGE if you have already updated your ramdisk properly for your device

https://github.com/osm0sis/AnyKernel3/commit/19cf85643b82c9f77e0859187c809ccf34f22220

tools: update magisk utils to 92546e8a(23016) canary:
https://github.com/osm0sis/AnyKernel3/commit/11cb678fb30c5602cbe6cbb29ebea083047c4102

README: document patch_vbmeta_flag feature:
https://github.com/osm0sis/AnyKernel3/commit/42e9c3a9a90e9f86ef97087bdf9f724b8df62bbd

Note: The new default magiskboot behavior in Canary 23016+ is to not patch the boot vbmeta flag to 03 anymore, so now AK3 has inverted the feature as well and patch_vbmeta_flag can be forced if needed.

If anyone has a hdr v4 device (pretty much just Pixel 6 right now) and can experiment to figure out the commands for lptools_static to resize and replace vendor_dlkm on a live system for AK3, please do and submit a Pull Request! Resources to be adapted are here:
https://github.com/phhusson/vendor_lptools
https://github.com/phhusson/lp-self-flash

Happy holidays and stay safe out there!
 
Last edited:
  • Like
Reactions: eng.stk and ipdev

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
14,912
33,757
Halifax
GT-i9250
Google Nexus 4
help, please, I'm trying to create my own enykernel.zip, but I got to the point where you need to specify block = and I don't know where I can get this value or with which utility who can see it please help
If you can't figure out how to look in /dev/block and find the partition yourself then I'm not sure I can help you. There's an alternative to directly specifying the partition explained in the README, which you must not have read, but again, I worry for your device and users since you don't seem to understand what you're doing.

Edit: Not trying to gatekeep here, just legitimately concerned you'll brick your device and have no concept what happened or how to fix it. Read more about device partitions, fastboot, and how to interact with them.
 
Last edited:
If you can't figure out how to look in /dev/block and find the partition yourself then I'm not sure I can help you. There's an alternative to directly specifying the partition explained in the README, which you must not have read, but again, I worry for your device and users since you don't seem to understand what you're doing.

Edit: Not trying to gatekeep here, just legitimately concerned you'll brick your device and have no concept what happened or how to fix it. Read more about device partitions, fastboot and how to interact with them.
I'm trying to do this for personal use and I perform all the actions on a non-main device so there are no problems, I would just be very happy for a hint on how exactly to find it
 

Top Liked Posts

  • There are no posts matching your filters.
  • 317
    AnyKernel3 -- Flashable Zip Template for Kernel Releases with Ramdisk Modifications

    "AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk." - Koush

    The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allowed a device-specific kernel zImage to be flashed over device-specific ROM and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.

    The drawback to this was that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. Enter AnyKernel2.

    AnyKernel2 pushed 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 to customize the installation experience to their kernel. AnyKernel3 adds the power of topjohnwu's magiskboot for wider format support by default.

    A script based on Galaxy Nexus (tuna) is included for reference. An example of ramdisk-only changes can be seen in my GN Synapse Injector repo. For an example that also modifies ROM and properly injects init.d support using busybox run-parts and sepolicy-inject see CosmicDan's CosmicTweaks project. For a multi-partition example and an example of how to handle a device which only has a ramdisk when rooted see my N5X/6P BLOD Workaround Injector. Other working AK2/3 examples for more recent devices may be found on eng.stk's blu_spark device repos under Releases.

    Please see the linked posts here for instructions on enabling full AVBv1 (Pixel), AVBv1, A/B slot and/or system-as-root (SAR) or 2-stage init (2SI) device support, and further guidelines for system-as-root/2-stage init (/system/system in recovery) modifications in general.

    Please also see the post here for important notes about the current state of AOSP vendor_boot v4 support, vendor_dlkm flashing support, and AVBv2 flag options.


    Magisk root is automatically detected and retained by patching the new Image.*-dtb as Magisk would!


    My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!


    Source:
    https://github.com/osm0sis/AnyKernel3/
    Download: https://github.com/osm0sis/AnyKernel3/archive/master.zip


    Instructions

    1)
    Place final kernel build product, e.g. Image.gz-dtb or zImage to name a couple, in the zip root (any separate dt, dtb, recovery_dtbo, dtbo and/or vendor_dlkm should also go here for devices that require custom ones, each will fallback to the original if not included)
    2) Place any required ramdisk files in /ramdisk (/vendor_ramdisk for simple multi-partition vendor_boot support) and module files in /modules (with the full path like /modules/system/lib/modules)
    3) Place any required patch files (generally partial files which go with AK3 file editing commands) in /patch (/vendor_patch for simple multi-partition vendor_boot support)
    4) Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for any added 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)
    5) `zip -r9 UPDATE-AnyKernel3.zip * -x .git README.md *placeholder`

    The LICENSE file must remain in the final zip to comply with licenses for binary redistribution and the license of the AK3 scripts.


    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:
    [DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]

    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. On newer devices Magisk allows these within /overlay.d - see examples.

    It is also extremely important to note that for the broadest AK3 compatibility it is always better to modify a ramdisk file rather than replace it.

    If running into trouble when flashing an AK3 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.


    Staying Up-To-Date

    Now that you've got a ready zip for your device, you might be wondering how to keep it up-to-date with the latest AnyKernel commits. AnyKernel2 and AnyKernel3 have been painstakingly developed to allow you to just drop in the latest update-binary and tools directory and have everything "just work" for beginners not overly git or script savvy, but the best practice way is as follows:

    1) Fork my AnyKernel3 repo on GitHub
    2) `git clone https://github.com/<yourname>/AnyKernel3`
    3) `git remote add upstream https://github.com/osm0sis/AnyKernel3`
    4) `git checkout -b <devicename>`
    5) Set it up like your <devicename> zip (i.e. remove any folders you don't use like ramdisk or patch, delete README.md, and add your anykernel.sh and optionally your Image.*-dtb if you want it up there) then commit all those changes
    6) `git push --set-upstream origin <devicename>`
    7) `git checkout master` then repeat steps 4-6 for any other devices you support

    Then you should be able to `git pull upstream master` from your master branch and either merge or cherry-pick the new AK3 commits into your device branches as needed.


    Enjoy!
    Questions, comments and feedback welcome.



    Credits & Thanks: All authors of the included binaries and the tools I used to port them over for their amazing work. koush for the original AnyKernel concept.

    Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
    128
    Script Commands Reference

    Everything to edit is self-contained in anykernel.sh. A quick-reference for the commands and properties included are as follows.


    Properties / Variables

    These are some values that will be read during the install process, allowing you to customize your installation, e.g. block= is a shell variable to specify the kernel/boot block partition that the dump_boot command method will copy and unpack.

    Code:
    kernel.string=KernelName by YourName @ xda-developers
    do.devicecheck=1
    do.modules=1
    do.systemless=1
    do.cleanup=1
    do.cleanuponabort=0
    device.name1=maguro
    device.name2=toro
    device.name3=toroplus
    device.name4=tuna
    supported.versions=6.0 - 7.1.2
    supported.patchlevels=2019-07 -
    
    block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
    is_slot_device=0;
    ramdisk_compression=auto;
    patch_vbmeta_flag=auto;

    do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device, ro.build.product, ro.product.vendor.device or ro.vendor.product.device from the build.prop files for your device. There is support for as many device.name# properties as needed. You may remove any empty ones that aren't being used.

    do.modules=1 will push the .ko contents of the modules directory to the same location relative to root (/) and apply correct permissions. On A/B devices this can only be done to the active slot.

    do.systemless=1 (with do.modules=1) will instead push the full contents of the modules directory to create a simple "ak3-helper" Magisk module, allowing developers to effectively replace system files, including .ko files. If the current kernel is changed then the kernel helper module automatically removes itself to prevent conflicts.

    do.cleanup=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) - 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 its working directory in /tmp/anykernel (by default) in case of installation abort.

    supported.versions= will match against ro.build.version.release from the current ROM's build.prop. It can be set to a list or range. As a list of one or more entries, e.g. 7.1.2 or 8.1.0, 9 it will look for exact matches, as a range, e.g. 7.1.2 - 9 it will check to make sure the current version falls within those limits. Whitespace optional, and supplied version values should be in the same number format they are in the build.prop value for that Android version.

    supported.patchlevels= will match against ro.build.version.security_patch from the current ROM's build.prop. It can be set as a closed or open-ended range of dates in the format YYYY-MM, whitespace optional, e.g. 2019-04 - 2019-06, 2019-04 - or - 2019-06 where the last two examples show setting a minimum and maximum, respectively.

    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, recovery, or vendor_boot.

    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, and using cpio or none will (attempt to) force the repack as uncompressed.

    patch_vbmeta_flag=auto allows automatically using the default AVBv2 vbmeta flag on repack, and use the Magisk configuration (Canary 23016+). Set to 0 forces keeping whatever is in the original AVBv2 flags, and set to 1 forces patching the flag (only necessary on few devices).

    customdd="<arguments>" may be added to allow specifying additional dd parameters for devices that need to hack their kernel directly into a large partition like mmcblk0, or force use of dd for flashing.

    slot_select=active|inactive may be added to allow specifying the target slot. If omitted the default remains active.

    no_block_display=1 may be added to disable output of the detected final used partition+slot path for zips which choose to include their own custom output instead.


    Command Methods

    Code:
    ui_print "<text>" [...]
    abort ["<text>" [...]]
    contains <string> <substring>
    file_getprop <file> <property>
    
    set_perm <owner> <group> <mode> <file> [<file2> ...]
    set_perm_recursive <owner> <group> <dir_mode> <file_mode> <dir> [<dir2> ...]
    
    dump_boot
    split_boot
    unpack_ramdisk
    
    backup_file <file>
    restore_file <file>
    replace_string <file> <if search string> <original string> <replacement string> <scope>
    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> <scope>
    remove_line <file> <line match string> <scope>
    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
    flash_generic <partition name>
    write_boot
    
    reset_ak [keep]
    setup_ak

    "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.

    "scope" may be specified as "global" to force all instances of the string/line targeted by replace_string, replace_line or remove_line to be replaced/removed accordingly. Omitted or set to anything else and it will perform the default first-match action.

    "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_generic can be used to flash an image to the corresponding partition. It is automatically included for dtbo and vendor_dlkm in write_boot but can be called separately if using "OG AK" mode or creating a simple partition flashing 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 Image.gz, and ramdisk, patch, etc. subfolders for each partition. To setup for the next partition, simply set block= (without slot suffix) and ramdisk_compression= for the new target partition and use the reset_ak command.

    Similarly, multi-slot zips can be created with the normal zip layout for the active (current) slot, then resetting for the inactive slot by setting block= to the partition (without slot suffix) again, slot_select=inactive and ramdisk_compression= to the desired options for the target slot and using the reset_ak keep command, which will retain the patch and any added ramdisk files for the next slot.

    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, abort "<text>" to abort with optional message, and file_getprop "<file>" "<property>" and contains "<string>" "<substring>" to simplify string testing logic you might want in your script.


    Binary Inclusion

    The AK3 repo includes current ARM builds of magiskboot, magiskpolicy and busybox by default to keep the basic package small. Builds for other architectures and optional binaries (see below) are available from the latest Magisk zip, or my latest AIK-mobile and Flashlt packages, respectively, here:

    https://forum.xda-developers.com/t/...kernel-ramdisk-win-android-linux-mac.2073775/ (Android Image Kitchen thread)
    https://forum.xda-developers.com/t/...-and-ends-multiple-devices-platforms.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 the dd command is not sufficient
    dumpimage, mkimage - DENX U-Boot uImage format support
    mboot - Intel OSIP Android image format support
    unpackelf, mkbootimg - Sony ELF kernel.elf format support, repacking as AOSP standard boot.img for unlocked bootloaders
    elftool (with unpackelf) - Sony ELF kernel.elf format support, repacking as ELF for older Sony devices
    mkmtkhdr (with unpackelf) - MTK device boot image section headers support for Sony devices
    futility + chromeos test keys directory - Google ChromeOS signature support
    boot_signer-dexed.jar + avb keys directory - Google Android Verified Boot 1.0 (AVBv1) signature support
    rkcrc - Rockchip KRNL ramdisk image support

    Optionally moving ARM builds to tools/arm and putting x86 builds in tools/x86 will enable architecture detection for use with broad, device non-specific zips.
    48
    AnyKernel3 (AK3) Release

    Welcome to AK3: AnyKernel2 + Magisk = AnyKernel3!:
    - abstract out execution directory as $home to fascilitate testing individual scripts (defaults to /tmp/anykernel)
    - general script clean ups for uniformity, readability, speed and simplicity
    - simplify consecutive `ui_print` commands where possible

    Backend only fixes:
    - use busybox umount and mount whenever possible to avoid linker warnings in stderr during system-as-root setup
    - use `busybox --install -s` for bin/* setup
    - consolidate setup to abort earlier if there are issues
    - add backwards compatible symlinks for those who might not have updated their anykernel.sh with ak3-core.sh (to be renamed in subsequent commit)

    Tools only fixes:
    - add magiskboot to replace separate support for AOSP and PXA-AOSP formats, with MTK headers, BLOB, DHTB, SEAndroid and Nook signing
    - add magiskpolicy to allow for easy sepolicy patching
    - remove xz and lz4 since magiskboot supports these (and all other formats except lzop)
    - magiskboot also resolves long-standing request for built-in Bump support (#18)

    AK3 Core only fixes:
    - use full `ui_print` function implementation like the backend
    - add `abort` function to simplify exit on errors
    - fix $patch directory being excluded from `reset_ak`
    - update $ramdisk_compression handling for magiskboot
    - update Sony ELF and related support for initial repack as AOSP by using mkbootimg as plug-and-play optional add-in binary
    - update Sony ELF MTK header support using mkmtkhdr only when ELF is initially unpacked by unpackelf
    - add support for MTK RECOVERY ramdisk header type with Sony ELF
    - simplify U-Boot dumpimage/mkimage and Sony ELF unpackelf/mkbootimg split_img file handling
    - update patch_cmdline to handle both magiskboot as header prop file, and unpackelf or mboot as cmdline.txt
    - use `cp -fp` for `backup_file` and `restore_file` to hopefully better preserve attributes if used outside of the ramdisk
    - refactor setup into `setup_ak` to simplify `reset_ak` trigger to find slot and block again
    - add fallback to busybox for compression formats (i.e. lzop) which magiskboot cannot handle

    IMPORTANT NOTES:
    1) forcing repack with uncompressed cpio ramdisk is not currently supported by magiskboot
    2) forcing repack with lzop ramdisk when previously another format is not currently supported by magiskboot

    https://github.com/osm0sis/AnyKernel3/commit/698682123053cab9e3277c9c9df783a97b3e8958

    tools: rename ak2-core.sh to ak3-core.sh:
    https://github.com/osm0sis/AnyKernel3/commit/cba94d3103ec92380717052a69bb6e37b15ad853

    anykernel: Update for AK3:
    https://github.com/osm0sis/AnyKernel3/commit/8724d881595abd529376cb6fe2205b69a05021dd

    README: Update for AK3:
    https://github.com/osm0sis/AnyKernel3/commit/a10312941ade81955d2217caa0e90dae553bb697

    AK3: fix elftool repack cmdline handling:
    https://github.com/osm0sis/AnyKernel3/commit/c8d087bbad6442546a3f85610e3eaa2d867de021

    AK3: allow workaround for dtbo devices with cat /dev/zero issues:
    https://github.com/osm0sis/AnyKernel3/commit/24032c07328cd2ed9b7c2e57d63d351d52425cf0

    README: updates and touchups for AK3:
    https://github.com/osm0sis/AnyKernel3/commit/5fdf659d01f0fed87b44c3dbc6103d4146b694d5

    AK3: resolve non-zero return code introduced by `cat <img> /dev/zero > <block>`:
    https://github.com/osm0sis/AnyKernel3/commit/97de781a55f09cca631982511789e1ff95badc8f

    Alright! The big day is here. Huge thanks to @topjohnwu for working with me to add the necessary features to magiskboot so I could keep virtually all feature parity with AnyKernel2. Plus the rewrite to magiskboot allowed me to do a thorough code review and includes more format support by default and ensures much better ongoing format support as magiskboot continues to be developed. I wrote this intentionally so that basically all current AK2 zips should be able to be immediately upgradeable using the initial patch, or even just dropping the updated tools/core and backend in.

    Of course pay close attention to merge conflicts for the main AK3 rewrite commit and the anykernel.sh updates, especially since many have added an older version of magiskboot/magiskpolicy unofficially to their zips for root repatching, but note you will need the current included builds since they are a couple commits ahead of even the current Magisk Canary. Going forward let me keep the included ARM magiskboot/magiskpolicy up to date, since I'll be ensuring they work correctly before updating them.

    Thanks also to @eng.stk and @Freak07 for their help testing during the AK3 BETA .patch phase. I also throughly tested most things throughout the rewrite on my OnePlus 6T so things should definitely be all good for OnePlus devices. :D:highfive:

    Edit: Added a couple more commits today to resolve issues on devices where dtbo partition flashing is required. Thanks @MSF Jarvis for reporting the issue, and help testing to find a solution. :)
    18
    Happy New Year!

    Despite me being away on vacation here's a big update to module handling thanks to @nathanchance. If you are currently pushing modules with AK2 you will need to move the files under "modules/" to reflect their destination subfolder to avoid breakage, e.g. "modules/system/lib/modules/", "modules/system/vendor/lib/modules/" and/or "modules/vendor/lib/modules/"; this will be pretty future proof so was worth the while.

    update-binary: Change how we handle modules:
    https://github.com/osm0sis/AnyKernel2/commit/6b11373d4ae91b10ce4745e380ee3d4b440fbde6

    README: Update documentation for modules:
    https://github.com/osm0sis/AnyKernel2/commit/218b5774d26f1ff1c0acd3bec273153f5b529cb2

    example: Update modules folder for new location handling:
    https://github.com/osm0sis/AnyKernel2/commit/a0b6db2784a3cd121a4af768a68ec88fc97c550a
    15
    Thanks guys!

    I figured it would be nice to get it out there and also have it as a "Help Desk" thread for kernel devs who have questions about implementation, etc. too. Some devices might require switching it from dd to MTD-Utils, so I can help with that. So on and so forth. :)

    Once we get a few devs who know how to use it, it should be pretty easy to help others. I'm looking at you Smitty. ;) No pressure. :p