Database Info

[Q] Is there an easy way to apply the patch files from the OTA on a PC?

I'm looking for a way to apply the patch files to the TF system image on a PC. This is not about how to get the ota to flash- I got that covered. This is about repacking roms or making flashable updates that don't rely on stock firmware.
I found a few ways, but none of them seem "easy."
The dirty way- apply the OTA and grab the system image.
From the PC command line - Linux has diff/patch, but that doesn't work for some of the patches in "IMGDIFF2" format. Besides, I'm not sure I ever got the regular BSDIFF40 patches to work.
The git option- There is the apply_patch source code in github. This works great, but I have to run it on the TF. Is it possible to compile this to work on my ubuntu box?
Maybe there is some magic script out there called apply_ota?
Thanks in advance

gee one said:
I'm looking for a way to apply the patch files to the TF system image on a PC. This is not about how to get the ota to flash- I got that covered. This is about repacking roms or making flashable updates that don't rely on stock firmware.
I found a few ways, but none of them seem "easy."
The dirty way- apply the OTA and grab the system image.
From the PC command line - Linux has diff/patch, but that doesn't work for some of the patches in "IMGDIFF2" format. Besides, I'm not sure I ever got the regular BSDIFF40 patches to work.
The git option- There is the apply_patch source code in github. This works great, but I have to run it on the TF. Is it possible to compile this to work on my ubuntu box?
Maybe there is some magic script out there called apply_ota?
Thanks in advance
Click to expand...
Click to collapse
I recently wrote some code for a ARM basestation (basically like a Freescale cell-phone board), and had to be able to supply some updates over time. Before the project ended, I'd also found bsdiff and bspatch and tested them on linux, where they worked fine (as long as you'd created either an ARM bsdiff/patch version or somehow took the big/little endianness of the hardware into account).
At first I thought it wasn't working but it seemed to do OK on standard cross-compiled-for-ARM files. (well, they still ran and performed the same stunt..).
The thing that worried me about this method is that they'd never have the same md5sum before as after, likely because they had a different amount of bytes. (e.g. you make your own before and after and build each, then create the patch file using bsdiff, then patch the old file using the patch file, and create a 'newtestfile', but look at the number of bytes (or md5sum it) difference between the original stage 2 file and the stage 1 + the patch file via bspatch).
Sorry that is pretty confusing the way I just tried to explain it.. I'll look this over again tomorrow and figure out if I said anything worthwhile

For inputs, the applypatch binary takes the file names, sha1 checksums of the before and after, and the final target size. Chance are high that the patch would only work if everything went in and came out properly.
Code:
apply_patch("/system/framework/framework-res.apk", "-",
99b382b5886e505508fa3f730d778a1bed4bc04e, 9761707,
a4798fb8d61d08b6f067e522e67107f6dd556148, package_extract_file("patch/system/framework/framework-res.apk.p"));
I think that bsdiff/patch will generally work on most of the OTA (BSDIFF40 files), but some of the files are IMGDIFF2, which targets binary/data files.
The applypatch binary works on both and as far as I can tell, is the same binary that the TF uses. Here is a snippet from the AOSP recovery... TF binary included Use the binary on your TF, not applypatch.sh! I suppose you can put it in system/xbin/
It would resolve the issue if I could compile this to run on my desktop from ubuntu. Short of that, I'm working on a script for the TF to parse the updater script.

gee one said:
For inputs, the applypatch binary takes the file names, sha1 checksums of the before and after, and the final target size. Chance are high that the patch would only work if everything went in and came out properly.
Code:
apply_patch("/system/framework/framework-res.apk", "-",
99b382b5886e505508fa3f730d778a1bed4bc04e, 9761707,
a4798fb8d61d08b6f067e522e67107f6dd556148, package_extract_file("patch/system/framework/framework-res.apk.p"));
I think that bsdiff/patch will generally work on most of the OTA (BSDIFF40 files), but some of the files are IMGDIFF2, which targets binary/data files.
The applypatch binary works on both and as far as I can tell, is the same binary that the TF uses. Here is a snippet from the AOSP recovery... TF binary included Use the binary on your TF, not applypatch.sh! I suppose you can put it in system/xbin/
It would resolve the issue if I could compile this to run on my desktop from ubuntu. Short of that, I'm working on a script for the TF to parse the updater script.
Click to expand...
Click to collapse
I'm not sure I understand the intent. I've just awoken and that's probably part of the problem..
'applypatch' is part of the standard (say 10.04 ubuntu) repo and is in a package called makepatch. Did you want to be able to run it "from" a standard x86 Ubuntu dist but have it targeting "armle" files or just be able to run it both on Ubuntu & Android correctly?
The files I tested were a) both binaries in different stages of evolution, and b) both built for armle(droids) and x86_64 and didn't behave differently, worked, and the checksum could be pre-calculated.
I'm going to mess around with applypatch when I'm out of my morning coma and get back to this in a bit.
Hah -- I do wonder if there's already a script (maybe it's a binary though) that lives in the dm* app on the tf101 that just does this already. You may have been right about that. Something has to apply those OTA patches. There's a few mechanisms for detecting them but I hadn't thought about how they're applied.
I'm trying to think if there's any scenario where the market applies 'patches' rather than always downloads the next version in entirety. Not sure about that.
Anyway, I'll see if I can get anywhere with applypatch.
Edit:: After a little messing around :
I finally see what you are trying to do and why what I'm doing is totally useless for that. I'm going to spend a little time looking over the imgdiff2 (apk) deal, and probably end up now figuring out a thing.

I'll look into the makepatch package later today. Maybe that might be what I'm looking for.
Just to be clear, the intent is to be able to patch a "stock" system without it actually running on the TF. For example, to take the stock 8.6.5.9 image, decompress system/ to the PC, apply the patches from the OTA, and then end up with a stock 8.6.5.13 image. This would all happen on the PC, not the TF. It would streamline the ROM cooking process and make it easier and faster to spit out a complete, flashable update that won't fail sha1 checks because of mods.
sent from my cyanogen(mod) vision

Zombie Thread Alert!!!
You have been warned....
OK, so my C-fu isn't strong enough to figure out how to cross compile the apply patch binary to run on a x86 computer. However, I did notice that the applypatch binary gets built in the aosp/generic_x86 build, specifically in the system/bin folder.
This will be an exectuble file that will run on a x86 linux based system and do the same thing that the applypatch binary does to the ota package during the ota update. In other words, you can apply the ota patch to a system image from the comfort of the linux command line without having to actually flash the ota. This will allow you to be the first one on your block to have the new system image without having to mess up whatever rom you are currently running.
Of course, this might all be moot if we don't see another ota for our tf. Come on ASUS, just one more so I can test this out on a live update.
OK, so if you read this far, repo sync your aosp source and build the generic_x86 branch. The binary is aosp/target/product/generic_x86/system/bin/applypatch_static
edit: then after you've done that, use a script to parse the updater-script to extract the patching commands and then she-bang! I'll post mine a little later- I've got to get some flowers for tonight

Any luck with that? I'm also searching for a way to apply an OTA update to a ROM using Ubuntu.

bgcngm said:
Any luck with that? I'm also searching for a way to apply an OTA update to a ROM using Ubuntu.
Click to expand...
Click to collapse
Yeah, it works like a charm. The binary is compiled in the aosp/generic_x86 build. There is no need to flash, you can just pull it out of the system/bin folder after compiling the source. You can probably use an "mmm" command to make just files you want, but I'm not sure which package it's in. Then, I use a script that converts the OTA patch commands in the updater-script to a script file that runs on my linuxbox that calls the binary and patches the ROM under linux/ubuntu.

Do you mind sharing your applypatch binary? I don't have AOSP source on my Ubuntu installation right now, so if you don't mind sharing I wouldn't need to build it from sources...

bgcngm said:
Do you mind sharing your applypatch binary? I don't have AOSP source on my Ubuntu installation right now, so if you don't mind sharing I wouldn't need to build it from sources...
Click to expand...
Click to collapse
I attached the applypatch binary- it should work on most x86 linux distros, maybe.
As I stated in my earlier post, the binary is built with the x86 build. I'm not so good with the build system, but I think the code is from the bootable/recovery/applypatch. I included the relevant notices for that code.
In the OTA updater-script, there will be a bunch of applypatch commands- you might have to change the name/permissions of the binary, but that syntax should be what you are looking for.
Enjoy!

Thank you very much for your time. It seems we are almost the only one trying this. The thing is that I really need to get this done because OTA update is failing for me by running it the usual way.
I've tried your binary and it works under my Ubuntu installation, however I was trying to manually patch just one file and got this:
Code:
[email protected]:~/Desktop/system/app$ applypatch_static ./ApplicationsProvider.apk - d9023cd58fd055e1ca3c8f8492b2c36aba923c6a 6184 69bea5d5a62980c611b903de8243d980f30e5fb5:../../patch/system/app/ApplicationsProvider.apk.p
applying patch to ./ApplicationsProvider.apk
target 6184 bytes; free space 1080520704 bytes; retry 1; enough 1
chown of "./ApplicationsProvider.apk.patch" failed: Operation not permitted
I got that chown error message although ApplicationsProvider.apk.patch was created. Is this the patched file?
EDIT: Nevermind, I forgot to run the command as superuser.
EDIT2: Would it be too much if I ask you also to share the script that converts OTA commands from updater-script into the correct syntax to run on Ubuntu?

There is no guarantee that this will work on your machine. It's a work in progress and will probably require some editing. This just creates the scripts that extract the commands from the OTA updater-script.
I haven't used it in a while since ASUS hasn't put out any updates lately, but I would copy the updater-script and rename it delete_source. Then I would edit out everything in delete_source except the delete commands. There might be an issue with a trailing ; or similar character. The script runs on the copy of the updater-script to pull out the applypatch commands and the delete_source to pull out the files that need to be deleted from the rom.
Check the syntax, but it will be something like ./tf_file <head of stock rom> <head of patch source>
If you have the donor stock system folder and the patch folder from the OTA at the same dir level, it would be ./tf_file system patch
The script also assumes that the applypatch binary is in your path as apply_patch. You can adjust as needed.
Lastly, my bash skills are probably pretty weak, so if you see ways to improve this script or add error/path checking, feel free to post improvements, etc. There is probably a really slick way to do this with just one script and not a script that makes three other scripts. The historical reason for this is that I used to transfer the files to my transformer and run the script on there. Running in Ubuntu is much faster!
Good luck!
Code:
#!/bin/bash
# extract_source is used to pull files to be patched from source tree
# delete_source is ued to delete unneeded files from the source tree
# tf_file applies the patches to the extracted source files
# don't forget to copy the direct updates in the OTA
# usage is apply_ota
# assumes that updater-script and delete-script are at same directory level
# updater-script is from META-INF folder, delete-script is from updater-script
# add error checking to count number of patches and number of patched files
# parse trailing / in folder names
work_dir=`pwd`
tf_file=$work_dir"/tf_file"
extract_source=$work_dir"/extract_source"
delete_file=$work_dir"/delete_source"
work_file=$work_dir"/work_file"
echo "#!/bin/bash" > $tf_file
sed ':a;N;$!ba;s/\n/\ /g' updater-script | sed -e 's/;/\n/g' -e 's/\ \ */\ /g' | grep "apply_patch(" | sed -e 's/"//g' -e 's/,\ p/\:p/g' -e 's/,//g' -e 's/package_extract_file(/$2\//g' -e 's/(/\ $1/g' -e 's/))//g' >> $tf_file
chmod 755 $tf_file
echo "#!/bin/bash" > $extract_source
#sed ':a;N;$!ba;s/\n/\ /g' updater-script | sed -e 's/;/\n/g' -e 's/\ \ */\ /g' | grep "apply_patch(" | cut -d \" -f 2 |sed -e s'/^/cp\ --parents\ $1/g' -e s'/$/\ \$2"\/\"/g' >> $extract_source
sed ':a;N;$!ba;s/\n/\ /g' updater-script | sed -e 's/;/\n/g' -e 's/\ \ */\ /g' | grep "apply_patch(" | cut -d \" -f 2 |sed -e 's/^/cp\ --parents\ $1/g' -e 's/$/\ \$2"\/\"/g' -e 's:/system::g' >> $extract_source
chmod 755 $extract_source
sed -e 's:",:\n:g' -e 's:\ ::g' delete-script > $delete_file
sort -r $delete_file > $work_file
echo "#!/bin/bash" > $delete_file
grep / $work_file | grep -v /$ | sed -e 's:"/:rm\ \$1/:g' >> $delete_file
grep /$ $work_file | sed -e 's:"/:rmdir\ \$1/:g' >> $delete_file
chmod 755 $delete_file
exit 0

