Related
have anyone seen 7zip for Android?
AndroZip handels 7zip
Sent from my GT-I9000 using XDA App
MiMikri said:
AndroZip handels 7zip
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Unless it is pw-protected.
AllGamer said:
have anyone seen 7zip for Android?
Click to expand...
Click to collapse
I've just compiled p7zip-9.20.1, it's the command line version of 7zip, if you still want it, you can download it from here:
http://dl.dbank.com/c0mtm6i3wa
(sorry, it's a file share site provided by Huawei company in Chinese language, outseas file share sites are blocked by "opening" China government)
Code:
$ uname -a
uname -a
Linux localhost 2.6.35.7-perf #1 PREEMPT Sat Dec 3 17:57:38 CST 2011 armv7l GNU/Linux
$ ls -l /system/bin/7z /data/local/bin/7za-9.20
ls -l /system/bin/7z /data/local/bin/7za-9.20
-rwxr-xr-x 1 2000 2000 1702540 Dec 26 03:37 /data/local/bin/7za-9.20
lrwxrwxrwx 1 0 0 24 Dec 26 03:03 /system/bin/7z -> /data/local/bin/7za-9.20
$ 7z
7z
7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,1 CPU)
Usage: 7za <command> [<switches>...] <archive_name> [<file_names>...]
[<@listfiles...>]
<Commands>
a: Add files to archive
b: Benchmark
d: Delete files from archive
e: Extract files from archive (without using directory names)
l: List contents of archive
t: Test integrity of archive
u: Update files to archive
x: eXtract files with full paths
<Switches>
-ai[r[-|0]]{@listfile|!wildcard}: Include archives
-ax[r[-|0]]{@listfile|!wildcard}: eXclude archives
-bd: Disable percentage indicator
-i[r[-|0]]{@listfile|!wildcard}: Include filenames
-m{Parameters}: set compression Method
-o{Directory}: set Output directory
-p{Password}: set Password
-r[-|0]: Recurse subdirectories
-scs{UTF-8 | WIN | DOS}: set charset for list files
-sfx[{name}]: Create SFX archive
-si[{name}]: read data from stdin
-slt: show technical information for l (List) command
-so: write data to stdout
-ssc[-]: set sensitive case mode
-t{Type}: Set type of archive
-u[-][p#][q#][r#][x#][y#][z#][!newArchiveName]: Update options
-v{Size}[b|k|m|g]: Create volumes
-w[{path}]: assign Work directory. Empty path means a temporary directory
-x[r[-|0]]]{@listfile|!wildcard}: eXclude filenames
-y: assume Yes on all queries
Hi lovetide. What kind of compression did you use?
I can't find a way to open it :/
Guys I found another working port of p7zip for android.
I Tried to post a link but becouse i'm a 'noob' here i'm not allowed to.
So you can search for "port2android" at google and you will find it
ilbolza said:
Hi lovetide. What kind of compression did you use?
I can't find a way to open it :/
Click to expand...
Click to collapse
It's not an archive file, it's an executable file, you can execute it directly. It's static linked, so it should work on most Android phones.
lovetide said:
I've just compiled p7zip-9.20.1, it's the command line version of 7zip, if you still want it, you can download it from here:
http://dl.dbank.com/c0mtm6i3wa
(sorry, it's a file share site provided by Huawei company in Chinese language, outseas file share sites are blocked by "opening" China government)
Click to expand...
Click to collapse
Link does demand to pay for it. Can you upload attachment on the forum?
You have to click the link several times. It will work after some time.
But scroll down... Mirror is attached.
Here version 9.38.1 for arm-v7a, 7za is standalone, 7z needs 7z.so in /system/lib, 7zr a reduced version of 7za, Codecs must be in current dir for rar support (optional)
in the archive I've also added makefile.machine if you want to compile from source (you need to replace the one in the source directory, it needs to be edited for paths)
sherpya said:
Here version 9.38.1 for arm-v7a, 7za is standalone, 7z needs 7z.so in /system/lib, 7zr a reduced version of 7za, Codecs must be in current dir for rar support (optional)
in the archive I've also added makefile.machine if you want to compile from source (you need to replace the one in the source directory, it needs to be edited for paths)
Click to expand...
Click to collapse
Thank you very much for this indeed. XDA won't let it download no matter how many times I try, would it be possible for you to post it in a mirror somewhere ?
Edit : Never mind, finally got it. XDA glitch.
Edit 2 : Shoot, this will not run in Android 5 and newer systems... ( Error: only position independent executables (PIE) are supported. )
sorry but I didn't have an arm android 5.x to test it, I'm attaching pie build, I think it should work also on android < 5, but anyway there is still the old attachment in previous post
Hey...
I think the Zarchiver app from the play store would just work.
Hit thanks if I helped you!
ClawSpark said:
Hey...
I think the Zarchiver app from the play store would just work.
Click to expand...
Click to collapse
Does it support being called via command line, from eg a bash script?
To the rest: did the PIE build work fine?
p7zip 16.02 stand-alone attached.
help needed. anybody know how to set HugeFiles=on? compiling with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE does not give expected result
- - -
edit: many thanks to superbeef150 @ XDA for solution!
aIecxs said:
p7zip 16.02 stand-alone attached.
help needed. anybody know how to set HugeFiles=on? compiling with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE does not give expected result
Click to expand...
Click to collapse
Does this work on Android 6.0?
aIecxs said:
p7zip 16.02 stand-alone attached.
Click to expand...
Click to collapse
Thanks for sharing! I'm able to get this to run on several devices, but for some reason it errors out when running it in TWRP (which is coincidentally where I hope to run it):
Code:
~ # chmod 777 /data/local/tmp/p7zip
~ # /data/local/tmp/p7zip
/sbin/sh: /data/local/tmp/p7zip: not found
~ # sh /data/local/tmp/p7zip
/data/local/tmp/p7zip: line 1: syntax error: unexpected word (expecting ")")
Has anyone observed this different behavior between TWRP and the normal OS occur with 7zip or any other terminal/shell/CLI apps?
superbeef150 said:
Has anyone observed this different behavior between TWRP and the normal OS occur with 7zip or any other terminal/shell/CLI apps?
Click to expand...
Click to collapse
I got this figured out in case anyone stumbles across this in the future.
The default shell in TWRP (in my case) is at /sbin/sh . From what I've read, it sounds like this is the one that is supplied with BusyBox rather than the normal one. When I ran 7z using /system/bin/sh I had a lot better luck.
I'm now running into issues with larger ISO files. It seems like ones over 2GB are the problematic ones, I can't extract, test, or list contents on them, instead I always get an "E_FAIL" error message.
Googling that in the context of 7z seems to indicate a space issue, but testing and listing contents should make that irrelevant. For the sake of trying I attempted this with the ISOs on an exFAT usb flash drive as well as an NTFS usb hard drive with the same results.
I suspect that the HugeFiles=off setting that @aIecxs mentioned earlier may be related, but unfortunately the only information on the topic I could find were on one of his posts on p7zip's SourceForge forum where someone suggested a few different compile flags that didn't seem to make a difference for him or myself.
If anyone has any thoughts on this I'd really appreciate it! Thanks!
maybe compiling on 64-bit machine will support Hugefiles
aIecxs said:
maybe compiling on 64-bit machine will support Hugefiles
Click to expand...
Click to collapse
I'm doing that currently, but unfortunately HugeFiles is still showing up as off :/
When deodexing, there are sometimes special bootclasspaths to include for jar and app files. I have my bootpathclass listed for framework/*.jar's but none for the apps themselves!
E.g.: Bootclasspaths for frameworks pulled from my init.rc on a gtab7.7
/system/framework/core.jar
/system/framework/apache-xml.jar
/system/framework/bouncycastle.jar
/system/framework/ext.jar
/system/framework/framework.jar
/system/framework/android.policy.jar
/system/framework/services.jar
/system/framework/core-junit.jar
The others would be like: com.android.twlauncher (just an example)
Might be being stupid with logs but if someone knows it'd be awesome
Okay, im all set now. Doesn't look like theres any easy way to find out what apps depends on other apps or frameworks besides trial and error when wanting to remove vendor/carrierware
This is NOT going to contain anything for users to flash - this is for developers(or those who aspire and want to learn). This is a work in progress.
I want to make it clear that XDA nor the mods endorse or approve of this thread(well, they are allowing me to post it), but this is a concept that may be helpful for multiple reasons.
Please go easy on me, constructive criticism is welcomed, flaming is not. Do not post if you are not adding to the discussion or a developer asking a question. This is something I have been working on for a "rom" I will be putting out in a few days.. I just decided I would share the process, maybe others can help refine it.
Benefits:
If you build for multiple devices you can use this SAME flashable on those other devices and only need to edit the updater-script, prop edits that are device specific, and any system or apk's that are device specific! This could take 5 minutes or less to change AND upload!
It will work on ANY rom(for the same device) as long as you aren't modifying the things that rom specifically needs - and with this method it would be very rare that you would somehow break a rom.
You can still add files/apks, delete files you don't want, modify(rather than replace) the build.prop - technically you could create a flashable that turns stock into CM9 if you wanted to, but only then is a full ROM really needed.
Users can choose the rom they want and add your customizations(the entire community can use your flashable, rather than just a portion!)
It reduces the flashable filesize - rather than 100-400mb your flashable could be 4-20(depending how much you are changing).
It takes MUCH less time to flash, the recovery log will be shorter/easier to read, and it reduces the chance of errors(you are changing less).
Easier to track the changes since the flashable has been reduced to what is NEEDED.
This is an open source community - other devs and even users could look at your flashable and clearly see what you've done, how you've done it, so everyone benefits.
Easier to support - to make changes is EASY, faster zipping, signing, updating, uploading, etc.
You can choose to make it CONFIGURABLE - add #comments in the updater-script, the included build.prop script, or add a readme in the flashable that tells them what they can remove if they don't want it!
I'm quite sure there are MANY more reasons this is beneficial, but I'll leave it to you to decide..
Post 1 - Benefits, explanation, reasoning
Post 2 - Instructions and a soon a flashable example that I will publish
Post 3 = profit?!
First, there are totally different systems out there we can try to get running, CM9, MIUI, etc- this is when the very framework is absolutely different-- otherwise every rom we have RIGHT NOW is just a series of tweaks to the stock(like the leaked ICS) rom. We can argue that people just tweak what is there, or "develop" something new, but nearly everything is building on the concepts of something before- so let's do it right.
What makes a rom unique:
It is easier to keep track of changes(the /system will only have the changes you make, your updater-script will show you other changes, and any scripts you create will show the last changes) - so there shouldn't be "and other stuff I don't remember" in your changelog. This will also assure that there are less potential issues- you are ONLY changing specific things- troubleshooting these things are easier when you aren't including the entire modified flashable.
What you are trying to accomplish:
The main thing that makes a "rom" stand out from any other is the changes to the build.prop - you totally replaced it with something that is your own(or an adapted version hopefully giving proper credit to whoever's tweaks you are using): but they are using your "rom" if they have your build.prop and not someone else's. Everything else is deleting, copying, setting permissions, etc.
The goal: making it more open source
Until you build something totally new(Cm9, miui, etc), you are working with an open source platform, modifying, adding, deleting, scripting. Period. Admit that you are giving the base platform some tweaks, or a "flavor" that others will hopefully prefer.
If you are already developing, you know that with the correct updater-script you can add apks, delete what you don't want, over-write the things you want to replace- this includes theming and everything else you could want.. and usually you would include this in the full base rom, totally pre-configured. With a build.prop that is yours alone.
Conclusion:
Unless you are building an OS from scratch, or modifying it so heavily that it is more yours than it is not, giving the end users these options without wiping is the way to go. If they can flash your mods and then mine and end up with a better final product, how can this go wrong? This is open source, this is android, this is evolution.
Instructions:
First, keep track of all the changes you want to make - the better organized you are, the easier this will be. If you aren't even sure what all you did..
How to do it:
One of the main things you are changing by creating a total prepacked rom is the build.prop- perhaps you have tweak A, and I have tweak B, and those tweaks are different enough to change the users experience.. but why not combine them if possible? It IS possible.
Decide on the build.prop edits that you want to add/modify(you will NOT replace their build.prop) and modify the propEditor script as needed - if you build for multiple devices I would recommend you add the device specific ones at the end(with #comments) for easy modification/removal from script. You really only need to MODIFY the RO.whatever lines(because they are read only), everything else can be added to a local.prop in the /data folder
Create your updater-script as you normally would, as you know this does the main work - this will likely remain mostly the same, with just a few lines added for the scripts you need to modify the build.prop. Just make sure you delete what you would from the rom itself with the script
Rather than copy your /system /data or any other files into the rom you would normally be modifying, those are the only files you will include in the flashable - if this is done right it will make all of the changes you want without breaking anything.
If you want others to be able to understand/build upon your work you can add #comments or a readme in the above steps, then all users would have to do is remove the lines you instructed, re-zip(no need to sign if they use 7-zip or winrar) and then flash.
As said in the previous area, outside the build.prop you can make a small flashable that will change everything, but if you can MODIFY tweaks already in the build.prop, or add lines if they don't exist-- we would be creating a continual evolution of a better and better performing rom.. with feedback bad tweaks would get tossed, each developer adds their flavor, but users can flash what they want to get the performance they desire without the headache and confusion that comes with wiping everything of the developer they used before that. This will enable them to learn more about how and what we are doing with their devices, and they can provide feedback that makes it better for everyone.
The code(that may need work) to modify or add lines in the default build.prop is here:
(This may require testing, big thanks to tommytomatoe for all the help, original thread is here.)
Code:
#!/sbin/sh
# Build.prop editor script with basic sed commands
# tommytomatoe
# May 12, 2012
# mounting system as rw
busybox mount -o remount,rw /system
if [ $? != 0 ] ; then exit
fi
FILE=/system/build.prop
TMPFILE=$FILE.tmp
line1=ro.product.version
line2=ro.HOME_APP_ADJ
line3=ro.media.enc.jpeg.quality
#Add more line# formatted as above as needed to identify each prop
line1Arg=Classicv0.1.0
line2Arg=1
line3Arg=100
#Add more line$Arg formatted as above as needed for each prop change
lineNum=
#to add additional prop changes copy the lines between here
prop=$line1
arg=$line1Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
#and here and paste to the end, changing the $line# and $line#Arg to match what you've added
# to iterate over all the prop values you want to change,
# just copy and paste the code chunk or create a for loop.
# I will leave it to you to create a for loop
prop=$line2
arg=$line2Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
prop=$line3
arg=$line3Arg
if grep -Fq $prop $FILE ; then
lineNum=`sed -n "/${prop}/=" $FILE`
echo $lineNum
sed -i "${lineNum} c${prop}=${arg}" $FILE
else
echo "$prop does not exist in build.prop"
echo "appending to end of build.prop"
echo $prop=$arg >> build.prop
fi
It may require some work, feel free to offer advice if you can help make it better), but you can make a few changes to that, and rather than replacing the entire system on a users phone, you are making YOUR modifications to make their device work better! Read the #comments above to see the different tweaks you are trying to make, and it will automatically either change the value, or it will add the line if it doesn't already exist in the build.prop
Profit?!
I understand many developers may think this would make it easier to "steal" your work, but as I said before, everything android is open source. Besides, with enough changes this makes it a TRUE rom, and it will be NEARLY as complex as the much larger file he would be uploading.
It could actually be profitable time/effort wise, ANY rom could be done with this as long as you tell them what base to work with.
Example of "profit"
Mike 1986.'s ARHD is on 10 devices, if you check, most of the features in one are in the rest of them. He has enough experience where porting everything over all of his changes to a new rom probably isn't that difficult for him(I'll bet he is VERY organized), but this would enable him to make a few changes to a propEditor script, the updater-script, remove or change out a few files.. re-zip and sign, upload, done.
This also takes out much of the opportunity for developer error or errors during flashing..
Doubt I'll need it.. but we'll see.
Work in Progress, this not work for now
Hi guys,
So, for now i'm trying to build CM9 from source for xt910.
Before starting a Huge thanks to
STS-dev-team (droidhive.com) (droidth3ory / hashcode / dhacker29)
For their huge work to add spyder into cm9 & aokp.
Now the hard stuff
i won't make another tutorial on how sync cm9 repo etc... i lead you to this thread which worked well for me.
http://forum.xda-developers.com/showthread.php?p=27722264
Follow everything and you will be able to build cm9.
What you need for spyder
so you need to download few folder from STS-dev-team github
https://github.com/STS-Dev-Team
Here's the list of what i dowloaded from 'em:
- https://github.com/STS-Dev-Team/android_local_STS (which is the local_manifest you have to replace)
Code:
put into :
.repo/local_manifext.xml
- https://github.com/STS-Dev-Team/android_device_motorola_spyder (file needed to build spyder)
Code:
put into :
devices/motorola/spyder
- https://github.com/STS-Dev-Team/android_hardware_ti_omap4xxx (hardware file for OMAP4xxx)
Code:
put into :
hardware/OMAP4XXX (replace the existing one)
- https://github.com/STS-Dev-Team/android_vendor_motorola_spyder (vendor file for spyder)
Code:
put into :
vendor/motorola/spyder
- https://github.com/Hashcode/android_hardware_ti_wpan (hardware file needed)
Code:
put into :
hardware/wpan
- https://github.com/Hashcode/android_hardware_ti_camera (hardware file needed)
Code:
put into :
hardware/camera
How to
Once you synced up cyanogen repo download and place all the file above.
then do:
Code:
curl -L -o .repo/local_manifest.xml -O -L https://raw.github.com/STS-Dev-Team/android_local_STS/ics/local_manifest.xml
once finished you'll have to edit this file : device/motorola/spyder/extract-files.sh to make it work with xt910 (just replace it by the file attached
Ok, now you can start trying to build:
Code:
make clean && make clobber
lunch
(choose cm_spyder, 5 for me)
make bacon -j4
Now my error
my building stop with this error
Code:
make: *** No rules to build target « out/target/product/spyder/obj/STATIC_LIBRARIES/libhostapdcli_intermediates/libhostapdcli.a », needed for « out/target/product/spyder/obj/EXECUTABLES/tiap_cu_intermediates/LINKED/tiap_cu ». Stop.
i tried to google it but nothing helped me.
So here we are, if someone have any ideas tips knowledge to share, you're welcome.
Nice! Keep your hard work! Congrats!
Into what path are you putting them into? I had problems compiling if the path contained any spaces or some other special characters.
Check the listing of the Makefile, it will execute some special commands and if those have spaces it will as well fail.
private files under the system/bin is much less, so the error is inevitable.
PS:My English is not very good
---------- Post added at 02:27 AM ---------- Previous post was at 02:08 AM ----------
Reference cdma xt912 extract-files.sh file, executed once, and then to private files the gsm xt910 does not exist shielding to name the difference between rename the file.
Note, divided into two:
1, copy the file
2, spyder-vendor-blobs.mk file creation
Must make the appropriate match to modify.
brainwash123 said:
Into what path are you putting them into? I had problems compiling if the path contained any spaces or some other special characters.
Check the listing of the Makefile, it will execute some special commands and if those have spaces it will as well fail.
Click to expand...
Click to collapse
Well, check the OP i edit it with path.
mapleshadow said:
private files under the system/bin is much less, so the error is inevitable.
PS:My English is not very good
---------- Post added at 02:27 AM ---------- Previous post was at 02:08 AM ----------
Reference cdma xt912 extract-files.sh file, executed once, and then to private files the gsm xt910 does not exist shielding to name the difference between rename the file.
Note, divided into two:
1, copy the file
2, spyder-vendor-blobs.mk file creation
Must make the appropriate match to modify.
Click to expand...
Click to collapse
Exactly, that's why i attached a new extract_files.sh, working for xt910, i only removed missing files, but we may need to add other files.
Yes, you need to add the missing files.
Hi guys, i'm actually builing for 20mn now without error, so i think it's on good way, but don't yeld victory too fast, i have to test the build after that.
Anyway i'll update OP to make it easier and with all the new file & script i added.(probably monday, little busy for weekend )
Stay tuned
Damned computer crashed, dont use it while building
sevenup30 said:
Damned computer crashed, dont use it while building
Click to expand...
Click to collapse
Lol
Are you going to post this as a rom or just leave it as a guide? Be nice to try it but then I need more motivation to learn to build
Sent from my XT910 using xda premium
MarkyG82 said:
Lol
Are you going to post this as a rom or just leave it as a guide? Be nice to try it but then I need more motivation to learn to build
Sent from my XT910 using xda premium
Click to expand...
Click to collapse
i had to add somes files, but for now > bootloop. Try to figure it out
edit:: Ok problem with audio, it can found it because of lib.
I tried replace most part of the lib, it fix display issue but logcat is not wirking anymore :s
i think we have to rework a lot the work done by STS dev team before compile. monday i'll upload the build if someone want to try something with it.
Hello,
I spent a lot of time searching and finding the material to understand and reproduce process about bump!.
After a few times shared the results of my manipulations on stock kernel, which I applied the method I'll describe here, I will try now to explain how you can make for yourself an identical result.
If you are still wondering what is Bump! I can only invite you to look for yourself, and even give you the link where I tried to answer this question on the section of the G2.
The purpose of this topic is to get you to bump kernel, from a PC, Linux, or Windows, or even from the phone.
I'll try to explain as why certain steps are essential to ensure a good result, steps that, at first, did not seem obvious.
When you will try it, and will want to test the result, make sure nice to have taken the necessary precautions before: Make a backup of your current kernel foremost flashing.
Now, you know what is BUMP! and why kernel must be bumped. Bump! basically involves injecting a signature in a file (boot).
This injection of the signature to be made in hexadecimal format, and immediately after the last used page of the kernel, we have to remove unnecessary bytes before doing so, and unpack/repack kernel is the easiest way to do so (http://forum.xda-developers.com/showpost.php?p=60086231&postcount=42). To do that, we need two binaries (unpackbootimg and mkbootimg).
About these two binaries, we can compile them ourselves from source, or taking already compiled bins.
@osm0sis made and share a super tool containing all that we need, these compiled bins, in his Android Image Kitchen - Unpack/Repack Kernel Ramdisk [Win/Android/Linux].
So i propose to use it here. The big advantage to this, is that @osm0sis compiled for windows, linux, and phone (arm). He created scripts that automate unpack and repack too.
The purpose of this topic is not to learn how to get the kernel file (boot), I assume that this prerequisite is acquired. However, I give you some hints for beginners, you can take a look at KDZ and TOT Extractor from @bullghost or the dd command to achieve.
1) Simply Bump a stock kernel in Linux (no change in ramdisk) to obtain a bumped working untouched stock kernel
Download the linux version of Android Image Kitchen - Unpack/Repack Kernel Ramdisk [Win/Android/Linux] ( AIK-Linux-v1.9.1-ALL.tar.gz), and untar it somewhere. Create, in the root directory of AIK, one file named "one_shot_bump.sh" (or the name that you like) containing this code I gave in osm0sis AIK thread (or, if you prefer, you can take the file named "linux_one_shot_bump_only.tar.gz" in attached files here), and chmod it 755.
Now you can use it by opening a terminal and drag and drop this file inside following by drag and drop kernel file too. Press enter, it's done You'll find a file named bumped.img, in AIK root directory, wich is your bumped kernel.
Note: bash for this script is very important for an expected result for printf cmd. It doesn't work as expected with sh.
2) Simply Bump a stock kernel in Windows (no change in ramdisk) to obtain a bumped working untouched stock kernel
I've not made a one click script to bump on this OS, but I'll explain very simply how to get there using the scripts offered natively in the osm0sis tools . This fair will be in three stages, for the reasons discussed in the preamble:
1) unpack the kernel
2) repack the kernel
3) inject hexa signature (bump!)
So to begin, download the windows version of Android Image Kitchen - Unpack/Repack Kernel Ramdisk [Win/Android/Linux] (Android.Image.Kitchen.v2.3-Win32.zip).
Unzip it where you want. Open a dos prompt and drag and drop unpackimg.bat on the prompt windows, tape one spaces in the command and drag and drop your kernel file in the prompt windows. Tape on enter: You made the first step, your kernel is unpacked.
Don't close window prompt, tape one touch to continue, as the prompt invite you to do.
Now, just drag and drop repackimg.bat in the prompt windows, and tape on enter. Done, you just finished the second step, you've repacked the kernel (image-new.img on the root folder of AIK).
Now, for doing the step 3, you need to inject the signature. I have not found other solutions at the moment than to use a hex editor to do this. I tried with a shareware (Hex Editor) and also with a freeware (HxD) with succes for these two softwares. With Hex Editor, after opening image-new.img, click on the first free byte at the end of the file and copy paste there "41A9E467744D1D1BA429F2ECEA655279" (without double quote). Save the file.
Or with HxD, after opening image-new.img, click at the end of the file, just after the last used byte, and in the menu"edition", choose "insert bytes". On the dialog box, type 10 on the first field (amount), let "hex" checked, and paste in the second field the value "41A9E467744D1D1BA429F2ECEA655279" (without double quote). Save the file.
Done, you just finished bumping your kernel in windows
I can give later screenshot if needed/asked.
Edit: i've found a workaround for using @osmosis tool to sign (bump) kernel just after repacking. Details can be found here: http://forum.xda-developers.com/showthread.php?p=63884919#post63884919
Edit2: After talking with @osmosis, the best solution for signing (bump) the kernel just after repacking should be to use cygwin printf.exe (I've attached this file to this post), that can be added in aik/bin folder (the real name of this folder is android_win_tools and it can be found in the root of AIK tool). So we just need to put printf.exe in android_win_tools folder, and replace this code in repackimg.bat
Code:
%bin%\mkbootimg --kernel "split_img/%kernel%" %ramdisk% %second% --cmdline "%cmdline%" --board "%board%" --base %base% --pagesize %pagesize% --kernel_offset %kerneloff% --ramdisk_offset %ramdiskoff% %second_offset% --tags_offset %tagsoff% %dtb% -o image-new.img %errout%
by
Code:
%bin%\mkbootimg --kernel "split_img/%kernel%" %ramdisk% %second% --cmdline "%cmdline%" --board "%board%" --base %base% --pagesize %pagesize% --kernel_offset %kerneloff% --ramdisk_offset %ramdiskoff% %second_offset% --tags_offset %tagsoff% %dtb% -o image-new.img %errout%
%bin%\printf \x41\xA9\xE4\x67\x74\x4D\x1D\x1B\xA4\x29\xF2\xEC\xEA\x65\x52\x79 >> image-new.img
As you can see, just one new line was inserted for injecting the signature.
3) Simply Bump a stock kernel in Phone (no change in ramdisk) to obtain a bumped working untouched stock kernel
I will not reinvent the wheel, you can use an existing tool for some time, made by @somboons, which uses the technique I mentioned here (unpack the kernel, repack it and injection of signing , all in the phone).
This script is an adaptation of Live bump by @Skin1980 that uses the arm versions of unpackbootimg and mkbootimg.
You will find the instructions and the tool here:
http://forum.xda-developers.com/lg-g2/development/tools-bump-kernel-offline-t3073261
---
Credits and thank's a lot:
codefire team for bump!:
@thecubed , @Shelnutt2 , @IllegalArgument , @autoprime , @AnimatronicRocketReptile , @Dees_Troy
@Skin1980 for his live bump and these explanations
@osm0sis for his Android Image Kitchen - Unpack/Repack Kernel Ramdisk [Win/Android/Linux]
@zequav for explain me at the beginning what happen with bump and what can be done on linux
How to add init.d support and SELinux permissive on the Ramdisk
Here, i explain how to implement in Ramdisk init.d and SELinux permissive.
We start from untouched kernel not bumped (so not from the kernel we eventually have bumped with the previous post).
Use @osmosis tool android image kitchen version for your system to unpack it.
After that, navigate to the AIK root folder and:
in split_img/boot.bin-cmdline, replace
Code:
console=ttyHSL0,115200,n8 user_debug=31 ehci-hcd.park=3 msm_rtb.filter=0x37 androidboot.hardware=g3
by
Code:
console=ttyHSL0,115200,n8 user_debug=31 ehci-hcd.park=3 msm_rtb.filter=0x37 androidboot.hardware=g3 androidboot.selinux=permissive
in ramdisk/init.qcom.rc replace
Code:
on property:sys.boot_completed=1
start qcom-post-boot
by
Code:
service sysinit /sbin/sysinit.sh
oneshot
class late_start
user root
group root
disabled
on property:sys.boot_completed=1
start qcom-post-boot
start sysinit
and on /sbin folder, add a file named "sysinit.sh" that contains this code:
Code:
#!/system/bin/sh
mount -o rw,remount /system
if [ ! -e /system/etc/init.d ]; then
mkdir /system/etc/init.d
chown -R root.root /system/etc/init.d
chmod -R 755 /system/etc/init.d
fi;
mount -o ro,remount /system
run-parts /system/etc/init.d/
/system/xbin/daemonsu --auto-daemon &
Note: This previous code on sysinit.sh is only for those who have run-parts installed (with busybox by example). Otherwise, for those who don't want to use run-parts, you can put the next one that don't need it:
Code:
#!/system/bin/sh
mount -o rw,remount /system
if [ ! -e /system/etc/init.d ]; then
mkdir /system/etc/init.d
chown -R root.root /system/etc/init.d
chmod -R 755 /system/etc/init.d
fi;
mount -o ro,remount /system
setenforce 0
FILES=/system/etc/init.d/*
for f in $FILES
do
$f
done
/system/xbin/daemonsu --auto-daemon &
Now you are ready to repack the kernel. Use AIK repackimg script for that. After repacking the kernel, you still have to sign it (Bump!).
For this last formality depending on the OS which you find yourself:
1) On Linux
put a file that you name as you want with sh ext(bump.sh should be a great idea ) on the AIK root folder, and chmod it 755.
On this file put the code above:
Code:
#!/bin/bash
printf '\x41\xA9\xE4\x67\x74\x4D\x1D\x1B\xA4\x29\xF2\xEC\xEA\x65\x52\x79' >> image-new.img
Save it, and now just drag and drop this file on a window terminal and valid. That's all
2) On Windows
Refer to the OP, i explained there how I bump on windows
3) On Phone
Refer to the OP, i explained there how I bump on the phone
Wow great, waiting for chapter 2
reserved
u25150 said:
Wow great, waiting for chapter 2
Click to expand...
Click to collapse
I feel that few people seem really passionate about what I say, if I refer to the answers
Also I'm going to focus on those who, like you, arise, and seem interested in this subject.
What specifically would you like to see some detail (what do you call "chapter two" ) ?
Duckscreen said:
reserved
Click to expand...
Click to collapse
Welcome, pleased to meet you
@6ril1 great work my freind
jac10000 said:
@6ril1 great work my freind
Click to expand...
Click to collapse
Hi my friend (not my freind, which is an advantage of German expression, ) , thank's, I assume that it is better to teach to fish than give fish, but perhaps this concept is it outdated ?
Could you making how to kexec hardboot patch Guide please
(for support Multirom)
Really nice work my friend !!!
In Linux, I just make my first bump boot thanks to you :good:
jac10000 said:
Really nice work my friend !!!
In Linux, I just make my first bump boot thanks to you :good:
Click to expand...
Click to collapse
You are welcome
And great thank's for having notify me my mistake about code i wrote in post 2 (class late_sart instead of class late_start )
Code is edited and correct now
Yeaah @6ril1 and my first bump boot with SELinux permissive
jac10000 said:
Yeaah @6ril1 and my first bump boot with SELinux permissive
Click to expand...
Click to collapse
LOL, thank's to have testing all of that i described in this thread, and for having mentioning me in private some others mistakes (unexpected one space inserted during copy-paste on the post 2 and one code tag not closed) . I have edited again with all that you find and now it should be correct
THANK'S again my friend
For windows user, new stuff added, i'll edit op with that too:
http://forum.xda-developers.com/showpost.php?p=63884919&postcount=716
Edit2: One more simple solution just added in OP
I have new-img but how do you use hex editor exactly? i can not figure it out. can u help with screenshots please?
I tried your tutorial (windows x64)(only bump no change in ramdisk) for 30c MM kernel but my phone wont boot(i don't have security error). Any ideas? Thank you!