- check for and remove patch for multi-partition/reset_ak (so removal of ramdisk/ and patch/ with the addition of $(basename block)-files is now the full trigger)
- wipe $(basename block)-files/ramdisk to ensure proper copied output, as the original contents are retained in the copied rdtmp
- for ramdisk-only changes that don't require added files or patch snippets, create the $(basename block)-files subfolder for proper output backup with reset_ak
- if no ramdisk is found in the zip, check for and copy files in from "$(basename $block)-files", e.g. boot-files + recovery-files subfolders, each which can contain their own zImage, and ramdisk and patch subfolders, etc.
- as part of the reset_ak command, copy the output files back to the corresponding *-files subfolder for use in debugging
* when ak2-core.sh gets run again by reset_ak after changing block= in anykernel.sh the above process begins again
- was only available in the update-binary, so allow in anykernel.sh as well, for use with checking /system/build.prop, /default.prop, $ramdisk/default.prop, etc.
- clean up false error output where sections are already removed on repeat flashes
- move size check to just before flash since we must compare against the fully repacked, signed boot-new.img
- place version text in a file named "version" in the root of the zip and it will display after the kernel.string when flashing
- useful in conjunction with build scripts, i.e. a generated version file not actually part of the kernel AK2 repo
elftool fails to repack the ELF boot image on Sony devices when a custom dtb file is not provided within the AnyKernel2 zip, because the "dtb" variable, that contains the name of the dtb file, is overridden before the dtb filename is actually passed to the "rpm" variable. Swapping these two lines of code fixes the issue (tested by me on a Sony Xperia SP).
Currently, trying to use insert_line to insert something on the second
to last line fails and places it on the last line.
AK2 line:
insert_line test "sched_boost 0" after "on property:sys.boot_completed=1" " write /proc/sys/kernel/sched_boost 0"
Before:
on property:sys.boot_completed=1
bootchart stop
After:
on property:sys.boot_completed=1
bootchart stop
write /proc/sys/kernel/sched_boost 0
Expected result:
on property:sys.boot_completed=1
write /proc/sys/kernel/sched_boost 0
bootchart stop
In this example, the file length is 2 but the line we're inserting
at is also 2, which is perfectly fine because everything will get
shifted down by 1. Only if the file length is less than the desired
position (in this example, 3) should be handled by >>. All three
cases are now handled fine by insert_line (position 1, 2, and 3).
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
- introduce reset_ak function to reset the /tmp/anykernel directory to allow for multi-partition mods; use after changing the AK2 shell (block, etc.) variables again
- make patch_cmdline more intuitive; match the string, and if it doesn't exist add the replacement string, and if so replace with it
- allow AVBv1 signing of recovery by adding simple partition type detection based on name
- restore LD_LIBRARY_PATH after AVBv1 signing to be friendly to recovery when flashed in between other zips
After working on the OnePlus 5/T with custom ROMs on Android 8.1.0, I
have noticed that several of them have modules in /system/lib/modules
with a context of "u:object_r:vendor_file:s0", which goes against the
assumption made in commit 6b11373 ("update-binary: Change how we handle
modules"). Because the context is changed, there is an SELinux denial
when trying to load the module during init.
While it would be nice for ROMs to fix that on their own, I suspect
they are not entirely at fault. Google's documentation does state that
all modules should be loaded from vendor whenever possible so I would
guess Google decided to force *.ko objects to have a vendor_file
context. This is all speculation as I haven't cared to do research into
the subject.
Easiest way around this is to just worry about applying contexts to new
modules. cp does not override contexts so if the module was already
present, we can assume it has the correct context to begin with.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
As of Oreo, Google is requiring that kernel modules be used whenever
possible and that their location be in /vendor. With Lineage 15.1,
devices without a separate /vendor partition will use /system/vendor,
which symlinked to /vendor.
To make this more flexible and future proof, allow developers to specify
where each module needs to go by setting the path in the modules folder.
If a module needs to go to /system/vendor/lib/modules, then the module
should be placed in modules/system/vendor/lib/modules. Contexts and
permissions will still be updated automatically.
Android documentation: https://source.android.com/devices/architecture/kernel/modular-kernels
Lineage 15.1 commit: https://github.com/LineageOS/android_vendor_lineage/commit/bf38db2a5e358a5449458b3dee2dd9d4015b8147
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
- split dump_boot into split_boot + unpack_ramdisk and write_boot into repack_ramdisk + flash_boot
- fully backwards compatible as dump_boot and write_boot still exist and call these new functions (i.e. no changes needed to anykernel.sh)
- those that wish to do zImage-only AK2 packages can now use split_boot intead of dump_boot and and flash_boot instead of repack_ramdisk in their anykernel.sh
- add failsafe check for failed boot-new.img creation to ensure abort before wiping target partition in edge cases
- hide some expected stderr for AK2 mods with no additional ramdisk files
- fix U-Boot support by passing correct repacked ramdisk filename
- fix multi-compression support during repack derp
- fix cleanup on successful flash not working due to double match from cleanuponabort
- dtbo may be added as dtbo or dtbo.img to the base of the zip
- new Pixel 2 ro.boot.slot doesn't contain _ like Pixel ro.boot.slot_suffix does
Thanks @nathanchance for the majority of the work and research on this one, via #12
osm0sis