IMGDIFF Tool Needed...
Hello Sir, i am looking for a tool to generate IMGDIFF patches on windows... i already have a BSDIFF tool, but coudn't find IMGDIFF... Thank You

I have no idea about windows, but the source is here.
https://android.googlesource.com/platform/bootable/recovery/+/master
You could install linux and build it from there. Follow these directions http://source.android.com/source/building.html
There is also lots of great info here http://wiki.cyanogenmod.org/w/Development#Learning_To_Build_CM
Good luck!

gee one said:
Good luck!
Click to expand...
Click to collapse
I am very thankful to you for replying me sir... these guides are awesome, but i dont think my slow internet connection and PC with 1GB RAM will be allowing me to download or compile
actully i was making a tool to apply OTA Updates in PC, it is semi functional for now, it is able to read updater script and apply bsdiff patches, but can't handle imgdiff patches and now i am stuck at this point because of no imgdiff port for windows... :crying:
i will be very thankful if you or @bgcngm can compile imgdiff at least for cygwin? else i will have to postpond this project until someone else compile and port imgdiff for win/cygwin

Sorry- I'm clueless about cygwin. You could try dual booting to linux to compile from there.

gee one said:
You could try dual booting to linux to compile from there.
Click to expand...
Click to collapse
Thanks alot for taking your time to reply me sir now it seems like linux is the only option left
as you are a linux user will it be too much if i ask you to find a right guide to compile ota tools only? cause i don't know much about linux, and it will be difficult for me to find right guide to compile ota tools only...

jawad6233 said:
Hello Sir, i am looking for a tool to generate IMGDIFF patches on windows... i already have a BSDIFF tool, but coudn't find IMGDIFF... Thank You
Click to expand...
Click to collapse
Answer is here - [Tool]imgdiff executable for windows. BTW, anybody have applypatch for Win32?

Hoping this works for lollipop.

[Tutorial/How-To][GB] Make Your Own Custom Rom & Kernel (Last Updated 30/07/2012)

Introduction
Hi guys, so im seeing a real lack of dev work going on in these forums so here i going to make a guide on making a custom rom and a custom kernel for the optimus 3d. XDA's about sharing so im going to tell you nearly everthing i know to get you started. This is no means the best/definative way as im still learning alot myself only starting this kind of stuff about 6 months ago. I dont call myself a dev so there could be things wrong but here is how ive made my stuff to share with you. Ill probably update these posts as time goes on too, to improve & answer questions. Plus ill probably forget something too. Plus it would be good if other dev types in this forum could maybe share a few of there words of advice, wisdom & tips. This will hopefully encourage people to use & create for the device.
Chapters/Posts
Post 1- Getting Started
Part 1- Prequisites
Part 2- Getting Necessary Basic Stuff Done For Your Rom
Post 2- Making The Rom Custom & Extra Mods
Part 1- Basic Mods
Part 2- Advanced & More Complex Mods
Post 3- Making The Custom Kernel
Part 1- Getting Set-Up
Part 2- Compiling Your zImage
Part 3- Making Your RamDisk
Part 4- Making Your Boot.img
Post 4- Changelog
Post 5- Dev Bible!
Getting Started
Presquisites
This guide assumes you have some knowledge on how to use basic computer stuff, use other guides in the forum, know how to use a rooted phone & have some general common sense. If you dont what some of this stuff research it before you carry on reading.
Youll need a computer(dugh) with preferably a linux distro like ubuntu 10,11 or 12(for kernels) and windows, xp, vista, 7 & 8 should all be fine. These arent necessety, im sure you can probably complile stuff on windows and on other distro's and versions but this is how ive done my stuff. Again dont ask where to get these.
Youll also need a memeory card with enough room to hold a cwm backup & some mods so 1gb is/should be plenty and fully charged battery too, we wouldnt want the battery to go flat during a risky process would we.
I recommend you also have these apps/tools too, they will make the process alot easier and your gonna need some of them along the way.
For Windows
Kdz flasher or .bin flasher- http://forum.xda-developers.com/showthread.php?t=1287236 Big Thanks To adixtra
Winrar (trial version is fine)- http://www.rarlab.com/download.htm
Or 7zip As Recommended By Pandaball- http://www.7-zip.org
Notepad+ From Here- http://notepad-plus-plus.org/
Megatron Root Method- http://vulnfactory.org/blog/2012/02/26/rooting-the-lg-thrill-optimus-3d/
CWR Flash Tool By Paki0402- http://forum.xda-developers.com/showthread.php?t=1482713
For Ubuntu/Linux
LG's Source Code Page: http://www.lg.com/global/support/opensource/opensource.jsp
Kernel Build Tools- sudo apt-get install uboot-mkimage (In Terminal)
Ramdisk Compile/Decomplie Tool- http://forum.xda-developers.com/attachment.php?attachmentid=1215193&d=1342992085
ARM Toolchain- https://sourcery.mentor.com/public/...-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 (Recommended)
disxda Kitchen- http://forum.xda-developers.com/showthread.php?t=633246
For Yourself
Computer, Preferably Modern Otherwise Things Could Get Slow
Coffee- http://www.starbucks.com/coffee/reserve/galapagos-san-cristobal
Patience
Time (Definatly Dont Ask Me Where To Get This Since I Couldnt Find A Link)
Getting Necessary Basic Stuff Done For Your Rom
Firstly youll need a rom to modify for this you can either download a ready made rip of a rom like from fabio in this thread http://forum.xda-developers.com/showthread.php?t=1155874 or you can make your own. For this youll need to have a fresh kdz flahed to you phone from here http://lg-phone-firmware.com/ or from another source if you prefer .bin. Once you have flashed i recommend just skipping all the setup stuff like market, wifi and accounts stuff since your not gonna need it yet.
Next we need to make a copy of your freshly flashed kdz if you going down this root(no pun intended) otherwise youll already have it in zip format & probably already rooted too. Talking about rooting this will be the next thing you need to do & since were running gingerbread youll need to root with megatron found here -insert link here- follow that guide & thanks to Dan for that breakthrough which without, this probably wouldnt be possible.
After your rooted youll need to get ClockWorkMod recovery. There are two ways you can get it either through rom manager in the Playstore or from this tool here -insert thread here-. Cheers paki for that very useful tool and koush for the recovery. For SU760 people use ibluemind version here http://forum.xda-developers.com/showthread.php?t=1565412 thank you iblue too.
Now were all rooted and have recovery installed we can now make a copy of the entire system. This bit is easy youve all probably done it before too. You will need to boot into recovery either with the button command or through rom manager app. Then just simply make a backup of you rom, while your waiting put the kettle on make yourself a coffee & enjoy a litttle break.
Ok so now we have a base for our custom rom based on whatever version kdz you flashed. Now we need to transfer this to our pc. So go to you backup & simply copy & paste the system.ext3, data.ext3 & boot.img to where you want to do your work, the rest you wont need unless something goes wrong later. The backup is located on the external memory card in the clockworkmod/backup directory.
So we have the necessary parts on your computer, youll need to decompress the system.ext3 and data.ext3 using winrar or other zip app. Then once you have your system and data folders set up you can start the modding but first thing to do is delete anything personal from the data folder so make sure only the app folder remains in the data partition like this data/app and no other folders like app-private, fota & data. If you want you can do away with the data part all together and just keep it simple.
We now have a basic stock rom in its raw form. So now youll need to package it up. For this ill provide a donate install script zip at the bottom of this post for which you can simply drap & drop your system folder and data folder if your including it. Youll also need to drag over the boot.img, this can be one you have made from the guide below, one from your backup folder which would be the stock kernel or one from a kind dev if they will let you use there's.
Thats it you should now have basic stock rom from which you can build upon, just flash it to your phone and test if it works. If you want to get creative i recommend you download and use disxda's Kitchen this will do the extraction part too.

Making The Rom Custom & Extra Mods
Ok guys & gals we now have a lovely stock base zip but its not lovely enough is it, we need to set it apart from from stock. This is where it could get complicated depending on your experience or your understanding on things. First off youll need to scour the realm's of XDA for what you want, but ill give you a few links & mods here that you can try yourself. Just remember not all these may work or be fully compatible with our device. I recommend you try these on your device first before applying them to your rom zip, just in case if they work then go ahead try them in your zip.
Basic Mods
Basic Mods are what i would consider as copy & paste mods like build.prop mods, some simple ready made zip packages such as Beats & Bravia mods and etc tweaks like apn's, hosts, .conf tweaks etc.
Here's some links to some you could try.
Beats- http://forum.xda-developers.com/showthread.php?t=1525226 (Recommend 0314 Package)
Build.prop Tweaks- http://forum.xda-developers.com/showthread.php?t=1631092
Boot Animations- http://forum.xda-developers.com/showthread.php?t=1053250
To apply a build.prop mod simply open your build.prop in the system directory and copy & past them at the bottom of the file like this:
Code:
#
# my build.prop mods
#
dalvik.vm.heapsize=64
Then simply save. In the build.prop you can also change you rom name in the ro.build.display.id= and other small mods too.
Next we want to apply zipped based mod like a boot animation or even Beats mod. There are 2 ways you can do this, so one way for this is to simply download the mod & extract to a folder for example modz folder and copy each file/folder into the relevent directory of your system folder or you can have both your mod zip and rom zip open and simply drag them over to the rom zip from the mod zip. Just be wary if there is a build.prop tweak within like in the Bravia & Xloud mod or text based part of the mod you will have to manually copy the extra lines from one modded one to yours. For example:
Code:
#
# my build.prop mods
#
dalvik.vm.heapsize=64
# Xloud Engine
ro.semc.sound_effects_enabled=true
ro.semc.xloud.supported=true
persist.service.xloud.enable=1
# BRAVIA Engine
ro.service.swiqi.supported=true
persist.service.swiqi.enable=1
Advanced & More Complex Mods
These are the sort of mods that can make a big impact on your rom. Usually involves changing or even coding system variables for asthetic & performance purposes. Things such as framework editing and scripts would come under this category. Although scripts are easy to apply some of them require modifications to get the best or even work with our device. Scripts are placed in the system/etc/init.d directory. You probably wont have this cause your developing from a stock rom, so youll need to create that folder. To enable the use of init.d scripts you will also need init.d support from the kernel, this will be covered later in the guide but if your using a custom kernel youll most probably already have this feature.
Here are some links to some popular script based mods that work well with our device:
http://forum.xda-developers.com/showthread.php?t=1227269
http://forum.xda-developers.com/showthread.php?t=1556013
http://forum.xda-developers.com/showthread.php?t=1236779
Once you have added your scripts we need to edit the updater-script to ensure they have the correct permissions. This is located in your zip in the /META-INF/com/google/android/ directory. To edit open in notepad+ or gedit and enter as below for every script you add.
Example
Code:
set_perm(0, 0, 0777, "/system/etc/init.d");
set_perm(0, 0, 0777, "/system/etc/init.d/01Your1stScriptName");
set_perm(0, 0, 0777, "/system/etc/init.d/02Your2ndScriptName");
set_perm(0, 0, 0777, "/system/etc/init.d/03Your3rdScriptName");
And so on for more scripts then save. If your script needs different permissions, set them according to the authors/devs's instructions.
Now on to deodexing, this isnt necessary but it makes theming your rom much easier later. To do the deodexing i recommend you use disxda's Kitchen. This part of the instruction is based on using Ubuntu but it probably applies to the Windows version too. Its easy and quick to use. Just simply drag the your roms zip into the original_update folder and load up the kitchen. If your using Ubuntu it will ask if you want to run in terminal, select this option. So now you have the kitchen up, go to create working folder for rom, press enter and then select your zip(My1stRom.zip). the kitchen will then ask you about the script just select 2 (do nothing) then press enter again when it comes up with a warning about update-script. Then go to advanced options and select deodex it will ask you whether or not you want to do system apps and some other stuff, just select option b, both folders (recommended). Press enter again at logging. Then this should deodex everthing in you rom. On ocassions there some certain apk's that cant be deodexed, dont worry there's only a few that cant be done. Thats it after about 10-15 minutes, now youre deodexed. This may take longer on a slower pc though. Just press enter again to get to continue and exit to the main menu.
So there we go, youve incorperated your mods that you want, its time to repackage it all up but this time we will use the kitchen to do this. Select 99 Build Rom from working folder, select interactive mode, select yes to zipaligning, select no to adding updater script, select yes to signing your rom, select yes to changing name, enter a new name My1stRom for example.
Now just copy the zip to your phone from the OUTPUT_ZIP directory then flash to you phone and see/feel/hear the difference. If all is well then congratulations you have now made a custom rom. Obviously these are just the begining of modifying your rom there are loads more things you can change and do things different ways but these come with experience and research such as modules and modified libraries, media hacks and such.

