yashsingh1/xdaforums huggingface dataset:
[Android Software Development] osm0sis:
Android Image Kitchen v1.8

Uploaded the new version to the OP. Looks like people are downloading AIK more rapidly than ever before, with 3556 downloads since mid-September! Thank you all. :D

v1.8 Changelog:

Drag and drop and commandline unpackimg does not need to be from within the same directory anymore. Drag from anywhere!

Fixed support for filenames with spaces.

Commandline option repackimg -o or --original will make it repack using the original split ramdisk, useful for testing and for trimming dumps.

Remove all magic entries but those required for compression support, slimming the zip down again to less than v1.5 was.

Latest Cygwin binaries and libraries.

Switched to my own mkbootimg builds, which include all the fixes from the previous custom builds plus shows all (previously hidden) commandline switches, now uses offsets instead of addresses, supports longer kernel cmdline and adds dtb support.

Also my own heavily improved unpackbootimg, which now splits the second stage image if it exists, dtb image if it exists, and exports all the offset information mkbootimg uses now.

General script cleanup, and better error catching so that the window shouldn't just disappear when there's an issue.

More on my own build changes in the commits here: https://github.com/osm0sis/mkbootimg/commits/master

Notes:

The updated mkbootimg and unpackbootimg should once again expand device support immensely. They also allowed me to remove the batch workaround for the old unpackbootimg not exporting ramdiskaddr and allowed me to remove some unneeded binaries in the process. As for the -o option, an example of use was when the KitKat 4.4 OTA dropped for the N7 '12, I upgraded, dumped the stock kernel and trimmed it via this method (8MB -> 4MB); the resulting image was identical to the Factory Image boot.img when later posted. It's also useful in figuring out where in the repack process something might be broken. :good:

If you are reporting a problem with your device, please clearly state your device name and model/variant as well as provide a link to the image file.
[Android Software Development] Xanza89:
Awesome, thanks for this.
[Android Software Development] inunxelex:
[MENTION=4544860]osm0sis[/MENTION]

its has different size and binary from original recovery, without changing everything, only unpack then repack, is it save to flash ? :confused:
[Android Software Development] osm0sis:
Yes, that's only the ramdisk size changing slightly because it doesn't repack identically due to various reasons (like doing it on Windows instead of Linux, for example). If you scroll down a little you'll also see the ramdisk hash is different. That's all to be expected and nothing to be concerned with. You'll note the rest of the header is exactly the same, which is what I worked hard on for this release. :)

In a nutshell, yeah it should be fine, it's always been like that. :good:
[Android Software Development] inunxelex:
Confirmed working on recovery for Lenovo A706 :good:

http://xdaforums.com/showthread.php?t=2391801

boot.img not tested yet :D

edit:

boot.img also working :good:
[Android Software Development] shoey63:
Or none of the above.

Need to use a fastboot command to disable it in the vbmeta partition for some slot A/B devices.
[Android Software Development] davek17:
OK, so can you just clarify what DTO and DTBO stands for?

I also don't know what the vbmeta partition is? I have tried to use Fastboot to disable DM-Verity but it didn't seem to work, although with the authentication in place I would imagine the boot process doesn't get that far without stopping.

So to conclude. in the old days where the default.prop and fstab file were in the root of the RAMDISK, I changed a few lines in these files.

NOW

We need to change the ro. settings in the /system/etc/prop.default, of course needing to root in some way to do that, and then to remove DM-verity we need to do that via a fastboot command or find the same fstab file in the DTO/DTBO?
[Android Software Development] osm0sis:
dtb/dtbo, and yeah.

dtbo=Device Tree Blob Overlay. Magisk patches them to remove dm-verity, might be the easiest way to get what you want nowadays.
[Android Software Development] shoey63:
Depends on device and firmware. Dtbo (device tree blob overlay) can be appended to the kernel or a separate partition. It needs to be hex patched to remove "verify" flags. This is what the Magiskboot binary does.

fastboot --disable-verity --disable-verification vbmeta.img

is used to achieve the same goal on some slot A/B devices.

At any rate AIK doesn't perform these functions.

