yashsingh1/xdaforums huggingface dataset:
[Android Software Development] osm0sis:
I've been thinking about this for awhile, and I would like to support Darwin, so I'll be trying to create some crosstool-ng cross compilers for it (which should also allow me to build the U-Boot tools). What would be needed? Would Darwin x64 be enough, or is i686 also a necessity?
[Android Software Development] sandpox:
Hello [MENTION=4544860]osm0sis[/MENTION], I haven't been able to extract ramdisk with your tool, somehow it doesn't extract the ramdisk.cpio

here is the boot.img: https://drive.google.com/open?id=0B0MI5d7Kg-kyQXh2NzNMOHdGS2s

No, that image is not corrupted and it's working fine, that image is from CM for Nook HD+ (ovation), you can find another boot.img here http://crimea.edu/~green/nook/hd/
[Android Software Development] osm0sis:
It might work on your device, but it's certainly not a normal image. Look at the output from bootimg-info:

Android Boot Image Info Utility

Printing information for "nookhd-ovation-boot.img"

Header:
magic : ANDROID!
kernel_size : 786576 (000c0090)
kernel_addr : 0x80d80000

ramdisk_size : 0 (00000000)
ramdisk_addr : 0x81d78000
second_size : 0 (00000000)
second_addr : 0x81c78000

tags_addr : 0x80d78100
page_size : 4096 (00001000)
dt_size : 0 (00000000)
unused : 0 (00000000)

name :
cmdline : Green Loader

id : bb2e63bd1a2251a6a61307baa4ca5145d9342b65

extra_cmdline :

Other:
magic offset : 0x00000000
base address : 0x80d78000

kernel offset : 0x00008000
ramdisk offset : 0x01000000
second offset : 0x00f00000
tags offset : 0x00000100

Ramdisk size in the header is zero, are you sure there is one? :eek:

Edit: Looks like there is, and there are little section headers ahead of the kernel and/or ramdisk, making it kinda like MTK.

Edit 2: There is actually a second ANDROID! header 1mb in, and this one unpacks correctly. Basically the "Green Loader" is a signature used to make the bootloader accept it.
[Android Software Development] sandpox:
Well... the boot.img is 5MB but after extracted I only get ~800kb total output so I think I've missed something
[Android Software Development] osm0sis:
I think there is a ramdisk but it's definitely yet another deviation from the AOSP standard. The upside being if CM was building for it, then it must be documented somewhere, hopefully with source for the necessary binaries. Detection might be tricky but I'll look into handling it in a future release. :good:
[Android Software Development] sandpox:
Yes, this is an official supported cm device and this is its custom boot.mk: https://github.com/CyanogenMod/android_device_bn_ovation/blob/cm-12.1/boot.mk
[Android Software Development] shoey63:
Just a heads up from a Sony user.

Tried AIK mobile on my Z5. Unpack of kernel.sin hangs, but unpack/repack of kernel.elf works fine after removing dm-verity.

Fantastic work!
[Android Software Development] osm0sis:
This a new .sin? The example SINv3 I had was from a Z5, but maybe you've got a newer one. Naturally this is more of a [MENTION=4120742]munjeni[/MENTION] thing to fix since kernel_dump is closed source, but can you upload it for me so I can take a look?
[Android Software Development] shoey63:
munjeni is taking an enforced "break", but here you go

https://drive.google.com/file/d/0B4NxGf27orCnTXg2dmxKemlyVFU/view?usp=drivesdk
[Android Software Development] osm0sis:
That's a .sin.tar.bz2, so just untar+unbzip2 it first to get to the actual .sin file and it should work. It was detected as SINv3 and worked great on AIK-mobile on my side here.

No idea why it would hang, it should just detect an unsupported format for the .tar.bz2 so I'll look into that.

Edit: Just occurred to me that even untar+unbzip2'd it would be around a 30mb file which could be the problem you're seeing. It's a hang but should only last about a minute as cat | tail processes and reads the file for any trailing magic, and is only noticeable on huge files >25mb. It's due to a limitation of busybox tail and I've already figured out a better solution for AIK v2.9. :good::cowboy:

I've got some binary updates then a few new formats to investigate further and possibly write binaries for from scratch first, so I'm in no hurry for a release; it's not broken, it's just slow (for huge files). :p

More general thoughts, directed at everyone: Hmm I notice downloads are about half what they used to be now that I've switched to the DevDB Download page.. anyone have any ideas why? Are DevDB files only accessible to registered users or something? Should I switch to my own hosting?
[Android Software Development] rignfool:
DevDB does not show on Tapatalk or XDA Labs...

