Tutorial: How to make Flashable zips

This tutorial will help you to understand the making of a flashable zip or also known as an update zip

Setting up your zip directories:

You will need to create the following folder structure inside of your flashable zip (The flashable zip can be called whatever it is you want it to be. (These subfolders are case sensitive)):

Code:

/META-INF/com/google/android

All flashable zips include this file structure. The final folder, android, will contain two files within it:

Code:

update-binary
updater-script

Note: The update-binary is specific to our devices based on built API mostly, but with other factors as well. It is currently open source and therefore possible to be built on a personal basis. However, to insure you are using the correct one, I can suggest taking it from the most recent OTA available for your device.

Setting up the updater-script:

-- This we can create ourselves, to ensure it works properly we will use Notepad++ for Window Users, and Gedit for those using Linux.

Open the text editor and start a new file, with the following settings for Window Users:

Quote:

Format: Unix
Encoding: ANSI
Default Language: Normal Text

Save this file as:

Quote:

File name: updater-script
File type: All types (*.*)

And for Linux users:

Just leave it as is.

You can now edit this file, so from here I will be providing some examples:

This is checking to see if you are flashing the correct handset, this is not a requirement, but it insures that the flashable zip will only work for the specified device as to not be accidently flashed by others and to help prevent causing any possible damage to those who do not qualify to use that particular zip. Just insert another device name in the place of "k2cl" if you so wish, or remove the command all together.

To explain this a little further, you have told the script to check certain properties within your 'build.prop' file located in your /system folder. The above command ensures the following categories have the correct definitions before proceeding with the flash:

Quote:

Code:

ro.product.device=
ro.build.product=
ro.product.board=

Take note, that if you apply this to a full rom which result you having to wipe out the system partition before flashing then this will obviously not work, because you also wiped out the build.prop file along with the /system, so the zip will be aborted due to an error by not being able to verify as instructed to do in the syntax.

Here are the main build properties within your build.prop (may slightly vary):

This is the specific mount point for the k2cl system partition, if you wish to flash a different partition, data for instance, you can get the mount points for your device by entering the following code over ADB via PC or on our phone via terminal emulator:

Quote:

Code:

adb shell
mount > /sdcard/PHONENAME_mountinfo.txt

This will place a text file on your sdcard with the mount points for your specific device. (Remember to swap 'PHONENAME' with your device name e.g. 'k2cl', as a means of remembrance and for record keeping).

Quote:

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

This command extracts the files you wish to flash from the zip and flashes them to the phone, it is formatted as follows ("package-path", "/destination-path"). So for this example you are telling it to flash everything from the 'system' folder in your zip to the /system partition of your handset. You can obviously change these values for different partitions.

uid - user id
gid - group id
dirmode - permission to set to directories contained within the specified directory
filemode - permission to set to files contained within the specified directory
dirpath... - directory to set permission on

You will need to also understand the way file permissions are represented:

Example = drwxrwxrwx

-- Use a Root Explorer to find the UID, GID, and permissions for a file. Permissions are the string that looks like some variation on 'rwxr-xr--' next to each file. Long press and choose "change owner" to get the UID and GID. You just want the number next to "owner" and "group", respectively.

-- If you're replacing a file, look up these settings for the existing copy and use them. If you're adding a file, just find a file that does the same functions and copy what it has (for example, installing an app to /system/app? Just look at these settings for any other app in that directory).

-- MODE is technically a 4-bit string, but the first character can be omitted. There doesn't seem to be any android file permissions with the first character set. For good practice, I think it's safe to assume you can always use a leading 0 unless you know otherwise for something specific. Or, just use a 3-digit MODE, which says to leave those settings as they are (disabled by default). (I.e. 0644=644).

The next 9 characters define the file permissions. These permissions are
given in groups of 3 each.

The first 3 characters are the permissions for the owner of the file or directory.
Example = -rwx------