Edit: see above post by [MENTION=4544860]osm0sis[/MENTION][emoji5]
[Android Software Development] davek17:
Cheers for clearing that up guys. So I will look into that. I think a lot of OS's, especially MTK based ones have this issue now but even worse, they have new MD5 authentication to contend with too (Authentication file requirement in SPFT), so you can't re-lock the bootloader after any kind of changes. Because you need to root the device now to change even the boot settings. Hopefully a solution can be found soon somehow.
[Android Software Development] jcmm11:
Sorry for the off topic but I suspect there's some knowledgeable people in this thread. Does anyone know what I would need to do to create an update.zip that I could apply via adb sideload and stock recovery? On a Pixel 3a to be exact.
[Android Software Development] anvesh583:
I am trying to edit ramdisk by unpacking boot.img on ubuntu . Opening the default.prop gives an error . " The link default.prop is broken" and cant be used since its target system/etc/prop.default doesn't exist. Any solution is welcomed. Also how to use the -- help to see the commands?
[Android Software Development] shoey63:
See post #2166. Only one page back
[Android Software Development] anvesh583:
Alright where can I see the help commands?
[Android Software Development] starbucks2010:
Unpacking - Unrecognized format error

Hello,

Sorry for the noobish question, but I just finished compiling a kernel for S10 and ended up with a file named Image of 41 Mb.

I tried to unpack it but I get an error: Unrecognized format.

What seems to be the issue?

Thanks in advance.
[Android Software Development] osm0sis:
Image is likely the uncompressed kernel. You should also have an Image.gz and/or Image.gz-dtb. None of these are a boot.img so can't be unpacked by AIK.
[Android Software Development] starbucks2010:
Hi,

Thanks for your fast reply. I have fixed that. You was right abut the image.

Now, I have unpacked the

stock

S10 kernel but I get the message: Warning: no ramdisk found to be unpacked!

Do you know why the tool couldn't find the ramdisk or why this kernel wouldn't have one?

Thank you.
[Android Software Development] ashyx:
Recent Pie devices do not have the ramdisk in the boot image any more. As per Googles specs it is now found in the rootfs as is the system partition.
[Android Software Development] alecxs:
You can't. because nobody have leaked the pixel oems private key required for zip signing
[Android Software Development] jcmm11:
Thanks. Roughly what I figured. Was hoping different.
[Android Software Development] pmatj:
Hi,

I'm currently using (well: tryiing to use) a P20 Lite and as I have no TWRP I'm a little bit lost.

I already got that this tool cannot be used to patch system.img, OK, but is it possible to use it to patch a recovery in that way, that it "runs" an update-zip from an SD-Card?

I would be perfectly OK with using MicroG (which could be installed systemless using Magisk), but as this does not really work with my banking app (although I good it running on a Pre-Treble phone and microG) I'm trying to somehow install Gapps into a specific GSI-Rom (Descendant)...

Is it somehow possible to patch the recovery_ramdisk, so that it acts as an installer for update.zip?

Peter
[Android Software Development] osm0sis:
You're way overthinking this. You can use [MENTION=5787964]SuperR.[/MENTION]'s Kitchen to patch a system.img.
[Android Software Development] Spaceminer:
Is there any way to prevent AIK-mobile from symlinking /system/bin to /bin inside the ramdisk? I have a few images that have their own /bin files in the ramdisk, and I need the originals. As it is now, /bin in the ramdisk only shows me the files in /system/bin of my phone, which I don't need and already have access to.
[Android Software Development] osm0sis:
It only unpacks whatever the ramdisk has inside, so if you see that then the ramdisk does not contain anything but that symlink for bin. Maybe you're thinking of sbin?
[Android Software Development] Spaceminer:
Nope, not sbin. It happens with /bin, /d, and /product too. I posted a screenshot that shows it symlinked. If I unpack it in AIK for Windows the symlinks don't happen, but the image size becomes too big to flash after repacking it.
[Android Software Development] osm0sis:
The symlinks don't get followed during repack, so that's got nothing to do with it.

Reread what I posted above. All those links are stored as actual symlinks in the ramdisk. AIK doesn't do anything like create symlinks at all, only unpacks whatever is in cpio to begin with and then repacks them the same.

So the files that you think are in bin in the ramdisk are not, if you see a bin symlink then the only thing in that ramdisk is a bin symlink.
[Android Software Development] mylove90:
I unpacked boot.img and repacked it but the size went from 64 mb to 14 mb