And requires a web browser... And the damn links are hidden as well...

Just my 2¢
[Android Software Development] osm0sis:
I'm definitely leaning toward hosting things myself down the road here, but for now, [MENTION=3290808]rignfool[/MENTION] does it work on Tapatalk/xda Labs if I expose the direct DevDB link within a regular post?

Like this for AIK-mobile v2.8:

https://xdaforums.com/devdb/project/dl/?id=25023&task=get

P.S. weird that xda Labs wouldn't properly allow access to xda's DevDB. :rolleyes:;)
[Android Software Development] Vagelis1608:
Just not implemented (yet?), I guess.

Clicking the link shows a message about failing to parse the link, whatever that means, and opens the link in a browser, in XDA Labs.
[Android Software Development] osm0sis:
Hmm but the download then proceeds, right? So it works overall in xda Labs? Cool. OP updated with the direct links. Tapatalk can likely handle them as well.
[Android Software Development] shoey63:
Ok no worries.

No need to look at tar.bz2. I just compressed the kernel sin with FX file explorer so I could send it to you on XDA app, but it didn't work, so I used drive instead:o
[Android Software Development] osm0sis:
It was definitely just the long hang from the tail magic detection, not actually frozen. As I said, it'll be fixed in the next version. :good:
[Android Software Development] rignfool:
No... Tapatalk can't...

It reverts to XDA's home...

Hence why it's referred to as Crapatalk
[Android Software Development] osm0sis:
**** sakes.. okay, and if they are redirected?

https://goo.gl/R1ZD9v
[Android Software Development] rignfool:
Ok... Redirected works... It the loads the browser in my case and starts the download... But I'm using "App Redirect" from the playstore since Tapatalk has decided to hijack every click for ad counting purposes
[Android Software Development] osm0sis:
That's what I'll switch to in the OP then. :good:

Edit: Done!
[Android Software Development] martyfender:
I started a thread a few months ago on how to root a Nextbook ares 8a intel x86 tablet.

https://xdaforums.com/android/development/nextbook-ares-8a-android-6-0-1-root-t3612397

A few weeks ago I released a twrp for it and modified boot.imgs for both version 1.1.1 and 1.2.0 of the tablet. I used image kitchen in linux to remove encryption, dm_verity and make selinux permissive. Everything worked great.

I received a post from a user with a new 2.1.5 version of the tablet saying he had lost sound with my boot.img so I asked him to upload his original boot.img and I would modify it in image kitchen.

I unpacked it, did the edits and when I repacked it it created two, smaller images one signed and one unsigned and in the terminal when I retried it on windows I saw an error:

Android Image Kitchen - RepackImg Script
by osm0sis @ xda-developers

Packing ramdisk . . .

Using compression: gzip

Getting build information . . .

kernel = boot.img-zImage
second = boot.img-second
cmdline = loglevel=2 androidboot.hardware=NXM882CAP_ES firmware_class.path=/system/etc/fir
mware bootboost=1 pm_suspend_debug=1 intel_pstate=disable vga=current i915.modeset=1 drm.v
blankoffdelay=1 i915.fastboot=1 thermal.off=1 console=ttyS0,115200n8 pstore.backend=ramoop
s intel_pstore_pram.record_size=0x8000
board =
base = 10000000
pagesize = 2048
kernel_offset = 00008000
ramdisk_offset = 01000000
second_offset = 00f00000
tags_offset = 00000100
hash = sha1

Building image . . .

Using format: AOSP

Signing new image . . .

Using signature: AVB boot

Error!

Press any key to continue . . .

When I try to fastboot boot boot.img on my older tablet I get a boot animation bootloop on either boot.img it created, both of which are smaller that the original by a significant amount. Does anybody know why it won't repack properly? The file naming in the ramdisk is somewhat different but the files are essentially the same, fstab, fstab device, init.rc default properties etc.

Here is a link to the original boot.img (originally boot.emmc.win twrp backup renamed) and the 2 images image kitchen created. Could someone look at them and give any suggestions ?

https://drive.google.com/open?id=0By0mLSbF9jhcLWZ4TlBWSW9KZkk

Thanks so much
[Android Software Development] osm0sis:
Is this on your desktop? Do you have Java 8 installed? It's required for AVB signing, per the OP.

The filesize is only different because the dump has a bunch of nul 00 padding on the end.
[Android Software Development] martyfender:
I just redid this on linux after installing java jdk:

OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11)

OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

Is it the norm for two boot.img to be created, one signed and one unsigned.