Making The Custom Kernel
So this is the post some of youve probably been waiting for & probably going to be the hardest one to write up so im gonna apologise now for my lack of typing & explaining skill You will need a linux distro for this bit, as ive not tryed using compilers for Windows. Any distro should be fine im currently using Ubuntu 12.04 LTS but have sucessfully done this on older versions. Im only going to cover the basic stuff with this guide it would be impossible to show you everything but ill show you a couple of mods to get started like overclock, a few fixes of LG's mistakes (For V21E Base only, other LG kernel's may have there own problems too PM me if your stuck) & changing a few variables stuff.
Getting Set-Up
Ok first off we will need to get our source. You get this from the LG Open Source website, link is attached in the first post. Obviously we want the latest 21E source or if your doing this for P925, get the latest or the one you want for that. Then youll need to download & extract it. This will be fine to do in the 'Download' folder. Once you have extracted it youll have another 2 tar archives. You will want to extract the LGP920_Gingerbread_Kernel.tar.gz, again in the same directory your in will be fine. So now you should have a folder named 'kernel'. Before you can continue we will need to rename the base directory to something more simple like LGP920v21ESource otherwise if you have brackets and other punctuation stuff it will give you a syntax error later.
Next we will need the ARM Toolchain in order to compile your kernel source. This is in the first post, this is the same toolchain that LG uses to compile it. You can use other compilers but you will have to modify a few things to get it working. That is for another post another day maybe. So now we need to extract the toolchain, do this in the same way as before in the 'Download' folder. Now youll have a folder named 'insert proper folder name here' this is your toolchain. Now we have our toolchain and source all unpacked and ready to go, youll need to open Terminal or your prefered terminal app. This next bit will be much easier if you extracted everything in the explanation above. For the next set of instructions just change my user name with yours and if you did the same directories as me this should be simple.
Ok so in terminal cd to inside your kernel like this for expample:
cd /home/samno/Downloads/LGP920v21ESource/kernel
Dont get confused about the kernel directory inside the kernel folder you want to be at the base of the rest of the files.You should have the kernel directory open in file browser too. If you want you can type cd in terminal and then drag the folder in the top of the file manager and drag it into the terminal window where you typed cd, this will save you making typo's and be quicker/easier.
Next we need to set the export/path for our toolchain so in terminal enter this for example:
Code:
export CROSS_COMPILE=/home/samno/Downloads/arm-2010q1/bin/arm-none-linux-gnueabi-
Code:
export PATH=$PATH:/home/samno/Downloads/arm-2010q1/bin
Exporting the path isnt completely necessary but is useful if you want to compile other things than this. Now we should be ready to compile.
Compiling The zImage
First thing we will need to to is edit the makefile in the base directory. Open with gedit and add '+' to the 7 where it says EXTRAVERSION = .7. This will make the kernel compatible with the 21E modules such as wifi. If you are devoloping for sources without a '+' such as 20F you can leave this bit. You could also make your own modules if you wanted but i might cover that later. I dont do this cause it can cause compatibilty problems for people swapping kernel all the time, especially when the kernel they flash isnt compatible with the modules of another kernel for example my kernel uses stock modules found already in the roms we use where as iblue for example compiles and includes his own in the kernel package. If you flash one over another then the modules wont work with another kernel version.
Ok what we want to do next is fix the defconfig for our device or just use a different one in our case. This is located in the arch/arm/configs directory. This was a problem when devs first started compiling to find out when they flashed it they no signal and charging issues when the phone is off. Cause we are meant to use the cosmo_rev_1.11_defconfig but it had cricial lines missing. Only by me messing about did i discover that the lines needed were located in the cosmo_rev_1.11_mipi_defconfig.
So in terminal you should still be in the kernel directory, now enter this command:
Code:
make ARCH=arm cosmo_rev_1.11_mipi_defconfig zImage
Dont worry it come up with loads of stuff as it compiles but i will come to an error which we need to fix before it will continue. The good thing about the complier it will give you a good idea where to look like the file and error location.
So it should come up with something like this:
Code:
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/staging/omap_hsi/xmd-hsi-ll.o
In file included from drivers/staging/omap_hsi/xmd-hsi-ll.c:33:
drivers/staging/omap_hsi/xmd-hsi-ll-internal.h:256: error: expected specifier-qualifier-list before 'if'
drivers/staging/omap_hsi/xmd-hsi-ll-internal.h:434: error: #endif without #if
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_read_complete_cb':
drivers/staging/omap_hsi/xmd-hsi-ll.c:707: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:707: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:708: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:711: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:711: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:713: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:714: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:715: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:718: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:720: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:722: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:722: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:733: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:734: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:736: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c:737: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_check_channel':
drivers/staging/omap_hsi/xmd-hsi-ll.c:1476: error: operator '/' has no right operand
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_open':
drivers/staging/omap_hsi/xmd-hsi-ll.c:1642: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:1643: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:1644: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_reset':
drivers/staging/omap_hsi/xmd-hsi-ll.c:2725: error: 'struct hsi_ll_rx_ch' has no member named 'open_id'
drivers/staging/omap_hsi/xmd-hsi-ll.c:2726: error: 'struct hsi_ll_rx_ch' has no member named 'open_size'
drivers/staging/omap_hsi/xmd-hsi-ll.c:2727: error: 'struct hsi_ll_rx_ch' has no member named 'retry_cnt'
make[4]: *** [drivers/staging/omap_hsi/xmd-hsi-ll.o] Error 1
make[3]: *** [drivers/staging/omap_hsi] Error 2
make[2]: *** [drivers/staging] Error 2
make[1]: *** [drivers] Error 2
So lets go to the first error, line 256 of the xmd-hsi-ll-internal.h. Simply add # before 'if defined' like this '#if defined'. Save the file then go back to terminal and enter the make command or press up arrow and press enter. Youll notice alot of errors have gone when it errors out again and it should look like this:
Code:
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/staging/omap_hsi/xmd-hsi-ll.o
drivers/staging/omap_hsi/xmd-hsi-ll.c: In function 'hsi_ll_check_channel':
drivers/staging/omap_hsi/xmd-hsi-ll.c:1476: error: operator '/' has no right operand
make[4]: *** [drivers/staging/omap_hsi/xmd-hsi-ll.o] Error 1
make[3]: *** [drivers/staging/omap_hsi] Error 2
make[2]: *** [drivers/staging] Error 2
make[1]: *** [drivers] Error 2
make: *** [zImage] Error 2
Again fixing this error is like the first one, goto line 1476 of xmd-hsi-ll.c simply delete the '/' like this '#if 1' where it was '#if 1 /'. Save again then back to terminal again where it will you guessed it error out again. Should look like this;
Code:
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/staging/omap_hsi/xmd-hsi-ll.o
CC drivers/staging/omap_hsi/hsi_driver_if.o
drivers/staging/omap_hsi/hsi_driver_if.c: In function 'hsi_ioctl':
drivers/staging/omap_hsi/hsi_driver_if.c:930: error: 'HSI_IOCTL_SET_WAKE_RX_3WIRES_MODE' undeclared (first use in this function)
drivers/staging/omap_hsi/hsi_driver_if.c:930: error: (Each undeclared identifier is reported only once
drivers/staging/omap_hsi/hsi_driver_if.c:930: error: for each function it appears in.)
drivers/staging/omap_hsi/hsi_driver_if.c:945: error: 'HSI_IOCTL_SET_WAKE_RX_4WIRES_MODE' undeclared (first use in this function)
make[4]: *** [drivers/staging/omap_hsi/hsi_driver_if.o] Error 1
make[3]: *** [drivers/staging/omap_hsi] Error 2
make[2]: *** [drivers/staging] Error 2
make[1]: *** [drivers] Error 2
make: *** [zImage] Error 2
Fixing this one will be similar too. If you read the error its says this bit of code hasnt been declared for a function, most probably LG have missed some more code here for it to work or it was left over from testing the ghost call stuff. The only way to get rid of this error that i know of is to do away with the line completely. So go to line 930 of hsi_driver_if.c and delete 'case HSI_IOCTL_SET_WAKE_RX_3WIRES_MODE:' and the space that it leaves and do the same for 'case HSI_IOCTL_SET_WAKE_RX_4WIRES_MODE:'.
Do the make command again and thats it no more errors and it should look like this:
Code:
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy.gzip
AS arch/arm/boot/compressed/piggy.gzip.o
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
SHIPPED arch/arm/boot/compressed/lib1funcs.S
AS arch/arm/boot/compressed/lib1funcs.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Congratulations! Youve just compiled your first kernel.
Making Your RamDisk & Boot.img
Well done! Now we need to package your zImage up into a useable form. This part will be similar to Urabewe's guide here http://forum.xda-developers.com/showthread.php?t=1358717 , kudos to him for such an excellent guide, the only difference is were using our own zImage.Remember the backup you did earlier of your stock rom, were gonna need it again for this part. Firstly were gonna need to make sure we have got the tools to decompress/compress the boot.img. Again you will need a Linux distrubution like Ubuntu to be able to do this. So first off if you havnt got it already, we need to download the packaging tool using terminal. Enter the command as follows:
Code:
sudo apt-get install uboot-mkimage
Good now we need the perl script from the first post. Download and extract it to a folder and call it 'My1stKernel' for example. In this folder paste the boot.img from you stock backup. This will be used as our ramdisk base which we will work from. Now we need to unpack the boot.img but first we need to make sure were in the 'My1stKernel' directory so in terminal:
Code:
cd /home/samno/Downloads/My1stKernel
Then to unpack the kernel:
Code:
./unpack-bootimg.pl boot.img
When completed you will have a new directory inside named 'boot.img-ramdisk' & two gunzip compressed files, 'boot.img-kernel' is the stock zImage and 'boot.img-ramdisk.cpio.gz' is the stock ramdisk. The 'boot.img-ramdisk' contains the decompressed ramdisk contents. First thing to do now is delete 'boot.img-kernel' , 'boot.img-ramdisk.cpio.gz' & the old 'boot.img' since we only need the 'boot.img-ramdisk' cause were editing the ramdisk and using our own zImage. Now copy and paste the zImage you created earlier from the 'arch/arm/boot' directory of the kernel folder into 'My1stKernel' folder.
Now were gonna add some tweaks to the ramdisk to do this open the 'boot.img-ramdisk' folder and open the 'init.rc'.
First were gonna add a cpu variable for the screen off state, this helps save a bit of power.
Where the line says '# switch CPUfreq from performance to hotplug & tune it' add this underneath to keep the max frequency when screen is off to 300mhz:
Code:
write /sys/devices/system/cpu/cpu0/cpufreq/screen_off_max_freq 300000
Next were gonna add init.d support. So after these few lines in the init.rc:
Code:
service bootanim /system/bin/bootanimation
user graphics
group graphics
disabled
oneshot
Add this:
Code:
service userscript /system/bin/sh /sbin/initd.sh
user root
group system
critical
oneshot
This basically tells the system to load this file, which were gonna add next. Now save the file and start a new text document. In the document add this bit of text:
Code:
#!/system/bin/sh
if [ -d /system/etc/init.d ]
then
logwrapper busybox run-parts /system/etc/init.d
fi
sync
This is basically a script that runs the items in the init.d folder at boot so now save it as initd.sh in the sbin directory of your 'boot.img-ramdisk' folder. Youll notice the top command should turn blue, that means you have saved the file in the correct format. Good so now we should package all this up, but if you want you can add more mods to the init.rc like your memory management, more cpu controls, IO controls & lots of other stuff, anyway.
Making Your Boot.img
Almost there now guys! Let's package this up and enjoy the fruits of your labour. Assuming you still have your terminal window open in 'My1stKernel' directory type this command:
Code:
cd boot.img-ramdisk
Then this to compress the ramdisk:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Now in your 'My1stKernel' folder you will have a new gunzip archive named 'newramdisk.cpio.gz' this is the ramdisk you modified earlier. Now we need to bind it with your custom zImage to make a boot.img. So get terminal back up and go back to the previous directory:
Code:
cd /home/samno/Downloads/My1stKernel
Then enter this to combine them:
Code:
mkimage -A ARM -T multi -n newboot -C None -a 0x80008000 -e 0x80008000 -d zImage:newramdisk.cpio.gz boot.img
You should then have a lovely file named boot.img, simply just paste it into the flash package ive provided below for you then flash to your phone through CWR. Thats it, you & me we have come a long way, you should now have a rom and kernel you have made by yourself. Now lets party, unless it dosnt work just restore or flash another kernel . If you need any clarification or help just post in this thread and we can all help each other. Also would love to here your sucess stories if you used my guide and on a final note i want to thank everyone who's ever developed for this device and those who will cause youve helped me so much (even though you probably dont know ) through my entire time with this.