the boot.img won't boot on the device

Am i doing it wrong ??

Device is Xiaomi Redmi 7

boot.img : https://drive.google.com/open?id=1s5Od5akIYutvhFYJZ_z_0PcEHgmvASpF

Thanks in Advance

Best Regards
[Android Software Development] martyfender:
On my devices, when I unpack and repack an image, it always ends up smaller, so I believe that is normal. I think it has to do with the removal of extra padding. I have alway wondered why this is the case, why the extra padding was there in the first place, if it was not needed. I hope [MENTION=4544860]osm0sis[/MENTION] will clarify this. However, the fact that the device is not booting this repacked image, means that there is something else at play here.

[MENTION=4544860]osm0sis[/MENTION] An OT note:

I want to thank you for all of of your recent contributions to Magisk you have made recently, even if they don't affect my older Android 6 devices directly.
[Android Software Development] osm0sis:
64 mb is the size of the entire partition. The image for your device doesn't fill the partition, so by unpacking and repacking you get the size of the actual content.

As always, the first step to troubleshooting is to repackimg --original to find out if it's a ramdisk thing or a signature/verity enforcement thing.

And cheers! I'm happy to contribute some meaningful fixes to magiskboot for the community at large. :)
[Android Software Development] mylove90:
I did repackimg --original with stock kernel and i was surprised to see it booting !

Now i have to figure out why my compiled kernel is not booting :D :D

How about dtb.img ?...can i deal with it with AIK too ?

Thanks for all your support :)

Best Regards
[Android Software Development] osm0sis:
dtbo is its own partition, so that's separate, but dt and AOSP dtb are supported. -dtb could also be attached to the end of the Image.gz usually as a final build product of Image.gz-dtb. For those it just unpacks it as "-zImage" because it doesn't differentiate about what's in that boot.img section.
[Android Software Development] mylove90:
Sorry for all these questions but i am kind of a noob to kernel compiling and repacking

So the device has dtbo.img and i got image.gz-dtb

how to convert image.gz-dtb to dtbo.img ?? Is there any tutorial to do this already ???

Thanks so much for all your help :)
[Android Software Development] osm0sis:
No, just replace zImage with your Image.gz-dtb
[Android Software Development] shoey63:
[MENTION=3728440]mylove90[/MENTION]

If you have compiled a new kernel, you may have to compile a new dtbo.img as well. If they don't match, it could cause a bootloop/corrupt device message. This is the case with Sony slot A/B devices.
[Android Software Development] mylove90:
Sorry if it seem like a dump question...but how to do so ?!

The compiled kernel is just stuck in the boot logo and i guess this is because i didn't flash my own dtbo.img

stock dtbo.img file is about 8 mb while compiled image.gz-dtb is about 24 mb....so i don't think dtbo.img == image.gz-dtb

maybe i am too dump to understand how this work :silly: :cyclops:
[Android Software Development] shoey63:
Read your kernel documentation. Also don't forget to disable verity.

But these things are beyond the scope of this thread.
[Android Software Development] sga999:
I'm having a problem with the AIK mobile version. After unpacking a boot image, I am unable to copy a file into the ramdisk folder. The file is about 77MB in size. It copies part of it, keeps trying, fails. I've tried this copy in several ways, e.g. FX File explorer and other file managers, cp command in terminal emulator, and none of them work. However, I am able to copy a smaller file successfully (maybe up to 64MB).

I also tried this with the Windows version of AIK. After unpacking, I am able to copy the 77MB file into the ramdisk folder and then do the repack. I haven't tested to see if the result actually works, but ramdisk-new.cpio is now 109MB, so it seems like it was successful.

Has someone experienced this "size problem" with the mobile version?
[Android Software Development] osm0sis:
You will likely hit the max boot partition size adding something like that. Because that's not super sensible, the latest AIK-mobile supports up to 64mb (unpacked) ramdisks. I have updated that to 96mb for the next release, since I've seen one ramdisk that big a short time ago.
[Android Software Development] sga999:
FYI, this is for the essential PH-1. It has A/B slots and a special TWRP installer that contains ramdisk-twrp.cpio. Unfortunately, I don't know if 96mb is enough since I thought it added 77 to about 30 that was already there. If changing to 128mb seems unreasonable, I can just use the windows version. Let me know what you think. Thanks for your help. These are wonderful tools!
[Android Software Development] osm0sis:
It's about the size of your device's partition minus the size of the other boot.img contents (like kernel and dtb). What's the size of the the dump when you `dd if=/dev/block/bootdevice/by-name/boot_a of=/sdcard/boot_a.img` ?