I don't have the newer version of the tablet to test it on. On my older version of the tablet when I sudo fastboot boot image-new.img I get a boot animation bootloop. When I try to unpack the newly created images with image kitchen they will not unpack:

mint@mint ~/AIK-Linux $ '/home/mint/AIK-Linux/unpackimg.sh'
No image file supplied.
Error!
mint@mint ~/AIK-Linux $

Do I need jre instead of jdk? Or the Oracle version?

I thought jre was included in the jdk. I am new to linux and linux mint so I just want to make sure I am setup properly for the future.

On Windows I can drag and drop file to pack and unpack, but on Linux Mint I can't I have to double click the repackimg.sh and unpackimg.sh to get them to work. It works if I drag the script to a terminal window, though

Thanks for being patient with a newcomer to Linux and AK.

Thanks
[Android Software Development] osm0sis:
Why aren't you using Windows if you have Windows? Just install Java 8 on Windows and drag drop if you're finding the Linux command line confusing.

Of course it's normal for signed images to be signed at repack. An AVB signed image should generally still boot on a device that isn't enforcing it, but I can't make any promises - there are definitely devices that enforce their own OEM keys so we can't re-sign them correctly, and every bootloader is different.
[Android Software Development] martyfender:
Why are the newly repacked images not able to be unpacked again. Seem as if they were not created properly

Signature with "AVB" type detected.

Here is the original Linux terminal output, both unpacking and repacking

Splitting image to "split_img/"...
BOARD_KERNEL_CMDLINE loglevel=2 androidboot.hardware=NXM882CAP_ES firmware_class.path=/system/etc/firmware bootboost=1 pm_suspend_debug=1 intel_pstate=disable vga=current i915.modeset=1 drm.vblankoffdelay=1 i915.fastboot=1 thermal.off=1 console=ttyS0,115200n8 pstore.backend=ramoops intel_pstore_pram.record_size=0x8000
BOARD_KERNEL_BASE 10000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_HASH_TYPE sha1
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_SECOND_OFFSET 00f00000
BOARD_TAGS_OFFSET 00000100

Unpacking ramdisk to "ramdisk/"...

Compression used: gzip
7835 blocks

Done!
mint@mint ~/AIK-Linux $ '/home/mint/AIK-Linux/repackimg.sh'

Android Image Kitchen - RepackImg Script
by osm0sis @ xda-developers

Warning: Overwriting existing files!

Packing ramdisk...

Using compression: gzip

Getting build information...
kernel = boot.img-zImage
second = boot.img-second
cmdline = loglevel=2 androidboot.hardware=NXM882CAP_ES firmware_class.path=/system/etc/firmware bootboost=1 pm_suspend_debug=1 intel_pstate=disable vga=current i915.modeset=1 drm.vblankoffdelay=1 i915.fastboot=1 thermal.off=1 console=ttyS0,115200n8 pstore.backend=ramoops intel_pstore_pram.record_size=0x8000
board =
base = 10000000
pagesize = 2048
kernel_offset = 00008000
ramdisk_offset = 01000000
second_offset = 00f00000
tags_offset = 00000100
hash = sha1

Building image...

Using format: AOSP

Signing new image...

Using signature: AVB boot

Done!
mint@mint ~/AIK-Linux $

Terminal output when trying to unpack newly created images:

mint@mint ~/AIK-Linux $ '/home/mint/AIK-Linux/unpackimg.sh'
No image file supplied.
Error!
mint@mint ~/AIK-Linux $

UPDATE: I got a report from the user of the newer version of the tablet that it booted ok and sound, wifi bluetooth all worked. he just fastbooted it and hasn't flashed it yet.

Thanks again
[Android Software Development] osm0sis:
They are. You're executing it wrong somehow.

You need to rename the image-new.img to something else for it to be accepted, because otherwise it's going to get removed as part of the cleanup before unpack.

Glad it works for the newer tablet; as I said, every bootloader is different. :good::)
[Android Software Development] martyfender:
I had a suspicion that I needed to rename it. However, I think I tried that last night, but that was before I had java installed.

I'm at work now, but will check after I get home after 11:30pm EDT.

Thanks again for your great support and even greater range of useful android apps and utilities.
[Android Software Development] martyfender:
The user of the newer tablet reported that both images flashed and worked fine until he flashed SR1-SuperSU-v2.82-SYSTEMMODE.zip, then it bootlooped

https://xdaforums.com/showpost.php?p=73121678&postcount=159

Do you have any thoughts or suggestions on this?