Changelog
To-Do
-Add Over Clocking/Frequency Instructions
-Add Voltage Changing Instructions
-Governors & IO Schedulers
Monday 30th July 2012
-Finished All Posts To A Finished Standard

Dev Bible!
From Pandaball 1 Verse's 1 & 2 http://forum.xda-developers.com/showpost.php?p=29185146&postcount=9
Just a few comments if I may:
I use 7zip over Winrar, it's a pretty badass alternative for something which is free.
Also, making a CWM backup isn't entirely necessary, you can do adb pull /system and the files will be pulled over to your adb directory. Saves you the trouble of extracting the nandroid backups. Normally I don't touch /data at all, just create /data/app and add the necessary lines in updater-script and you're good to go.
Some more tips:
Get the LG source code, it really tells you how Android works and all.
Linux is better than Windows for things like this. Both work fine, but Linux has the compilers and tools.
Test, test and test again. Make sure everything and everything works. Failure to do so (like I do sometimes ) will result in horrible things happening.
CWM's updater-script is a PITA. If there's an install script error, check your syntax. Did you forget a semicolon? A quotation mark? Did you ensure you used the correct command and parameters? If you really have to, weed out your updater-script down to the very basics and debug from there. Nice things such as ui_print are unnecessary until you're sure the basic functionality works.
Finally, doublecheck your permissions. Don't make everything 0777 (rwxrwxrwx) for no reason at all. Assign 0755 only when it's needed by the tweak, else 0644 will suffice. Also, things like su and busybox require special permissions like 4755 and 6755. If you don't assign these permissions, something's bound to break. Make sure your permissions are assigned correctly, else you have only yourself to blame when you bootloop your phone.
tl;dr it sucks to be a developer
Click to expand...
Click to collapse
From Pandaball 1 Verse 3 http://forum.xda-developers.com/showpost.php?p=29298911&postcount=12
Well, since there's an open invitation, might as well crash the how-to-dev party with some scripts you can use right off the bat. They are as attached, feel free to use them.They are a part of the tweaks I use for my rom. Noticeable improvements over stock this way, although they more or less deal with usability rather than performance so benchmarks might not improve as much as you'd expect. Dump them in /system/etc/init.d with permissions 0644 with a kernel that supports init.d (in other words, any custom kernel on this forum) and you're good to go.
However, since we're here, why not study how init.d works? Better to understand what these scripts do and how they impact performance, no?
Disclaimer: Some of these tweaks (like the one I'm going to explain below) were taken from the very awesome knzo (http://forum.xda-developers.com/show....php?t=1227269). However it has a ways to go in terms of explaining what the commands do so this post is entirely dedicated to that.
The scripts are very nicely named, giving you an idea of what they do. However, what do the strange numbers in front mean? Simply put, during bootup the kernel will run these scripts according to the numbers, so 65ZipAlign will run first, followed by 70Ext4Mount and so on.
Now, open 70Ext4Mount using notepad, notepad++, what have you. You'll see a bunch of variables and values, but at the start it is of paramount importance to add #!/system/bin/sh to the first line, else the script will not even execute as there is nothing defined to execute or write these values.
What do the values/commands do, you may ask.
tune2fs -o journal_data_writeback /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Let's analyse this command in sections.
tune2fs is just the code that runs the commands that follow after it.
-o journal_data_writeback tells tune2fs to write to the filesystem to enable journal data writeback. This typically provides the best ext4 filesystem performance.
/dev/block/mmcblk0p7 is the partition to apply the above commands to. In this case, mmcblk0p7 is /system.
Now, the other command is this
tune2fs -O ^has_journal /dev/block/mmcblk0p7
Click to expand...
Click to collapse
This time, the parameters are slightly different.
-O ^has_journal removes journaling, which is basically a filesystem log service. It takes up system resources, so removing journaling will improve system responsiveness. Note that -o and -O are different, the parameters are case-sensitive. -o configures the mount/filesystem options, -O enables/disables features.
Finally, at the bottom you get this line
busybox mount -o remount,noatime,noauto_da_alloc,nodiratime,barrier =0,nobh /system
Click to expand...
Click to collapse
As seen, the above is just a bunch of parameters. What do they all mean?
busybox mount -o mounts the partition named at the end, which is system. -o enables the mounting options.
remount, well, remounts the partition with the options named.
noatime disables the filesystem from writing the last accessed time to each file. When enabled, every read operation must have a write operation to write the last access time. With this option, only the read operations are done, removing the need for a write operation as well, giving a significant I/O boost.
noauto_da_alloc is a bit complex. When a file is edited in Linux, a new file is created containing the changes, then when it is saved, the new file is renamed and overwrites the old file. In ext3, it causes no problems since ext3 guarantees that either the old or new data will be on disk (when I say disk, it really means memory/eMMC) due to its default journaling mode. However, ext4 delays allocation, and thus the new file contents may not be written to disk before the file is renamed. Because of this, Linux kernels force the data to be written immediately which creates a performance hit. Disabling this will improve I/O by a bit. This may not be to everyone's liking since it creates the possibility of losing data, but such a thing has never happened to me. You can remove it if you like
nodiratime is the same as noatime, except this applies to directories being accessed rather than files.
barrier=0 disables the use of write barriers. Write barriers enforce proper on-disk ordering of journal commits, and is usually enabled due to possibility of data loss if power is lost. However because the O3D is a phone, it has a battery and this ensures data will not be lost as the system will not shut off abruptly due to power loss. Removing barriers gives a performance boost.
nobh makes the phone avoid assigning buffer heads. Similar effects to barrier=0, similar dangers.
/system selects the partition to remount.
That's all for 70Ext4Mount. Congrats, you now know how one of the init.d scripts work Now try figuring out the other 3. Google is your friend
This post is meant as a complement to samno's init.d mods, and only covers and explains a small section of what can be accomplished with init.d. I'll cover more when I find time
Click to expand...
Click to collapse

You are the man!!!!I was wondering will someone post something like this and i was to newbie to ask.Thank you good sir!
Sent from my LG-P920 using xda app-developers app

skilovan said:
You are the man!!!!I was wondering will someone post something like this and i was to newbie to ask.Thank you good sir!
Sent from my LG-P920 using xda app-developers app
Click to expand...
Click to collapse
I agree with you, I did notice things seemed pretty mellow here vs other forums, this'll be a great start for those of us that are picky and wanna combine and mess around with stuff. And i wasn't totally sure where to look for kernels and rom building so thanks this should make the community a little bigger. And i'm sure we'd end up providing some better support than lg lol

love it gj cant wait for the custom kernel section cuz thats what i am interested in is building my own kernel

Just a few comments if I may:
I use 7zip over Winrar, it's a pretty badass alternative for something which is free.
Also, making a CWM backup isn't entirely necessary, you can do adb pull /system and the files will be pulled over to your adb directory. Saves you the trouble of extracting the nandroid backups. Normally I don't touch /data at all, just create /data/app and add the necessary lines in updater-script and you're good to go.
Some more tips:
Get the LG source code, it really tells you how Android works and all.
Linux is better than Windows for things like this. Both work fine, but Linux has the compilers and tools.
Test, test and test again. Make sure everything and everything works. Failure to do so (like I do sometimes ) will result in horrible things happening.
CWM's updater-script is a PITA. If there's an install script error, check your syntax. Did you forget a semicolon? A quotation mark? Did you ensure you used the correct command and parameters? If you really have to, weed out your updater-script down to the very basics and debug from there. Nice things such as ui_print are unnecessary until you're sure the basic functionality works.
Finally, doublecheck your permissions. Don't make everything 0777 (rwxrwxrwx) for no reason at all. Assign 0755 only when it's needed by the tweak, else 0644 will suffice. Also, things like su and busybox require special permissions like 4755 and 6755. If you don't assign these permissions, something's bound to break. Make sure your permissions are assigned correctly, else you have only yourself to blame when you bootloop your phone.
tl;dr it sucks to be a developer

the aroma installer is great addon for roms
but it needs some time to add it to roms...
Sent from my LG-P920 using Tapatalk

Getting There
Almost done guys but been busy setting up my old laptop so i can take my stuff to work and work on it in my break, which will be good ics comes out i will be able to jump straight on it.
Toolchain link fixed and most of the kernel bits done. You could use the rest of another boot.img guide for now if you cant wait for mine.
Also are there any other dev's willing to contribute to my bible post. I would be grateful and it would be more of a community thing then. Any tips tricks, links, dev related story's or something to push the development on in here.

Well, since there's an open invitation, might as well crash the how-to-dev party with some scripts you can use right off the bat. They are as attached, feel free to use them.They are a part of the tweaks I use for my rom. Noticeable improvements over stock this way, although they more or less deal with usability rather than performance so benchmarks might not improve as much as you'd expect. Dump them in /system/etc/init.d with permissions 0644 with a kernel that supports init.d (in other words, any custom kernel on this forum) and you're good to go.
However, since we're here, why not study how init.d works? Better to understand what these scripts do and how they impact performance, no?
Disclaimer: Some of these tweaks (like the one I'm going to explain below) were taken from the very awesome knzo (http://forum.xda-developers.com/showthread.php?t=1227269). However it has a ways to go in terms of explaining what the commands do so this post is entirely dedicated to that.
The scripts are very nicely named, giving you an idea of what they do. However, what do the strange numbers in front mean? Simply put, during bootup the kernel will run these scripts according to the numbers, so 65ZipAlign will run first, followed by 70Ext4Mount and so on.
Now, open 70Ext4Mount using notepad, notepad++, what have you. You'll see a bunch of variables and values, but at the start it is of paramount importance to add #!/system/bin/sh to the first line, else the script will not even execute as there is nothing defined to execute or write these values.
What do the values/commands do, you may ask.
tune2fs -o journal_data_writeback /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Let's analyse this command in sections.
tune2fs is just the code that runs the commands that follow after it.
-o journal_data_writeback tells tune2fs to write to the filesystem to enable journal data writeback. This typically provides the best ext4 filesystem performance.
/dev/block/mmcblk0p7 is the partition to apply the above commands to. In this case, mmcblk0p7 is /system.
Now, the other command is this
tune2fs -O ^has_journal /dev/block/mmcblk0p7
Click to expand...
Click to collapse
This time, the parameters are slightly different.
-O ^has_journal removes journaling, which is basically a filesystem log service. It takes up system resources, so removing journaling will improve system responsiveness. Note that -o and -O are different, the parameters are case-sensitive. -o configures the mount/filesystem options, -O enables/disables features.
Finally, at the bottom you get this line
busybox mount -o remount,noatime,noauto_da_alloc,nodiratime,barrier=0,nobh /system
Click to expand...
Click to collapse
As seen, the above is just a bunch of parameters. What do they all mean?
busybox mount -o mounts the partition named at the end, which is system. -o enables the mounting options.
remount, well, remounts the partition with the options named.
noatime disables the filesystem from writing the last accessed time to each file. When enabled, every read operation must have a write operation to write the last access time. With this option, only the read operations are done, removing the need for a write operation as well, giving a significant I/O boost.
noauto_da_alloc is a bit complex. When a file is edited in Linux, a new file is created containing the changes, then when it is saved, the new file is renamed and overwrites the old file. In ext3, it causes no problems since ext3 guarantees that either the old or new data will be on disk (when I say disk, it really means memory/eMMC) due to its default journaling mode. However, ext4 delays allocation, and thus the new file contents may not be written to disk before the file is renamed. Because of this, Linux kernels force the data to be written immediately which creates a performance hit. Disabling this will improve I/O by a bit. This may not be to everyone's liking since it creates the possibility of losing data, but such a thing has never happened to me. You can remove it if you like
nodiratime is the same as noatime, except this applies to directories being accessed rather than files.
barrier=0 disables the use of write barriers. Write barriers enforce proper on-disk ordering of journal commits, and is usually enabled due to possibility of data loss if power is lost. However because the O3D is a phone, it has a battery and this ensures data will not be lost as the system will not shut off abruptly due to power loss. Removing barriers gives a performance boost.
nobh makes the phone avoid assigning buffer heads. Similar effects to barrier=0, similar dangers.
/system selects the partition to remount.
That's all for 70Ext4Mount. Congrats, you now know how one of the init.d scripts work Now try figuring out the other 3. Google is your friend
This post is meant as a complement to samno's init.d mods, and only covers and explains a small section of what can be accomplished with init.d. I'll cover more when I find time
As always, props to samno for having such a thread. I must say, I haven't seen many forums where devs band together to impart to the community what we know
samno - feel free to copy the contents of this post into the OP(s) if you want to.

hi samno thanks for the tutorial but if I want to compile the kernel i get this error:
[email protected]:~/Downloads/LGP920(Optimus_3d)_Android_Gingerbread_LGP920v21e/kernel$ make ARCH=arm cosmo_rev_1.11_mipi_defconfig zImage
/bin/sh: Syntax error: "(" unexpected
make: *** [cosmo_rev_1.11_mipi_defconfig] error 2
[email protected]:~/Downloads/LGP920(Optimus_3d)_Android_Gingerbread_LGP920v21e/kernel$
Click to expand...
Click to collapse
I tried it with root to but the same error.
I hope it isn't a too silly fail and I didn't forget something.
greets berni

Sorry berni the syntax error is because of the _'s & ()'s in the directory name, rename it to something similar but without them example LGP920v21ESource. I will amend the op forgot about this since i set mine up a while ago.
Thank you very much panda i will add i to the bible Pandaball verse 3.

Just requested the kernel source code for v20c Rogers and lg will get it to me in a couple days and once I get some time I wanna build a customer kernel from it so I can use all your guys great roms and keep my 4G data

i'm not sure if I'm the only one who gets errors like this:
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
/bin/sh: /home/bernhard/Downloads/arm-2010q1/bin/arm-none-linux-gnueabinm: not found
No valid symbol.
make[1]: *** [.tmp_kallsyms1.S] Error 1
make: *** [zImage] Error 2
Click to expand...
Click to collapse
but it is easy to fix just rename the
/home/bernhard/Downloads/arm-2010q1/bin/arm-none-linux-gnueabi-nm
to arm-none-linux-gnueabinm
after fixing this it was no problem to
make the zImage
thanks again for this guide!!
---------- Post added at 08:13 PM ---------- Previous post was at 07:52 PM ----------
I just wanted to add some stuff to this guide :
after you compiled your zImage you want to
test it but how?
Parts of this are taken from Urabewe guide so credits are going to him
first run this in terminal :
sudo apt-get install uboot-mkimage
then you have to unpack a working boot.img
with this script (link by samno):
http://forum.xda-developers.com/attachment.php?attachmentid=1215193&d=1342992085
unpack it and put it in the same folder of boot.img
cd to this folder in terminal
run in terminal
./unpack-bootimg.pl boot.img
you should now have a directory called boot.img-ramdisk
here you can add some tweaks if you want.
If you change some things in the ramdisk you have to do this:
go in this directory with terminaal and run
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
cd back to the folder within the boot.img and the other stuff
Click to expand...
Click to collapse
place now your zImage in that folder and run
mkimage -A ARM -T multi -n NAME YOUR IMAGE -C None -a 0x80008000 -e 0x80008000 -d zImage:newramdisk.cpio.gz newboot.img
now you shold have a file called newboot.img just put it in a zip
and flash it from cwm but make a backup to restore the boot partition
if something wents wrong
hope i did not forget any credits or steps
greets berni

Excelent samno! Bravo!
You're the best.

Yaaay!
Just to let you know guy's ive finished the guide, please tell me if you see anything wrong or you think i should change. Good luck to those who try it out too.
Also has anyone else got/know anything i could/should add to this?

great work sir !!!
u gave an inspiration to young developers..
hatts off

I wonder why the export command sometimes doesn't do :/
I had to copy the files contained in arm2010-1 into /usr to get it working with CROSS_COMPILE=arm-none-linux-gnueabi
Without this was starting the arm-linux-gnueabi already installed in ubuntu which gives errors..
Anyway i'm doing experiments with sources and kernels here.. i feel like a mad compiler doing my "frankenstein" kernel..

[SCRIPTS] ROM, kernel, anykernel updater and Environment-setup scripts

Hey guys
I've been working on some scripts to automate my work for quite some time now and thought, why not share it?
So that's what I'm gonna do now
For now, we have three scripts: one to build a ROM, one to compile a kernel, to make an anykernel updater zip and to set up and entire build environment on Arch and Ubuntu-based distros (2nd post). The kernel and anykernel scripts, however, are linked, which means the kernel script automatically executes the anykernel script so as soon as you compile a kernel, you get a recovery flashable zip.
A small note: These scripts were made for the LG Optimus 4x HD, but can easily be modified for any other device.
So, you may ask yourself now 'nice, but what do these script do exactly?' well, that's what I'm gonna tell you now
ROM
The ROM build script can be found HERE
This script is made for CM 11, but can be easily modded to be used with other ROMs. I will also add some more scripts to support more ROMs in the future.
In order to make it compatible with your machine and your device, we have several configurable parameters in the beginning of the script:
Code:
# Configurable parameters
ccache_dir=/home/laufersteppenwolf/ccache/CM11
ccache_log=/home/laufersteppenwolf/ccache/CM11/ccache.log
jobs_sync=30
jobs_build=20
rom=cm
rom_version=11
device_codename=p880
If you want to use a special ccache dir, you can define it using the first parameter. Same for ccache's log.
The "jobs_sync" variable defines how many jobs will be running at the same time while running "repo sync" (---> the -j value)
The "jobs_build" variable defines how many jobs will be used for the make command
"rom" defines the ROM you are trying to compile (used in the lunch command, but also for the zip upload command)
"rom_version" defines the version of the ROM. You can change it to 10.2 or any other version depending on the CM version you are compiling.
Last but not least, the devices codename. In my case it's "p880", but you can just change it to your device (mako, hammerhead, maguro,...) and the lunch as well as the upload command will be changed to your device.
About the upload, if you have a goo.im account and also configured it in your ssh_config, you can just leave it the way it is. However, if you use a different file hoster, please edit the last command to your needs
Furthermore, we have some more features. These, however, don't need to be defined inside the script, but added to the execution command.
You can execute the script with the command:
Code:
. build.sh [-h -n -r -c -ncc -d -j #]
But what do these flags do?
Code:
-h | --help
shows a help message and exits the script
Code:
-n | --nosync
skips the "repo sync" command
Code:
-r | --release
uploads the build when it's done
Code:
-c | --clean
executes "make clean" instead of "make installclean"
Code:
-ncc | --no_ccache
disables ccache
Code:
-d | --debug
shows some debug stuff (not really needed for the "normal" user )
Code:
-j #
sets a custom number of jobs for the "make" command
Example:
Code:
. build.sh -c -r
This command syncs the repos, executes "make clean" instead of "make installclean" and uploads the build to the defined file hoster as soon as the build is done.
Kernel
The kernel build script can be found HERE
This script is made for the p880 (aka x3), but can be easily modded to work with your device.
We have 2 configurable parameters in the beginning of the script:
Code:
defconfig=cyanogenmod_x3_defconfig
jobs=32
"defconfig" defines the name of your defconfig to be used
And "jobs" defines the -j value to be used for make
All modules are being copied to ./out/modules/ and the zImage is being copied to ./out/zImage. Which means no more searching for modules inside the various folders, but having everything in one place
If you take a look into the script, the created out dir is after the above command copied to "~/smb/kernel/out". This is where my network drive is mounted. Please change it to a path of your choice.
This folder now needs to have the files from the anykernel folder inside, because the anykernel build script is being executed next. What this script exactly does will be explained later.
When the anykernel updater zip is done, the script cd's back to the place it was initially executed and will then be done.
If you don't want to make an anykernel zip, just remove the commands after
Code:
find -name '*.ko' | xargs -I {} cp {} ./out/modules/
(well, maybe except for the commands that tell you the script it done )
Anykernel updater zip
Wanna know what an anykernel updater zip is?
The anykernel updater zip only replaces the actual kernel (zImage) and not the whole boot.img. This means the ramdisk stays the same, which makes the kernel compatible with every ROM and Android version.
The script and it's needed tools can be found HERE
This script creates an anykernel updater zip from a given zImage and modules. The zImage has to be in the same folder as the script itself. The modules have to be in a folder called "modules", which also should be located in the same folder as the script. In the beginning of the script, you can define the name of the zip:
Code:
zipname="WWJB_v009_anykernel.zip"
IMPORTANT:
Please make sure to edit the updater-script so it is compatible with your device! Otherwise you can (hard) brick your device!
I am not responsible for possibly bricked devices!
Another feature of the anykernel updater is, you can mod the ramdisk while flashing (repacking the boot.img). This can be done inside THIS file. By default it creates an unsecured boot image. But you can edit way, way more using this method. For an example what can be done, you might wanna take a look at THIS file
The signapk.jar and the sign keys were taken from the latest CM11 sources.
You have a question, suggestion, bug report? Please feel free to leave a reply in this thread
Many thanks go to @GermainZ and @doixanh for helping me fighting with bash
Thanks also go to Koush, for "inventing" the anykernel updater

Environment setup script
Who is bored of setting up an entire build environment for Android? I certainly am, which is why I wrote this "tiny" script
This script sets up a complete build environment, so you can directly start to repo sync a ROM after the script is done. And the best thing is, it is extremely customizable without even having to edit the script itself. All done by appending the appropriate flags to the executing command.
A further big advantage of this script is, that it is compatible with the two most common Linux distros Arch Linux and Ubuntu (also including all distros that are based on these 2, like Xubuntu, Lubuntu,....). This compatibility is achieved by detecting the distro in the beginning of the script and then using the appropriate commands (apt-get or pacman).
The script is located HERE and called "setup.sh"
To run the script, cd to the folder the script is located and enter ". setup.sh" and append all desired flags. If you need help, just append the "-h" or "--help" flag and some help will be shown.
So, you may ask yourself now "That's nice, but what the hell does this script install/set up?" and the answer is quite simple: All you need, and (if desired) even more
The "base package" includes:
Ccache
Java
GIT
All needed build tools
Python 2
The Android SDK
Furthermore, you can also choose the "extended package" by appending the flag "-e" or "--extended", which includes:
SSH
iostat
bmon
htop
geany
The dev-host commandline tool by GermainZ
udev-rules (on Arch only)
If this still isn't enough for you, you can also add your own packages. This can be done by either editing the script and entering the packages inside the quotes of the following line:
Code:
extra="" # Add here some extra packages to install
OR
by appending the flag "-s" or "--special" and then listing the packages within quotes, seperated by spaces.
Example:
Code:
. setup.sh -s "package1 package2 package3"
This script is made to perform all actions on its own, however, it will not do so by default. To have it automated, you need to append either "-a" or "--automated". The script will then install the "base package" with all default packages (such as Oracle's JDK 6).
But you can still also append the other flags, like "-e", "-s", "-j",...
Now, let's talk about Java. This script can install 3 Java versions: Oracle's JDK 6, openJDK 6 and openJDK 7. The default version is Oracle's JDK 6. You can change the version by either appending the "-j" or "--java" flag followed by the desired version (1, 2 or 3), or if the -a flag isn't triggered, the script will ask you about it.
What? You don't want to install/change java at all? No problem! Just append "--no-java" and Java will get completely skipped.
The same thing also happens to the SDK when appending "--no-sdk".
The script has been tested on (X)ubuntu 13.10 and 14.04 by @nilse and me, and on Arch Linux by @SMillerNL and me. However, I have only tested Oracle's JDK 6, no other java versions but according to the wiki pages, it should work just fine
You have suggestions, feedback, improvements? Shoot! Just let me know and I'll do my best to include it
A big thanks goes to my testers @nilse and @SMillerNL who also made some nice suggestions. But also to @GermainZ for his dev-host commandline tool
Furthermore to @eagleeyetom for giving me the idea

Thanks awesome work it will be helpfull i was looking for such thing yesterday XD you're best @laufersteppenwolf

The anykernel script doesn't work on newer devices with zImage-dtb right?
Doesn't look like it based on the script, but I've had trouble with the M8 DTB so figured I'd ask.

u saved my life thanks buddy i will try it !!!

Hi
Fits ics?

xboxfanj said:
The anykernel script doesn't work on newer devices with zImage-dtb right?
Doesn't look like it based on the script, but I've had trouble with the M8 DTB so figured I'd ask.
Click to expand...
Click to collapse
To be honest, I have no idea
I have only tested it on the 4x HD myself, but if you use all the same commands as the the ROM build process does (maybe also grab the needed files) it should work. I mean, it does exactly the same thing as when the ROM build packs the boot image, it puts the zImage and ramdisk into one file. Only anykernel does this on the device itself, rather than on your PC.
If you want, we can take a look into it together
Marília de Oliveira said:
Fits ics?
Click to expand...
Click to collapse
Sure, should work with all ROMs, just edit some stuff (like rom_version=11 to rom_version=9 when compiling CM) and it should work just fine

laufersteppenwolf said:
To be honest, I have no idea
I have only tested it on the 4x HD myself, but if you use all the same commands as the the ROM build process does (maybe also grab the needed files) it should work. I mean, it does exactly the same thing as when the ROM build packs the boot image, it puts the zImage and ramdisk into one file. Only anykernel does this on the device itself, rather than on your PC.
If you want, we can take a look into it together
Sure, should work with all ROMs, just edit some stuff (like rom_version=11 to rom_version=9 when compiling CM) and it should work just fine
Click to expand...
Click to collapse
How do I edit? Can you explain me better .. Thanks

Thanks a lot @lauferstppenwolf
Really takes the stress out of executing commands during my kernel compiles.

Marília de Oliveira said:
How do I edit? Can you explain me better .. Thanks
Click to expand...
Click to collapse
open in notepad or gedit or whatever and edit what u want
BTW does -j number of jobs should be for example "-j6" or "-j 6"?

Marília de Oliveira said:
How do I edit? Can you explain me better .. Thanks
Click to expand...
Click to collapse
It's quite simple, open the script with an editor (I personally like Geany) and edit the following lines:
Code:
ccache_dir=/home/laufersteppenwolf/ccache/CM11
ccache_log=/home/laufersteppenwolf/ccache/CM11/ccache.log
jobs_sync=30
jobs_build=20
rom=cm
rom_version=11
device_codename=p880
example:
You want to compile CM9 for the Nexus 5 (codename hammerhead) on a dual core CPU and your username (on your PC) is username:
Code:
ccache_dir=/home/[COLOR="Red"]username[/COLOR]/ccache/CM11
ccache_log=/home/[COLOR="red"]username[/COLOR]/ccache/CM11/ccache.log
jobs_sync=[COLOR="red"]5[/COLOR]
jobs_build=[COLOR="red"]3[/COLOR]
rom=cm
rom_version=[COLOR="red"]9[/COLOR]
device_codename=[COLOR="red"]hammerhead[/COLOR]
and you're already done Your script can now compile CM9 for the Nexus 5

laufersteppenwolf said:
It's quite simple, open the script with an editor (I personally like Geany) and edit the following lines:
Code:
ccache_dir=/home/laufersteppenwolf/ccache/CM11
ccache_log=/home/laufersteppenwolf/ccache/CM11/ccache.log
jobs_sync=30
jobs_build=20
rom=cm
rom_version=11
device_codename=p880
example:
You want to compile CM9 for the Nexus 5 (codename hammerhead) on a dual core CPU and your username (on your PC) is username:
Code:
ccache_dir=/home/[COLOR="Red"]username[/COLOR]/ccache/CM11
ccache_log=/home/[COLOR="red"]username[/COLOR]/ccache/CM11/ccache.log
jobs_sync=[COLOR="red"]5[/COLOR]
jobs_build=[COLOR="red"]3[/COLOR]
rom=cm
rom_version=[COLOR="red"]9[/COLOR]
device_codename=[COLOR="red"]hammerhead[/COLOR]
and you're already done Your script can now compile CM9 for the Nexus 5
Click to expand...
Click to collapse
I have done everything ... where else do I put the script?

Marília de Oliveira said:
I have done everything ... where else do I put the script?
Click to expand...
Click to collapse
just put it inside the root of your sources (the place where you have initiated the repo) and then run it using ". build.sh [flags]"

laufersteppenwolf said:
just put it inside the root of your sources (the place where you have initiated the repo) and then run it using ". build.sh [flags]"
Click to expand...
Click to collapse
Thanks ... Worked in xperia mini pro with ics :good:

gerciolisz said:
open in notepad or gedit or whatever and edit what u want
BTW does -j number of jobs should be for example "-j6" or "-j 6"?
Click to expand...
Click to collapse
Sry for the late reply, haven't seen it at all
it's "-j x", as it only listens to the things behind the actual flag

laufersteppenwolf said:
Sry for the late reply, haven't seen it at all
it's "-j x", as it only listens to the things behind the actual flag
Click to expand...
Click to collapse
thx after reading that script i know now i thought it is same like brunch/lunch -jx

Alright guys, a big update just found its way to github: a script to set up a complete build environment on Ubuntu and Arch-based distros.
If you want me to add support for another distro, please contact me either via PM or via IRC (#TeamFun or #p880-dev) and give me details on what must be changed (install command, packages, ...)
Also the kernel script got some updates, to abort the script if the kernel didn't compile and to copy the anykernel zip directly to dropbox to share it with your testers
Cheers

laufersteppenwolf said:
You want to compile CM9 for the Nexus 5 (codename hammerhead) on a dual core CPU and your username (on your PC) is username:
Code:
ccache_dir=/home/[COLOR="Red"]username[/COLOR]/ccache/CM11
ccache_log=/home/[COLOR="red"]username[/COLOR]/ccache/CM11/ccache.log
jobs_sync=[COLOR="red"]5[/COLOR]
jobs_build=[COLOR="red"]3[/COLOR]
rom=cm
rom_version=[COLOR="red"]9[/COLOR]
device_codename=[COLOR="red"]hammerhead[/COLOR]
Click to expand...
Click to collapse
couldnt you make the script universal by using $HOME?

Wow! Great job and well written... I'll be trying this on my old archserver box that I thought I would have to convert to Ubuntu because I couldn't get all the required packages configured correctly. Looking over your scripts you've touched it all!

Thanks a bunch for the scripts, especially the env-setup one. I'll test it one of these days in Manjaro.
However, env-setup/setup.sh has a small bug: after running the script in LM16 (build environment already set up) it wants to reinstall Java no matter which flag is given.
Also, it doesn't detect installed SDK for some reason.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Scriptor - perm2metadata, metadata2perm, updater-script checker/converter

Scriptor is a utillity i build to convert an upater-script from metadata to perm, from perm to metadata, to simultaneously swap the syntax, and to check against files not found
here's the usage
Code:
Usage: scriptor -p/m/s/c [inputfile] [outputfile/checkdir]
-p convert to set_perm syntax
-m convert to set_metadata syntax
-s convert metadata to perm and perm to metadata
-c check script for errors against filesystem
-b build updater-script from #not implemented yet#
[inputfile] input updater-script filename
[outputfile/checkdir] output file or if checking for errors input directory to root of rom
DOWNLOAD1.78kb
your welcome
XDA:DevDB Information
Scriptor, Tool/Utility for all devices (see above for details)
Contributors
Ricky Divjakovski
Version Information
Status: Testing
Created 2015-10-20
Last Updated 2015-10-19

Great
That is a thing which I need
Thank you hehe
Sent from my Nexus 5 using Tapatalk

Enjoy, this is only a beta version but works fine as far as i know
ill be adding EOL conversion in the next update and make it a commandline tool
then gonna add a few more things like convert it to simplyfy language( a language im writing to simplify reading updater-scripts, im almost done to be honest and its much easier to read, gonna compile update-binary to support the language aswell and a few more options to it like deodexing, but that wont be for a while
also gonna add a debloating utillity and an option to activate/deactivate aroma from the script itself

The edify2simplyfy converter is almost ready

could you please give an example on how to use that script to convert perm to metadata, and thanks in advance

yakie47 said:
could you please give an example on how to use that script to convert perm to metadata, and thanks in advance
Click to expand...
Click to collapse
scriptor -m updater-script new-updater-script

thank you man, but i'm getting this error: echo. was unexpected at this time.

yakie47 said:
thank you man, but i'm getting this error: echo. was unexpected at this time.
Click to expand...
Click to collapse
ill look into it mate thanks for feedback
edit: i got that error too on windows 8.1, ill fix and re-upload V2

Updater Sript Converter
I have also build a tool that will covert the updater-script to support lower version cwm and twrp. CWM version less than 5 and TWRP version less than 3 will support the script. This tool converts all set_metadata and set_metadata_recursive to set_perm and set_perm_recursive respectively and remove 5th argument from mount.
Tool is made of javascript so can be run in any html5 supported browser like firefox, chrome and in any OS like windows, mac, linux, android, iphone. Fully OS independent.
Just download the zip file attached below and extract. Then click and open index.html file in your browser. Dont forget to use the update-binary linked in that page. Tool can also be surfed online visit http://minify.cf/usc
100% working and tested.​

aniruddhabag3 said:
I have also build a tool that will covert the updater-script to support lower version cwm and twrp. CWM version less than 5 and TWRP version less than 3 will support the script. This tool converts all set_metadata and set_metadata_recursive to set_perm and set_perm_recursive respectively and remove 5th argument from mount.
Tool is made of javascript so can be run in any html5 supported browser like firefox, chrome and in any OS like windows, mac, linux, android, iphone. Fully OS independent.
Just download the zip file attached below and extract. Then click and open index.html file in your browser. Dont forget to use the update-binary linked in that page. Tool can also be surfed online visit http://minify.cf/usc
100% working and tested.​
Click to expand...
Click to collapse
please do not post your software in the comments section of my work, make a new thread for your tool dont clutter mine with crap

Ricky Divjakovski said:
please do not post your software in the comments section of my work, make a new thread for your tool dont clutter mine with crap
Click to expand...
Click to collapse
Ok sorry. I am new here.

@Ricky Divjakovski
Is there any chance for /system/bin script?

HemanthJabalpuri said:
@Ricky Divjakovski
Is there any chance for /system/bin script?
Click to expand...
Click to collapse
This is long obsolete, i didnt have the time to maintain it or turn it into a console application

[DEV][PROOF OF CONCEPT] APK-Patcher - Easily Mod APKs from Recovery [Flashable Zip]

APK-Patcher -- Flashable Zip Template for Modifying System APKs On-Device from Recovery
APK modification can be a tedious task. If you want to provide modified APKs you copy it to PC to decompile using Java applets like baksmali and apktool, make changes and recompile using another Java applet, smali (or apktool again). Then there's the pitfall of different recompiled APKs being required for the various different ROMs, etc., not to mention across Android versions. So, considering Android runs a version of Java runtime and the primary tools are Java-based I wondered why we couldn't do all of this on-device and on-the-fly so modifications could be applied via recovery, to whatever ROM APK was present, and take the constant update burden off of the modification creator.
I have taken these commandline Java applets, dexed them to allow them to run on-device, and found/built static ARM compiles of zip, zipalign and aapt to run on the various Android versions and devices. These binaries would need to be recompiled for other architecture support. The zip is smart and automated, using the APK name to run all the various parts involved for complicated patches and is extensible to any number of APKs in a single zip. The modification creator needs to only add the APK name(s) to a list, figure out how to make the changes universally (i.e. sed, awk, etc.) then add the commands to scripts of the same name, and add any whole-file additions/changes in subdirectories of the same name.
A proof-of-concept working script automating the long known Facebook Contacts Sync modifications to ContactsProvider.apk is included for reference.
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/APK-Patcher/
Status: No Longer Updated
Instructions
1a) Place any required script to alter the decompiled APK classes.dex smali files in /script as a -smali.sh file with the name of the APK
-b) Place any required/additional updated whole smali files in /patch under the name of the APK with "-smali" and the relative path within the classes.dex file (including com)
2a) Place any required script to alter the decoded APK resources.asrc files in /script as a -res.sh file with the name of the APK
-b) Place any required/additional updated whole resource files in /patch under the name of the APK with "-res" and the relative path within the zip/resources.asrc file (including res)
3) Modify the envvar.sh to add your banner, apklist, backup and cleanup options
4) Modify the extracmd.sh to add any additional commands to be performed at the end of the patching process that aren't patch-related (/data file changes, etc.)
5) zip -r9 UPDATE-APK-Patcher.zip * -x README UPDATE-APK-Patcher.zip
As a general rule, whole-file adding is best used only for including a file that doesn't already exist, and the more surgical script-work should be used to keep things more universal.
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]
Enjoy!
Questions, comments and feedback welcome.
Credits & Thanks: JesusFreke for bak/smali, iBotPeaches for apktool, Surge1223 for help working out how to build zipalign and aapt, and all authors of the included binaries and those who ported them over for their amazing work.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.