The TWRP installer contains uncompressed ramdisk.cpio, so its size is not how much it actually increases. It also doesn't add-to, it replaces the existing ramdisk.
[Android Software Development] sga999:
The dump file is 64MB. So you're saying that when I was seeing 100MB+ for ramdisk-new.cpio, that was uncompressed. So your 96MB change will work fine. Great!
[Android Software Development] osm0sis:
Yep, and 64mb for a full packed boot.img is your device's maximum, so just be aware you can't go over that when repacking one.
[Android Software Development] sga999:
I'll explain a little more. I have installed the existing TWRP installer zip successfully. So I know the 77MB ramdisk-twrp.cpio file normally has no problem. But I wanted to learn more about slots, partitions, etc. So I was looking into how to make that installer only write to a single slot (currently, it writes to both). When I saw your mobile tool, I thought it would be a fun way for me to learn.

Now I wonder if I'm doing something wrong. After unpacking, I'm trying to copy that 77MB file into the ramdisk folder. That fails, usually only copying about 27MB, retrying lots of times.. So am I correct in just copying the file there, not doing any compression first?

The kernel and dtb add up to about 30MB. So I'm not seeing how the numbers will allow me to copy all 77MB. No need to explain if it's too complicated. But I just wanted to be sure that you understood that this works under "normal circumstances", i.e. flashing the TWRP installer. So it can't be a problem with the device's maximum.
[Android Software Development] osm0sis:
So if you flash the TWRP installer and dump the resulting boot image, then attempt to unpack it will it fail in AIK-mobile?

So my best guess is one (or all) of the icacls commands is behaving differently on your device. On my Windows 10 PC those actually fixed inherited bad folder permissions on my non-boot drives and let AIK run from anywhere and be able to cleanup 000 permissioned (e.g. Magisk's /.backup) folders, but it sounds like the opposite case for you.

Try commenting them out and see what happens.

I'm not sure how to best proceed to cover both my and your cases with these folder permissions. :confused:
[Android Software Development] anagramgenius:
By removing either inheritance command or all 3 icacls commands, there's no error while unpacking ramdisk and it works same as v3.4.
[Android Software Development] sga999:
No, this problem isn't tied to a device with TWRP installer. I have another device (Leeco) that has no slots or TWRP installer. I tried AIK mobile there also, and after unpacking a boot image, I could not copy a large file into the ramdisk folder. I've probably made this more confusing by giving so much detail in my prior post. I'm guessing that your change to 96MB will fix the problem. Butt I thought those details might help you be sure before you made any changes.

The unpack never fails. It's just the copy into ramdisk that keeps trying and fails.
[Android Software Development] osm0sis:
Which would break the case that I found on my PC, so again not sure how to handle both yours and mine. Maybe I'll add a switch to skip those or something? Not sure how to detect the issue on the fly.

Well yeah, I told you, a) there shouldn't be a ramdisk that big and b) there physically can't be, to a point, because compression goes only so far and the partition size is the limit.
[Android Software Development] sga999:
I am using your tool only because I was investigating how the slots and partitions work. So I thought I would try to duplicate the same thing that the TWRP installer zip does. There were plenty of ways to do that, and I have tried some (e.g. modifying the zip file, entering similar commands while in TWRP, etc.). But I really wanted to use your mobile AIK, just to learn and possibly use it in the future.

So I'm just trying to do the same thing with your AIK that the TWRP installer does. And the TWRP installer has no problem doing it, so that's why I wondered if I'm doing something wrong by just copying the 77MB file into ramdisk. Here is part of the update-binary in the TWRP installer zip. The tool being referenced is magiskboot.

"$tool" --unpack boot.img

cp -f ramdisk-twrp.cpio ramdisk.cpio

"$tool" --repack boot.img

dd if=new-boot.img of=/dev/block/bootdevice/by-name/boot_a