Thanks
[Android Software Development] rootlinux:
Thank you for this.
[Android Software Development] osm0sis:
My only thought is why use system mode? It's an unofficial hack zip, and Chainfire's official one does systemless by default Marshmallow and above for a reason.. you're asking for issues.
[Android Software Development] martyfender:
I have owned the original Nextbook Ares 8 with 5.1.1 and two of the new Ares 8A and have flashed countless versions, both stable and SR releases of supersu in system mode without one issue. And the original author of the twrps that I use for both, [MENTION=2472806]vampirefo[/MENTION] recommends it. I alway see countless people on the supersu forum using systemless mode having issues. I have, however been curious if systemless will work well on this device. Considering that I have many twrp backups I may test it though. I just don't have the newer v2.1.5 to try it out directly, but through this same user on my thread. I recommended that he start fresh by booting into fastboot and formating userdata and cache, then flashing the supersu.zip

Something appears to be different with this tablet, namely a signed boot.img

The older two versions of the tablet, 1.1.1 and 1.2.0 didn't need java for me to sucessfully modify the boot images on them.

Also the version 1.2.0 and 2.1.5 both have DISA activation point of sale where you have to enter a one time activation code from your receipt on first boot. I flashed the 1.2.0 rom on my 1.1.1 device and I see no signs of it, as in settings to reset disa activation that is seen with the same rom on the newer device. This makes me suspect it may be firmware or hardware based activation. Also on a factory reset you don't have to re-enter the code.

http://www.digital-safety.sg/

Have you ever heard of this? Several other manfacturers such as RCA are using this In Walmarts, Targets, Bestbuy, etc. It could be in the stock recovery though. When I reflashed the stock recovery temporarily, in a 1.2.0 version of the tablet, I saw the activation message again.

With much respect, thanks for your comments and help.
[Android Software Development] sscsps:
How was this fixed?

I have this issue on my kernel and I'm unable to find the solution :(
[Android Software Development] USBhost:
Not really.

Unpack as root for the workaround
[Android Software Development] sscsps:
Actually the thing is I am not unpacking/packing it. I am working on my kernel to make it bootable with Android Nougat and so far, i'm here :\

I am facing this issue and have been searching for how I can fix it and get it to boot with my ROM :\
[Android Software Development] USBhost:
https://github.com/USBhost/FIRE-ICE/commit/5f06fe67306781387ebe8b508a1448aded085c0f That should allow it to continue.

Or just patch init by removing that line
[Android Software Development] martyfender:
I successfully used unSU to remove supersu in system mode and have flashed:

SR1-SuperSU-v2.82-SR1-20170608224931.zip to my older version of the device and so far I am not having any issues.

If my suggestions for the user of the newer version of the device don't work I have recommended that he use unSU, delete the dalvik cache and cache, then flash the SR1-SuperSU-v2.82-SR1-20170608224931.zip in systemless mode to see if that works

Thanks, [MENTION=1143630]osmosis[/MENTION] I just received a report that the user of the newer tablet successfully flashed the supersu in systemless mode and reported that it didn't bootloop and everything is working.

He also stated that he had flashed the unsigned boot.img, of the 2 that I provided him.

So, thanks again, you are great.

UPDATE: [MENTION=4544860]osm0sis[/MENTION] The original porter of the twrp I use and who modified the boot images for me for v1.1.1 and 1.2.0, vampirefo, told me for the new tablet the reason it bootlooped until systemless supersu was flashed, was that I had not modified that to make it permissive and he was correct. He modified the sepolicy file in the boot image.

He said that the reason the bootloop was gone was that systemless supersu had patched the boot image to make the kernel permissive.

"Modify them takes work, that's why I suggest you just use the one that is already made via systemless root.

I use device tree and rebuild sepolicy, based off of TWRP source code.

Chainfire patches them supolicy, his method and my method both require work.

Chainfire method has already patched the sepolicy for you, just use it."

He suggested that I get that patched image from the v2.1.5 tablet owner to solve the problem. As of yet the user has not been able to send me the file as he apparently is out of data this month to upload it. Is there any other means to modify the sepolicy file or make the boot image permissive that you are aware of? I have been using linux Mint Mate for the last month but I have not been able to gain the knowledge to build a device tree and compile as it is a steep learning curve. In my search about a month ago, I had found a link where they added it in /split_img/ boot.img cmdline but I can't find that link anymore. If you have any Ideas I would appreciate your feedback, as I am getting reports that there are five versions of the tablet I will need to get boot images for and modify them. I am am assuming the sepolicy file will be device or rom specific and can't be universally be used for each device's boot image.