Script/Patch Reference
Properties / Variables (envvar.sh)
Code:
banner="Facebook Contacts Sync Enabler";
apklist="ContactsProvider.apk";
apkbak=/data/media/APK-Backup;
backup=1;
cleanup=1;
banner is the name of your patch zip, usually suggestive of what it does, to be displayed at the beginning of the zip flash. You should include your name/handle here like "by osm0sis @ xda-developers" for credit purposes.
apklist is a string containing the list of APKs to be patched included in the patch zip, separated by spaces between the quotes. Each APK is automatically found recursively in /system, then copied to the working directory to be decompiled and acted on, then copied back to /system.
apkbak is the location to place backups of the untouched APKs in apklist if backup=1 is set.
backup=1 will store backups of the untouched APKs in the location specified in apkbak.
cleanup=0 will keep the zip from removing it's working directory in /tmp/apkpatcher or any of the files resulting from the smali process - this can be useful if trying to debug in adb shell whether the patches worked correctly. cleanup=1 is necessary on multi-APK patching zips to clean the baksmali classout directory for the next APK, so it's recommended each APK to be patched be tested on their own with cleanup=0 before combining into a single zip.

osm0sis said:
Properties / Variables (envvar.sh)
Code:
banner="Facebook Contacts Sync Enabler";
apklist="ContactsProvider.apk";
apkbak=/data/media/APK-Backup;
backup=1;
cleanup=1;
banner is the name of your patch zip, usually suggestive of what it does, to be displayed at the beginning of the zip flash. You should include your name/handle here like "by osm0sis @ xda-developers" for credit purposes.
apklist is a string containing the list of APKs to be patched included in the patch zip, separated by spaces between the quotes. Each APK is automatically found recursively in /system, then copied to the working directory to be decompiled and acted on, then copied back to /system.
apkbak is the location to place backups of the untouched APKs in apklist if backup=1 is set.
backup=1 will store backups of the untouched APKs in the location specified in apkbak.
cleanup=0 will keep the zip from removing it's working directory in /tmp/apkpatcher or any of the files resulting from the smali process - this can be useful if trying to debug in adb shell whether the patches worked correctly. cleanup=1 is necessary on multi-APK patching zips to clean the baksmali classout directory for the next APK, so it's recommended each APK to be patched be tested on their own with cleanup=0 before combining into a single zip.
Click to expand...
Click to collapse
Did you happen to figure out how to cross compile jdk for arm? (different from the arm sources available from oracle etc)
..and nice work!