The next 3 are permissions for the group that the file is owned by.
Example = ----rwx---

The final 3 characters define the access permissions for everyone not part of the group.
Example = -------rwx

There are 3 possible attributes that make up file access permissions.

r -- Read permission. Whether the file may be read. In the case of a
directory* this would mean the ability to list the contents of the
directory.

w -- Write permission. Whether the file may be written to or modified. For
a directory this defines whether you can make any changes to the contents
of the directory. If write permission is not set then you will not be able
to delete rename or create a file.

x -- Execute permission. Whether the file may be executed. In the case of a
directory this attribute decides whether you have permission to enter,
run a search through that directory or execute some program from that
directory

You set these permissions using the following binary based numerical system:

Quote:

Code:

0: --- No Permissions (the user(s) cannot do anything)
1: --x Execute Only (the user(s) can only execute the file)
2: -w- Write Only (the user(s) can only write to the file)
3: -wx Write and Execute Permissions
4: r-- Read Only
5: r-x Read and Execute Permissions
6: rw- Read and Write Permissions
7: rwx Read, Write and Execute Permissions

Default Linux permissions:

For Files:
"Read" means to be able to open and view the file
"Write" means to overwrite or modify the file
"eXecute" means to run the file as a binary

For Directories:
"Read" means to be able to view the contents of the directory
"Write" means to be able to create new files/directories within the directory
"eXecute" means to be able to "Change Directory" (cd) into the directory

You now need to create some other folder(s), this needs to be named based on where within the system you are flashing to help keep it simple (you can technically name them whatever, just as long as they are placed in the proper location of your current daily rom); for the sake of this example we are flashing to the system partition, so:

Quote:

Code:

/META-INF/com/google/android
/system/app

Place whatever files you wish to flash within this file. For example:

Quote:

Code:

/META-INF/com/google/android
/system/app/nameofapp.apk

Creating your .zip file:

Select both of your top directories and their contents 'META-INF' and 'system' and package them into a .zip file with 7zip or any other method you may currently use, using the following settings:

You don't actually need to sign your zip file for it to work as most custom recoveries like, TWRP, now support unsigned zips. For the learning developers and the more cautious among us though, here is how. First, go ahead and place your newly made flashable zip on to your device. I preferably place it on the root of my internal sdcard, though the choice is ultimately yours.

Download the free application on the playstore called, zipsigner. Open it up and select the option for, Choose In/Out....

Go and select your zip, and then select, auto-testkey, under where it says, Key/mode. Once done, proceed to sign it. You will recieve an output zip file with the same name as the previous unsigned zip but with it ending in *-signed.zip. At this point, you are now good and you can either apply your zip to your device, or share your work with others.

There are so many different ways you can go about signing the zip, but for something like a simple flashable zip file, I will normally always go this route.

supersu is fixed. Can flash and gain root. I permanently unrooted my device for the official test and success. The initial problem I had was in the script... A stupid (") mark.... Spent hours looking for the problem and it came down to one " mark... But, I found it and its up and going. even tested it on my girlfriends HTC Evo Design 4g as she too needed root now for certain things - success.

My apologies for the past problems and delays.

Here is the code used for the su and busybox flash zip. The quotation in red is what was initially missing and overlooked for hours before I found it.

EDIT: after simply creating a folder named 'apktool' in
/sdcard it asked root permissions.

I'll see if there is anything else needed to do before I can decompile and recompile successfully.

Hey bud, hope you were able to resolve the issue. Anyways, I fixed the apktool flash zip. Was missing folders and of course, due to those missing I failed to implement them in my script. Human error none the less. Will upload the flash zip for Apktool when I get the chance (meaning - when I have WiFi and not 3G). Here is the script code so you can verify that the stuff needed is and will be implemented into the internal sdcard. Don't know why I failed to include it originally. Guess I just had too much on my mind and slipped up lol.

XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality.Are you a developer?