Thanks again
[Android Software Development] sscsps:
Thank you

But i actually fixed it, atleast that part, by the help of this conversation here: http://seandroid-list.tycho.nsa.narkive.com/D3qnO4XY/restorecon-init-fail-in-the-init-cpp-file

The commit i made is present here: https://github.com/SamsungGalaxyTab...mmit/d1180b4eeac339367af3000dec110f4b85fdbba1

I might use your commit as well, as I have more issues with sepolicy, but let's see if I can fix them or not first.

Thanks :)
[Android Software Development] osm0sis:
To fix it properly without the patched policy from that user you'd want to look into sepolicy-inject probably, but beyond that I can't really tell you how to proceed.. you'd need to know the specific denials to patch, so you'd need a kmsg/dmesg log while it's failing to boot.

As for making it permissive, that's getting harder and harder to do on Android without recompiling the kernel. Adding androidboot.selinux=permissive to the boot.img cmdline is worth a try, but might not cut it. Again, unfortunately, after that I've got no further ideas for you.
[Android Software Development] cascabel:
Minor bug (?) on LG f460k running RR (android 7.1.1). Typing "aik" (no "") does not bring me to the install directory. I have to manually go there. Eveything works once i do, though. Just a heads up (or if it's already reported, maybe there's an easier way to get to /data/local/AIK-mobile? :laugh: )
[Android Software Development] osm0sis:
Does aik do anything? Try aik --restore

I personally prefer doing it all in FX File Explorer and just have AIK-mobile as a bookmark. :good:
[Android Software Development] cascabel:
aik --restore tells me shortcut restored but typing aik again does nothing. It's a very minor bug (probably has to do more with my system), so no worries. Just wanted to let you know. Everything works so I'm good. Yeah, I'm thinking of using a file explorer instead to make things easier. Cheers. :)
[Android Software Development] osm0sis:
Yeah that's weird. Does it trigger a root prompt at least? If you look at the script all it does with no argument is change directory then call su.
[Android Software Development] cascabel:
Yes it does call su. I'll check it later since I'm at work right now and let you know.
[Android Software Development] osm0sis:
Normal scripted way to get to a directory as root is be in it first before doing su (since you can't pass that to the su command and still open it as an interactive sub-shell), but it's possible your shell/sepolicy refused access to the directory without root. Normally it lets you be in the directory, just not view its contents.

I'll try to reproduce it on one of my devices and see if I can come up with a better solution.
[Android Software Development] cascabel:
I just noticed this when i tried aik --restore. I just did a reboot prior to this.
[Android Software Development] osm0sis:
That suggests you've got system root but it couldn't remount /system rw to make changes.

What's the output of just aik look like?
[Android Software Development] Wuby986:
on 7.0 it's a common issue over sammy s7 f.e. only way i can mount system rw is via busybox mount and not just mount
[Android Software Development] cascabel:
Oh ok. So I'll just have to edit the script to busybox mount to get it to work? I can try that tonight.
[Android Software Development] osm0sis:
Shouldn't be necessary in your case, since the script clearly is installed correctly. I'll add a if $(which busybox) to prefer that, or try to use my included AIK busybox, but that's another issue.

From a non-root ($) prompt can you just manually type in cd /data/local/AIK-mobile and then pwd and show me the output please.
[Android Software Development] cascabel:
Like this?
[Android Software Development] osm0sis:
Yes. And that looks completely as expected, so no idea why on your device it doesn't do it all together like it's supposed to:

https://github.com/osm0sis/Android-...-mobile/data/local/AIK-mobile/bin/aik#L40-L42
[Android Software Development] cascabel:
That's weird. Anyway, it's easy enough to navigate to the install directory, and it wouldn't matter if i do start using a file manager to execute the scripts. Unpack, repack works, and that's what I'm really after. Lol.

Thanks! :laugh:
[Android Software Development] osm0sis:
One last test, in a file manager mount /system rw then go to /system/xbin/aik and edit it, changing cd $aik to cd /data/local/AIK-mobile then save and try it again from the command prompt.
[Android Software Development] cascabel:
Apologies. I fell asleep last night (too tired). Tried that but it doesn't do anything. I notice --uninstall also remounts system and it works. I'm using Privacy Guard, not superSU (goves me bootloops). Could that be it? Tried replacing $aik with the set path (/data/local/AIK-mobile) and it gives permission error.
[Android Software Development] osm0sis:
Perhaps. It's all acting fine on the command line but weird via script with your setup. If you're open to it, try SuperSU.