Surge1223 said:
Did you happen to figure out how to cross compile jdk for arm? (different from the arm sources available from oracle etc)
..and nice work!
Click to expand...
Click to collapse
Nah, just forced bak/smali and apktool to run by building/adding classes.dex for each of them and figuring out how to call a functional dalvikvm from recovery.
The first part was mentioned in passing (and quite awesomely) by JesusFreke back in 2011.
That got it running in booted Android. Then running from recovery was a whole other issue, but I stumbled upon Jim Huang's work on executing dalvikvm on Linux, and that lead me to figuring out a solution.
As it stands, apktool should technically be able to do both the classes and resources parts of things (since it incorporates baksmali and smali), but for some reason it bails in recovery on decompiling the classes.dex where baksmali standalone doesn't. So perhaps in future revisions apktool could be the only jar required.
Similarly, apktool also bails when rebuilding resources.asrc because it can't call its internal(?) aapt, so I've included aapt compiled as PIE since that's the only working one I could find; in the future this could go too if apktool resolves it, or at the very least it would be more universal if we had a static compile of aapt to go with the other static binaries included.
Other possible items on the to-do list would include adding zip re-signing (currently it uses the apktool /system APK trick of keeping META-INF the same), reflashing to revert to the backup APKs, and adding busybox to always have an expected execution environment like I recently did on AnyKernel2 to work around Cyanogen Recovery and toybox missing basic stuff like awk at the moment. These aren't something I'm going to be actively working on since it works and APK modding isn't really a focus for me, but since I figured out how to automate the process I wanted to provide the WIP template for the modding community. :good:

osm0sis said:
Nah, just forced bak/smali and apktool to run by building/adding classes.dex for each of them and figuring out how to call a functional dalvikvm from recovery.
The first part was mentioned in passing (and quite awesomely) by JesusFreke back in 2011:
http://forum.xda-developers.com/showpost.php?p=10424700&postcount=2
That got it running in booted Android. Then running from recovery was a whole other issue, but I stumbled upon Jim Huang's work on executing dalvikvm on Linux, and that lead me to figuring out a solution.
As it stands, apktool should technically be able to do both the classes and resources parts of things (since it incorporates baksmali and smali), but for some reason it bails in recovery on decompiling the classes.dex where baksmali standalone doesn't. So perhaps in future revisions apktool could be the only jar required.
Similarly, apktool bails when rebuilding resources.asrc because it can't call its internal(?) aapt, so I've included aapt compiled as PIE since that's the only working one I could find; in the future this could go too if apktool resolves it or at the very least it would be more universal if we had a static compile of aapt to go with the other static binaries included.
Other possible items on the to-do list would include adding zip re-signing (currently it uses the apktool /system APK trick of keeping META-INF the same), and adding busybox to always have an expected execution environment like I recently did on AnyKernel2 to work around Cyanogen Recovery and toybox missing basic stuff like awk. These aren't something I'm going to be actively working on since it works and APK modding isn't really a focus for me, but since I figured out how to automate the process I wanted to provide the WIP template for the modding community. :good:
Click to expand...
Click to collapse
Nice! I tried to compile aapt from my device a few mins ago just for s&g's got pretty far actually before it couldn't compile some external android libs because I didn't have them downloaded.
Have you ever seen the Android apktool apk by pqy330? It's not on git anymore for some reason, but the guy figured out how to get java, javac, aapt, aidl, and everything working on arm, only required a LD_LIBRARY_PATH export. I wish I could get a hold of the guy to ask him about getting some of those tougher arm static binaries compiled.
And yeah I wouldn't actively spend hours working on this if it's already in a working state like you said, it's just interesting compared to the other mundane things I read of xda lol. Especially new developments. Great job man.

APK-Patcher: minor fixes, binary updates:
- allow for recoveries without busybox
- update tool compiles to my newer zipalign and static(!) aapt builds
- strip zip binary to compensate for larger aapt and zipalign binaries
- simplify aapt usage now that we have a static arm binary
- configure zipalign for Marshmallow system APK handling
https://github.com/osm0sis/APK-Patcher/commit/af24805f06e2e2b92f2bfeeb1490d6022073c4b5
Thanks @Surge1223 for the help with figuring out compiling zipalign and aapt statically for arm. :highfive:

Wow, i wish that i know this patcher before
so im trying to add two lines after line #24 in "res/xml/tuner_prefs.xml"
i tried
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and this also
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and it doesn't work, im really sorry i never used sed commands before
do i have to add original file in "patch/SystemUI/res/xml" and then the script should change it ?

AL_IRAQI said:
Wow, i wish that i know this patcher before
so im trying to add two lines after line #24 in "res/xml/tuner_prefs.xml"
i tried
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and this also
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and it doesn't work, im really sorry i never used sed commands before
do i have to add original file in "patch/SystemUI/res/xml" and then the script should change it ?
Click to expand...
Click to collapse
Nah, per the OP, the "patch" directory is only for replacing files whole, which you shouldn't do to keep it universal.
You just need a working sed command in the script directory.
You can borrow this script function from my AnyKernel2 to make the insertion easier for you as a sed beginner:
Code:
# insert_line <file> <if search string> <before|after> <line match string> <inserted line>
insert_line() {
if [ -z "$(grep "$2" $1)" ]; then
case $3 in
before) offset=0;;
after) offset=1;;
esac;
line=$((`grep -n "$4" $1 | head -n1 | cut -d: -f1` + offset));
sed -i "${line}s;^;${5}\n;" $1;
fi;
}
Then follow that with an insert_line command using the syntax provided. "if search string" tests whether the mod has been completed already, then "line match string" is the line you want to put the inserted lines before/after.
You can insert both lines at once with a \n between as well.

osm0sis said:
Nah, per the OP, the "patch" directory is only for replacing files whole, which you shouldn't do to keep it universal.
You just need a working sed command in the script directory.
You can borrow this script function from my AnyKernel2 to make the insertion easier for you as a sed beginner:
Code:
# insert_line <file> <if search string> <before|after> <line match string> <inserted line>
insert_line() {
if [ -z "$(grep "$2" $1)" ]; then
case $3 in
before) offset=0;;
after) offset=1;;
esac;
line=$((`grep -n "$4" $1 | head -n1 | cut -d: -f1` + offset));
sed -i "${line}s;^;${5}\n;" $1;
fi;
}
Then follow that with an insert_line command using the syntax provided. "if search string" tests whether the mod has been completed already, then "line match string" is the line you want to put the inserted lines before/after.
You can insert both lines at once with a \n between as well.
Click to expand...
Click to collapse
im such a noob, even this basic code is hard for me to understand :crying:
do i have to keep grep commands ?, because i dont need to replace or find something in the file, only inserting after line #24
$1 is the file here right ?, and your trying to find $2 and add someting, and in case of 3$ there is another case, and edits will probably be before/after $4 ?

AL_IRAQI said:
im such a noob, even this basic code is hard for me to understand :crying:
do i have to keep grep commands ?, because i dont need to replace or find something in the file, only inserting after line #24
$1 is the file here right ?, and your trying to find $2 and add someting, and in case of 3$ there is another case, and edits will probably be before/after $4 ?
Click to expand...
Click to collapse
What is on line 24? Wouldn't it be more universal to match against some part of the contents of the current line 24 to ensure its always in the right place, even if the number changes?
The $1 $2 $3 $4 $5 correspond to each argument supplied as per the <syntax> in the #commented line.

osm0sis said:
What is on line 24? Wouldn't it be more universal to match against some part of the contents of the current line 24 to ensure its always in the right place, even if the number changes?
The $1 $2 $3 $4 $5 correspond to each argument supplied as per the <syntax> in the #commented line.
Click to expand...
Click to collapse
i modded systemui for N5X,N6/6P,N9 and android one device, all of them has the same layout
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
or i can search for "<Preference android:title="@string/other"" and add it before it
oh, now its easier to understand ;P

Okay, so.. Probably:
Code:
insert_line res/xml/tuner_prefs.xml "com.android.systemui.tuner.NavBarTuner" before "com.android.systemui.tuner.OtherPrefs" "<Preference android:title=\"@string/nav_bar\" android:key=\"nav_bar\" android:fragment=\"com.android.systemui.tuner.NavBarTuner\" />\n<Preference android:title=\"@string/color_and_appearance\" android:key=\"color_transform\" android:fragment=\"com.android.systemui.tuner.ColorAndAppearanceFragment\" />";

osm0sis said:
Okay, so.. Probably:
Code:
insert_line res/xml/tuner_prefs.xml "com.android.systemui.tuner.NavBarTuner" before "com.android.systemui.tuner.OtherPrefs" "<Preference android:title=\"@string/nav_bar\" android:key=\"nav_bar\" android:fragment=\"com.android.systemui.tuner.NavBarTuner\" />\n<Preference android:title=\"@string/color_and_appearance\" android:key=\"color_transform\" android:fragment=\"com.android.systemui.tuner.ColorAndAppearanceFragment\" />";
Click to expand...
Click to collapse
i removed /patch and added the script to SystemUI-res.sh, but it doesn't seems to work
screenshot:

AL_IRAQI said:
i removed /patch and added the script to SystemUI-res.sh, but it doesn't seems to work
screenshot:
Click to expand...
Click to collapse
You shouldn't see that message for what you're doing unless you've got things set up weird. Can you just attach your WIP zip and I'll take a look?

osm0sis said:
You shouldn't see that message for what you're doing unless you've got things set up weird. Can you just attach your WIP zip and I'll take a look?
Click to expand...
Click to collapse
here you are, link
Thanks

osm0sis said:
You shouldn't see that message for what you're doing unless you've got things set up weird. Can you just attach your WIP zip and I'll take a look?
Click to expand...
Click to collapse
AL_IRAQI said:
here you are, link
Thanks
Click to expand...
Click to collapse
Okay, try this. I've got you about 90% of the way there; fixed all the weirdness with the unnecessary patch folder, extra files and extracmd. The sed insertion is still untested, so you'll have to check that out, and from what you and others have told me you'll need to update the included tools for Nougat support.
Download the newer bak/smali and apktool, then that's done with
Code:
dx --dex --output=classes.dex <file>.jar
from within the latest SDK. Add the classes.dex to the jar (it's a zip). Name them like the current ones (version numbers, etc.) and put them in tools and remove the old ones. :good:
[ Attachment removed. ]

osm0sis said:
Okay, try this. I've got you about 90% of the way there; fixed all the weirdness with the unnecessary patch folder, extra files and extracmd. The sed insertion is still untested, so you'll have to check that out, and from what you've told me you'll need to update the included tools for Nougat support.
Download the newer bak/smali and apktool, then that's done with
Code:
dx --dex --output=classes.dex <file>.jar
from within the latest NDK. Add the classes.dex to the jar (it's a zip). Name them like the current ones (version numbers, etc.) and put them in tools and remove the old ones. :good:
Click to expand...
Click to collapse
Awesome, ill try it today :fingers-crossed:
Edit:
i already downloaded newer tools, and now i have to run this code ?
Code:
dx --dex --output=classes.dex apktool_2.0.3.jar
dx --dex --output=classes.dex baksmali-2.1.1.jar
dx --dex --output=classes.dex smali-2.1.1.jar

AL_IRAQI said:
Awesome, ill try it today :fingers-crossed:
Edit:
i already downloaded newer tools, and now i have to run this code ?
Code:
dx --dex --output=classes.dex apktool_2.0.3.jar
dx --dex --output=classes.dex baksmali-2.1.1.jar
dx --dex --output=classes.dex smali-2.1.1.jar
Click to expand...
Click to collapse
@AL_IRAQI, sorry, just saw your edit. The latest bak/smali is 2.1.3, and latest apktool is 2.2.0, but otherwise yes, you run that command on each jar separately from the build-tools directory of the latest Android SDK, and put the resulting classes.dex inside the jar (which is a zip file). Then it's able to be run on Android as in my zip.

New commit!
tools: binary updates:
https://github.com/osm0sis/APK-Patcher/commit/e4f6e3e90e13c862652183460a86e49cb0514fd9
Since I felt bad @AL_IRAQI didn't appear to be able to figure it out for his mods. :angel:

From an incorrect thread:
aj20010319 said:
Can I combine APK Patcher with aroma? Like use the standard updater-binary and adding all these functions from updater-binary into a different shell script and executing it later?
Click to expand...
Click to collapse
aj20010319 said:
Okay so I somehow managed to get aroma and apk patcher together, made separate zips and then made one zip flash the other.
I am trying to decompile framework-res.apk, but it's failing, logs show this error,
Code:
framework-res.apk
I: Using Apktool 2.2.0 on framework-res.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Regular manifest package...
I: Decoding file-resources...
java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/imageio/ImageIO;
at brut.androlib.res.decoder.Res9patchStreamDecoder.decode(Res9patchStreamDecoder.java:39)
at brut.androlib.res.decoder.ResStreamDecoderContainer.decode(ResStreamDecoderContainer.java:33)
at brut.androlib.res.decoder.ResFileDecoder.decode(ResFileDecoder.java:120)
at brut.androlib.res.decoder.ResFileDecoder.decode(ResFileDecoder.java:87)
at brut.androlib.res.AndrolibResources.decode(AndrolibResources.java:262)
at brut.androlib.Androlib.decodeResourcesFull(Androlib.java:131)
at brut.androlib.ApkDecoder.decode(ApkDecoder.java:108)
at brut.apktool.Main.cmdDecode(Main.java:163)
at brut.apktool.Main.main(Main.java:81)
Caused by: java.lang.ClassNotFoundException: Didn't find class "javax.imageio.ImageIO" on path: DexPathList[[zip file "/tmp/apkpatcher/tools/apktool_2.2.0-dexed.jar"],nativeLibraryDirectories=[/system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
... 9 more
Suppressed: java.lang.ClassNotFoundException: javax.imageio.ImageIO
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java)
at java.lang.BootClassLoader.loadClass(ClassLoader.java)
... 11 more
Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack trace available
Decoding APK resources failed. Aborting...
Click to expand...
Click to collapse
Seems like you're in the wrong thread? I'm not sure. You can try reverting to the previous builds of tools, but beyond that I'm not sure at the moment. It's on my to-do to test everything out again in the near future and resolve any issues I can come up with. Please reply in the APK-Patcher thread.