[Micromax A110] nexi4droid:
Creating Flashable zips for CWM

Basics- Create food(flashable zip file) for CWM

I created this tutorial especially for noobs who would like to know how the clockworkmod uses the .zip file and what and all goes into the process of flashing a .zip file and mainly about the format and syntax used in updater-script.

first is first!

#include

/*

* I am not responsible for bricked devices, dead SD cards or

* thermonuclear war.

* do some research if you have any concerns.

* YOU are choosing to make these modifications.

* yes, i copied this disclaimer from FXP because it is cool

and i am lazy!

*/

now what is the updater-script and update-binary present in the META-INF>com>google>android in any flashable zip package?

1. updater-script - it is just a text file which contains

all the commands which tells the clockworkmod what to do with the given zip file. the updater-script is written in the edify scripting language.

2. update-binary - it is a binary which is requiered by the clockworkmod to translate the human readable format of the updater-script to machine readable format for execution of the updater-script in our device.

exploring the updater-script:

now let's start exploring the updater-script !

1. open the updater script with notepad++ (strongly recommended)

2. now i will try and explain commands generally used in the updater-script,

assert(getprop("ro.product.device") == "ST15i" || getprop

("ro.build.product") == "ST15i" ||

getprop("ro.product.device") == "ST15a" || getprop

("ro.build.product") == "ST15a" ||

getprop("ro.product.device") == "smultron" || getprop

("ro.build.product") == "smultron");

the above bunch of lines checks the device model to confirm that the zip file is flashed on the devicefor which it is specifically created for. These bunch of lines are very important because it preventsflashing of zip file which is not intended for the device hence avoiding any problems due to flashingthe wrong zip. for example the above lines checks for the value of "ro.product.device" and"ro.build.product"in the build.prop file of the already existing rom in the device, if any of the threedefined values ST15i, ST15a, smultron are found it will continue with the next line of updater-script otherwise flashing gets aborted with error in getprop.

format("yaffs2", "MTD", "system", "/system");

the above command explains itself, it is used to format the specified partition

syntax explanation:

format - the main command to direct the cwm to format using the following parameters:

"yaffs2" - filesystem type used in the device

"MTD" - type of the partition used in the file system

"system" - location of the partition to be formatted

"/system" - name of the partition to be formatted

ui_print("Format Completed");

the above command is also self explanatory, it directs the cwm to display the following textenclosed in double quotes in the user interface (display).after succesful formatting it displays "Format Completed" in the device screen.

mount("yaffs2", "MTD", "system", "/system");

the mount command directs the cwm to mount the following file system and the following partition the syntax is just as explained in the format command except that this command mounts the defined partition whereas the format command formats the defined partition.

let's review what we have done till now,

1. we have checked the device to confirm that this is the device for which we created the zip.

2. we have formatted the system partition of the device.(this is only done when a new complete rom is being flashed, for flashing mods you should never format the system partition!)

3. we have mounted the system partition of the device.

now let's continue,

package_extract_dir("system", "/system");

this command searches for the directory (folder) named "system" in the root of the zip file and copies all the content of the "system" folder from the zip file into the "/system" partition which is already mounted by the previous mount command.remember the structure of the file system in the zip file and the "/system" partition of the device must be always

identical.for eg., you have created a mod by editing the systemUI.apk and you want to flash it, the system UI.apk resides in "/system/app" so the structure of the file system in the update zip should be "/system/app/systemUI.apk" ie., the update zip should contain folder named "system" at the root of it and folder named "app" inside the "system" folder and the modded "systemUI.apk" must be placed inside the "app" folder.

package_extract_file("autoroot.sh", "/tmp/autoroot.sh");

this command searches for the file named "autoroot.sh" in the root of the zip file and copies the file to "/tmp" folder and names it as "autoroot.sh" (here it does not change the name)

symlink("mksh", "/system/bin/sh");

the above command creates a symlink. okay, now let's see about symlinks, symlink is nothing but shortcuts, for example if a file is required in two different places instead of copy pasting the file in two different locations, the file is copied to one of the two locations and in the other location a shortcut to the file(symlink) is created. the source and the symlink can have different names (actually this is the prime use of symlinks).to explain in a noob friendly manner, take the above symlink, it creates a shortcut(symlink) for the command "mksh" and places it in the path of the operating system. the shortcut(symlink) directs to the file "/system/bin/sh" , so whenever the os gets a request to execute the "mksh" command, the actual binary that gets excuted will be "/system/bin/sh" .creating symlinks saves a lot of space because instead of copying the whole file and placing it in required places we are just creating shortcuts which directs to the source file which can be placed anywhere in the file system (generally placed in the path of the os).

set_perm_recursive(0, 0, 0755, 0644, "/system");

the above command is used to set permission recursively for the files and folders present inside a folder (in this case for "/system" folder).

syntax explanation:

0 - uid - it defines that the following permission is set for the user id 0 .

0 - gid - it defines that the following permission is set for the group id 0 .

0775 - dirmode - it defines that 0775 permission to set to directories contained within the specified directory.

0644 - filemode - it defines that 0644 permission to set to files contained within the specified directory.

"/system" - target directory to set the above mentioned

permissions.

set_perm(0, 3003, 06755, "/system/bin/ip");

the above command is used to set permission for a individual file (in this case for "/system/bin/ip" file).

syntax explanation:

0 - uid - it defines that the following permission is set for the user id 0 .

3003 - gid - it defines that the following permission is set for the group id 3003 .

06775 - it defines that 06775 permission to set to the specific file.

"/system/bin/ip" - target file to set the above mentioned permissions.

run_program("/tmp/autoroot.sh");

remember the file autoroot.sh from package_extract_file command?that file is supposed to be a shell script, the above command directs cwm to execute the "autoroot.sh" shell

script present in "/tmp" folder.

unmount("/system");

the unmount command directs the cwm to unmount the following partition the syntax is just as explained in the mount command except that this command unmounts the

defined partition whereas the mount command mounts the defined partition.Okay now going into slightly complex and/or not widely used

updater-script commands,Ifelse

Syntax:

Ifelse(condition),(do_this),(else_do_this);

Example:

ifelse mount("yaffs2", "MTD", "system", "/system") ==

"system", ui_print("Mounted!"), ui_print("Mount Failed!");

Ifelse command can be explained simply as asking the system to do something based on the result of a condition.

From the example:The ifelse command would attempt to mount the MTD partition named "system" to "/system".If the mounting process succeeds (the condition), the script

will display "Mounted!", else it will display "Mount Failed!"

abort()

It just abort's the script execution

Note: it is usually paired with some other command for example the getprop command or with ifelse. Independently specifying abort() in the updater-script will

kill the script abruptly right there so use this command carefully.

ALWAYS LEAVE A BLANK LINE AT THE END OF THE update-script

(if the code contains 50 lines then 51 lines should be visible in the notepad++ including a blank line after the end of the script)

ALWAYS REMEMBER TO SET THE EOL (end of line) CONVERSION OF updater-script IN UNIX FORMAT BEFORE SAVING (notepad++ > edit > EOL conversion > UNIX format)

the above mentioned commands are just basic edify scripting commands which are generally used in updater-script.