I realize that your AIK mobile unpack/repack may not be doing identical things as magiskboot. But I figured that after unpack, the equivalent of the 'cp' step would be to just copy the ramdisk-twrp.cpio into folder ramdisk. Maybe I have to delete something from folder ramdisk, like ramdisk.cpio, before doing this copy. I didn't see it there. Instead I just attempted to copy ramdisk-twrp.cpio into the ramdisk folder. So maybe you can tell me the way to accomplish what that 'cp' command did in the script. Once that's done, I would follow that with your repack.

This also seemed to work fine with your windows version. When I say it worked, I didn't actually try to write the resulting boot image. I'm just saying that there were no errors with unpacking, copying the file to ramdisk, repacking.
[Android Software Development] anagramgenius:
Is there a way to fix the permissions of the files created inside "split_img" folder? Seems the permission inherited by "ramdisk" folder corresponds to that. Only few files inside "split_img" folder have correct permissions. Other files show this "The permissions on <filename> are incorrectly ordered, which may cause some entries to be ineffective." error when I click on "Security" tab to check the permissions. This is a problem caused by cygwin in Windows 10. Isn't it? The "split_img" folder itself has correct permissions. But most of the files inside that folder show that warning, one of which is ramdisk.cpio.gz. Is there a way to set correct permissions to all files when unpacking to "split_image" folder?
[Android Software Development] osm0sis:
You wouldn't copy anything into the ramdisk. To do what TWRP's installer does you would unpack, delete split_img/*-ramdisk.cpio.* and put ramdisk-twrp.cpio there, BUT it's still uncompressed, so to do it like the TWRP installer you would also need to manually compress ramdisk-twrp.cpio with whatever format compression split_img/*-ramdisk.cpio.* was, then name the resulting new compressed ramdisk along those lines as e.g. split_img/twrp-ramdisk.cpio.* and then repackimg --original to make it use that TWRP ramdisk in the repack.

Those "incorrectly ordered" permissions are the Linux file permissions we need to keep. Unfortunately what you're describing doesn't make sense because the ramdisk being unpacked is the only important part. If I had your system I could try and figure out why our non-boot drives behave differently and maybe detect things more elegantly, but as it is the only thing I can think to do is make a toggle to opt out of the Windows folder inheritance fix.
[Android Software Development] sga999:
I was able to delete the .gz file from split_img. And I compressed ramdisk-twrp.cpio using gzip format. I renamed that resulting .gz file, did unpack, copied .gz file to split-img, and did the repack, which appeared to be successful. But the image-new.img actually becomes smaller than the original, so I know my rename was not correct. I tried several other renames to no avail. I'll keep trying.

Thanks for your help. Even if I don't get this working, I've still learned lots by using your tools.
[Android Software Development] osm0sis:
When you do --original it'll tell you what ramdisk filename it's using. Follow my instructions above closely and the rename will be correct. Smaller than the original dump is normal, I answered this a couple pages ago.
[Android Software Development] sga999:
Apologies, I misunderstood the --original parameter, assuming you meant to put the original filename used in unpackimg. The magiskboot method I mentioned earlier caused the boot image size to increase from 27MB to 44MB. I'm sure there are cases where the image gets smaller. I just tried your method, and wiith a very quick test with --original, it is now 45MB. Good!
[Android Software Development] osm0sis:
Yep, just depends on whether the original image was trimmed or not, or AVBv2 signed, since nobody bothers to re-sign for it.
[Android Software Development] sga999:
Out of curiosity, I decided to try to unpack the resulting image that was created with the twrp-ramdisk.cpio.gz copied to split-img.

For either the mobile version or the windows version, I have to rename image-new.img to something else. Otherwise, it says it's an unrecognized format.

If I rename it, the windows version can unpack it with no problem. But the mobile version cannot. Here is the end of the output:

Unpacking ramdisk to "ramdisk/"...

Compression used: gzip

cpio: write error: No space left on device

I wanted to attach the renamed boot image file here, but it is 45 MB. Not sure how to get that to you. As I said, I was just curious about this, so I have no real need for it to work. But I still thought I would let you know.
[Android Software Development] osm0sis:
Yeah image-new.img is created by AIK so it won't accept it as an input image name (it would get overwritten), so rename it first.

Sounds like it's a big ramdisk. 96mb in the next release should fix it for AIK-mobile. :good: