Develop Bugs

[DEV Idea] Magldr/CLK all-in-one rom (somewhat obsolete..)

Work posted here, it is tested working by me
http://www.neopeek.com/viewtopic.php?f=24&t=7366
Just make sure to copy all files needed by CLK (ppp, ril wrapper, init.d scripts, etc) from tytung's kernel patches

This would be awesome if pulled off

MAGLDR 1.2 and below only support Yaffs boot partition type.
MAGLDR 1.3 supports Yaffs and Raw boot partition types.
And cLK only supports Raw boot partition type.
However every MAGLDR ROM uses Yaffs boot partition, that's why we need to separate two types of ROMs.
In fact, I ever released a RAW boot partition ROM (NexusHD2-Gingerbread_V2.6T_WiFi-Calling_update_20110418.zip) in WiFi Calling development thread that suits for cLK and MAGLDR at the same time.
It uses PPP as the default data connection, but we can switch to more stable RMNET if using MAGLDR.

e334 said:
Finding out that the only difference between a magldr and a clk rom is the format of /boot (initrd.gz/zImage vs Boot.IMG), files in /etc/ppp and some scripts in /etc/init.d, I've decided to try to combine everything all together so developers would not need to upload 2 seperate versions of a rom in order to suit both CLK and MagLDR users...
The basic principle is this:
-updater-script checks /mnt/sdcard for a file called "clk.txt" or "magldr.txt" (that is created by the user) and then if it find "clk.txt", it unpacks files needed for clk compatibility and flashes boot.img but if it finds "magldr.txt", it copies the /boot folder to the /boot partition and nothing else is changed (assuming the rom was built for magldr ONLY compatibility at first).
So extra files that will be needed for the rom to be both clk/magldr compatible would be as listed:
/system/etc/.clk.tar.gz
(Contents of .clk.tar.gz are basically the same as the CLK patch by tytung except with 2 extra file, which are /system/ppp and /system/init.d/01modules)
-You will need to delete old modules script, if present in the rom, in order to it to work correctly (complete contents listed below.. vvv)
Code:
Content of .clk.tar.gz are as follows (it unpacks to /system)
-.clk.tar.gz
-/system/ppp (so module script can find it and load proper module)
-/system/etc/ppp/
-resolv.conf
-ppp-gprs.pid
-pap-secrets
-options.smd
-options
-ip-up-vpn
-ip-up
-ip-down
-chap-secrets
-active
-/system/etc/init.d/
-97ppp
-02htcleo
-01modules
Boot files, you place both the /boot version and the boot.img version in a folder called /boot in the root of the rom
-/boot/initrd.gz
-/boot/zImage
-/boot.img
Last but not least, you will need to modify the updater-script (I avoided making an extra script to make the process cleaner)
In updater-script, you will need to remove the lines that flashes boot.img or copies boot to /boot partition and add this:
Code:
#decide clk or magldr
if -f /mnt/sdcard/clk.txt
then
#boot.img needed
ui_print("Writing Boot.img");
package_extract_file("boot/boot.img","/tmp/boot.img");
write_raw_image("/tmp/boot.img", "boot");
delete("/tmp/boot.img");
#ppp files also needed
run_program("/sbin/sh","-c",
concat("busybox gzip -dc ",
"/system/etc/.clk.tar.gz > ",
"/system/"));
else
#boot folder needed
if -f /mnt/sdcard/magldr.txt
then
ui_print("Writing Boot");
format("MTD", "boot");
mount("MTD", "boot", "/boot");
package_extract_dir("boot/boot","/boot");
unmount("/boot");
endif;
(might have left out [ ] somewhere.. please correct me if I did)
Credits:
-Tytung
-EZterry (find him in the G1 Section)
-Neopeek
To Do:
-Eliminate the process needed for the user to create a clk.txt or magldr.txt by using differences between clk/magldr..
Please review the scripting, report if you get any 'error 6' when flashing, and I am open to suggestions!
Below is attached the .clk.tar.gz (zipped in a folder because attachments won't allow me to upload tar.gz files... )
Click to expand...
Click to collapse
there are already a few ROMs that use similar approach (including mine):
the base ROm is for MAGLDR and there is easy patch to make that a cLK ROM - so for that there is small update package...so basically I need to develop one version and leave cLK patch unchanged (until there is kernel change in the ROM)...

e334 said:
Finding out that the only difference between a magldr and a clk rom is the format of /boot (initrd.gz/zImage vs Boot.IMG), files in /etc/ppp and some scripts in /etc/init.d, I've decided to try to combine everything all together so developers would not need to upload 2 seperate versions of a rom in order to suit both CLK and MagLDR users...
The basic principle is this:
-updater-script checks /mnt/sdcard for a file called "clk.txt" or "magldr.txt" (that is created by the user) and then if it find "clk.txt", it unpacks files needed for clk compatibility and flashes boot.img but if it finds "magldr.txt", it copies the /boot folder to the /boot partition and nothing else is changed (assuming the rom was built for magldr ONLY compatibility at first).
So extra files that will be needed for the rom to be both clk/magldr compatible would be as listed:
/system/etc/.clk.tar.gz
(Contents of .clk.tar.gz are basically the same as the CLK patch by tytung except with 2 extra file, which are /system/ppp and /system/init.d/01modules)
-You will need to delete old modules script, if present in the rom, in order to it to work correctly (complete contents listed below.. vvv)
Code:
Content of .clk.tar.gz are as follows (it unpacks to /system)
-.clk.tar.gz
-/system/ppp (so module script can find it and load proper module)
-/system/etc/ppp/
-resolv.conf
-ppp-gprs.pid
-pap-secrets
-options.smd
-options
-ip-up-vpn
-ip-up
-ip-down
-chap-secrets
-active
-/system/etc/init.d/
-97ppp
-02htcleo
-01modules
Boot files, you place both the /boot version and the boot.img version in a folder called /boot in the root of the rom
-/boot/initrd.gz
-/boot/zImage
-/boot.img
Last but not least, you will need to modify the updater-script (I avoided making an extra script to make the process cleaner)
In updater-script, you will need to remove the lines that flashes boot.img or copies boot to /boot partition and add this:
Code:
#decide clk or magldr
if -f /mnt/sdcard/clk.txt
then
#boot.img needed
ui_print("Writing Boot.img");
package_extract_file("boot/boot.img","/tmp/boot.img");
write_raw_image("/tmp/boot.img", "boot");
delete("/tmp/boot.img");
#ppp files also needed
run_program("/sbin/sh","-c",
concat("busybox gzip -dc ",
"/system/etc/.clk.tar.gz > ",
"/system/"));
else
#boot folder needed
if -f /mnt/sdcard/magldr.txt
then
ui_print("Writing Boot");
format("MTD", "boot");
mount("MTD", "boot", "/boot");
package_extract_dir("boot/boot","/boot");
unmount("/boot");
endif;
(might have left out [ ] somewhere.. please correct me if I did)
Credits:
-Tytung
-EZterry (find him in the G1 Section)
-Neopeek
To Do:
-Eliminate the process needed for the user to create a clk.txt or magldr.txt by using differences between clk/magldr..
Please review the scripting, report if you get any 'error 6' when flashing, and I am open to suggestions!
Below is attached the .clk.tar.gz (zipped in a folder because attachments won't allow me to upload tar.gz files... )
Click to expand...
Click to collapse
That is pointless IMHO, the commands you mentioned are linux shell commands mixed with recovery script which is of no use. As for single ROM issue, its been a long story short, any magldr rom can be run on clk using fastboot binary and some ppp files. hence what i would do is, supply a ppp conversion package for my rom including the cache remount script for CWM to work with clk. and since the user is using clk, he is knowledgeable enough on how to use fastboot (Even though commands are given on page of every such rom ie. AngelDeath's releases)

Oh, I guess that is the end of the "script" then. I did not know magldr supported raw type because of all the roms I've downloaded, it was either yaffs or had raw boot. Mods, please lock the thread out let it die..

[TUTORIAL] Making Flashable ZIPs, EDIFY Script, ZIP Signing & Key Creation [19.01.13]

[TUTORIAL] Making Flashable ZIPs, EDIFY Script, ZIP Signing & Key Creation [19.01.13]
Recent Updates: Command Line Edify Script Tester, Further 'update-binary' info clarification, helpful links, additional credits. post#1
Hi all,
In the process of creating my [BOOTANIMATIONS - LINKS & INFO] thread I realised I needed to know more about how boot animations worked, as by default people tend to ask questions in that type of thread, so I wanted to be able to help.
This meant I came across the problem of creating flash-able ZIP files and Edify scripting and in the interests of sharing and helping this great community I would like to share what I have found and hopefully learn more through discussion, I certainly am no expert and am always willing to learn.
I have checked xda and various other websites whilst reseraching for this post and there is nothing that really explains all the basic concepts to just get up and running, also a lot of threads are quite old and focus on the old Amend scripting syntax or are a confusing mixture of the two.
I hope this helps people get started and that we can all collaborate to make this a thread a source of valuable information.
Contents:
Post #1: Tutorials
Post #2: Edify Commands
***Please, if there are any mistakes on this thread then let me know what I have done incorrectly in reply to this post and I will update the thread to correct it***
***As always, I accept no responsibiltiy for your handset, you modify it at your own risk, nobody is forcing you...be aware you can seriously bork your phone by flashing its internal partitions! Always make a nandroid back-up and think before you flash!***
***Have you made a nandroid back-up...no? Then make one!!***
You will need the following:
Android SDK, ADB & Fastboot set up for your handset.
Notepad++ [LINK]
7zip [LINK]
Setting up your zip directories:
you will need to create the following folder structure (these are case sensitive):
Code:
/META-INF/com/google/android
All flash-able zips include this file structure, the final folder 'android' will contain two files:
Code:
update-binary
updater-script
update-binary: I have been unable to find much information on the update-binary file other than they seem to be chip set specific (if anyone can shed further light on these I will include it here). For the sake of compatibility I have attached the update binary from the latest CyanogenMod Nightlies for the maguro at the bottom of this thread - You can of course download the latest nightly and extract the update-binary file yourself as the attached one will obviously begin to date (all credit to the great devs at CyanogenMod for this, many thanks).
Update: For more detailed info on the update binary you can find the sources in the bootable/recovery/updater directory at AndroidXRef here: [ xref: /bootable/recovery/updater/ ]. There is also an edify directory which looks like it handles the parsing of the script. Obviously with the sources there's nothing to stop you extending syntax/functionality should you wish given the fact the each zip comes with its own version. It will also help you understand how signature checking is handled.
Update II: For anybody having problems flashing it is worth ensuring you have an up to date version of the update-binary (obviously the one attached to this thread will gradually become out of date).
It is advisable to use the update-binary from the latest OTA image for your device, these images can be found in the following link:
Official Google OTA update URLs - efrant
updater-script: This we can create ourselves, to ensure it works properly we will use Notepad++.
Open Notepad++ and start a new file, with the following settings:
Format: Unix
Encoding: ANSI
Default Language: Normal Text
Save this file as:
File name: updater-script
File type: All types (*.*)
You can now edit this file, add the following text:
Code:
[COLOR="Red"]assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro");[/COLOR]
[COLOR="Green"]ui_print(" ");[/COLOR]
[COLOR="green"]ui_print("confirming device maguro");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="green"]ui_print("success");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("mounting system");[/COLOR]
[COLOR="red"]mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("updating system files");[/COLOR]
[COLOR="red"]package_extract_dir("system", "/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("unmounting system");[/COLOR]
[COLOR="red"]unmount("/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("by yourusername");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
***EMPTY LINE***
Ok, I've colour coded this so we can break it down, the lines of code in RED are the actual commands, everything else is cosmetic.
assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro"); This is checking you are flashing the correct handset, this is not a requirement, but is best practice. Just insert another device name in the place of "maguro" if you so wish, or remove the command all together.
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system"); This is the specific mount point for the maguro 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:
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. 'maguro')
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.
unmount("/system"); This simply unmounts whatever partition you previously mounted.
ui_print(" "); Shows text in the recovery whilst the flash is ongoing, you can put whatever you please between the speech marks, you must leave a space if you wish to have a blank line.
show_progress(0.200000, 5); Controls what the progress bar in the background is displaying, it is formatted as follows (fragment, seconds).
***EMPTY LINE*** This is not actually text, you simply need to leave a blank line at the end of your script before you save it for it to work.
FYI, this means in fact your script could look like this and still work:
Code:
[COLOR="Green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(1.000000, 30);[/COLOR]
[COLOR="red"]mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");[/COLOR]
[COLOR="red"]package_extract_dir("system", "/system");[/COLOR]
[COLOR="red"]unmount("/system");[/COLOR]
[COLOR="Green"]ui_print(" ");[/COLOR]
***EMPTY LINE***
But that just isn't that pretty, or as deceptively complicated lol!
Make sure you save your edify script.
Files to flash:
You now need to create a further folder, this needs to be named based on where within the system you are flashing, for the sake of this example we are flashing to the system partition, so:
Code:
/META-INF/com/google/android
/system/app
Place whatever files you wish to flash within this file e.g:
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 using the following settings:
Archive: name_of_your_file
Archive Format: zip
Compression level: Store
Update mode: Add and replace files
And there you have it, your very own flash-able .zip file.
I have attached an example flashable .zip file that includes this updater-script and the above mentioned CM update-binary.
How to sign your update.zip:
You don't actually need to sign your zip file for it to work as most custom recoveries now support unsigned zips, for aspiring developers and the more cautious among us though, here is how.
You will need to download the following files:
SignApk [LINK]
Java JDK (Java Development Kit) & JRE (Java Runtime Environment) [LINK]
Install Java JRE and JDK and restart your PC.
You then need to create a folder in the root of your c:\ drive named 'signapk' and extract the contents of the SignApk download (signapk.jar, key.pk8, certificate.pem) to this folder.
Place your .zip file into the same folder and then open cmd line. Input the following commands (remeber to change the name of 'myupdate.zip' to the name of your file and 'myupdate-signed.zip' to whatever you want your resulting .zip to be named):
Code:
cd\signapk\
java -jar signapk.jar certificate.pem key.pk8 c:\signapk\myupdate.zip myupdate-signed.zip
You should find that you now have the the following files in your 'META-INF' folder: CERT.RSA, CERT.SF, MANIFEST.MF
This can also to be used to sign .apk files using the below command (same stipulations for file name changing applies as above):
Code:
java -jar signapk.jar certificate.pem key.pk8 c:\signapk\myapplication.apk myapplication-signed.apk
How to create your own private signing key & certificate:
You will need the following download:
OpenSSL [LINK]
The above signapk file includes test keys, if you want to create your own private keys for signing, here's what you need to do.
As before extract the OpenSSL files to a folder in the root of your c:\ drive, preferably named 'openssl' for ease of cmd line navigation. Then input the following:
Code:
cd\openssl\
openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out request.pem
openssl x509 -req -days 9999 -in request.pem -signkey key.pem -out certificate.pem
openssl pkcs8 -topk8 -outform DER -in key.pem -inform PEM -out key.pk8 -nocrypt
You can then replace 'key.pk8' & 'certificate.pem' with your own files.
I really hope this has helped folks out, if so please consider hitting the 'Thanks' button!
Happy flashing!
Testing your script before you flash:
If you would like to test if your script commands are valid and will run properly on your PC first before you use them on your handset, therefore removing the fear of borking your current install/handset in the process then head to this post:
Command Line Edify Script Tester by: trevd
This great tool developed by trevd currently has the following features:
Validates function name.
Validates function parameter count.
It is available for Linux and Windows, so head over and check it out. Be sure to click trevd's thanks button if you find this useful.
Other helpful links & threads:
xda-developers: Edify script language wiki
Edify scripts in CWM recovery by: NFHimself
Phandroid - Edify Script Language Reference by: Koumajutsu
Introduction to edify updater script by: kurotsugi
Intelligent EDIFY updater-script - (Decides things during flash) by: lotherius
Credits:
CyanogenMod for (update-binary)
Lorenz's Blog for (SignAPK & Info)
JoeSyr for (Help with File Permissions)
efrant for (Help with various commands)
trevd for (further update-binary clarification and source links)
osm0sis for (Helpful info & forum links & help with update-binary info)

Edify Scripting Commands
I would like to try and put together a guide to Edify scripting commands and what their function is to compliment my above tutorial, I hope again we can all collaborate to make this a helpful source of information to all budding devs...we all have to start somewhere right!?
***Please, if there are any mistakes in this post or if you can help by adding further info please post below, thanks***
Ok...
Check you are flashing the correct device:
Code:
assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro" || getprop("ro.product.board") == "maguro");
This will check your device is showing the correct name in the build.prop, in this case "maguro", you can obviously replace this with your device name.
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:
Code:
ro.product.device=
ro.build.product=
ro.product.board=
Here are the main build properties within your build.prop:
Code:
ro.build.id=
ro.build.display.id=
ro.build.version.incremental=
ro.build.version.sdk=
ro.build.version.codename=
ro.build.version.release=
ro.build.date=
ro.build.date.utc=
ro.build.type=
ro.build.user=
ro.build.host=
ro.build.tags=
ro.product.model=
ro.product.brand=
ro.product.name=
ro.product.device=
ro.product.board=
ro.product.cpu.abi=
ro.product.cpu.abi2=
ro.product.manufacturer=
ro.product.locale.language=
ro.product.locale.region=
ro.wifi.channels=
ro.board.platform=
ro.build.description=
ro.build.fingerprint=
ro.build.characteristics=
ro.cm.device=
Print text in the recovery during flashing process:
Code:
ui_print("Your text here");
Code:
ui_print(" ");
This simply prints a line of text in the recovery, it has no actual effect on the flashing process, if you want a blank line just leave a blank space as the second example.
Controlling the progress bar:
I believe I understand this correctly, if not please do post below with further clarification.
Code:
show_progress(0.000000, 0);
or
Code:
set_progress(0.000000);
You have two choices when controlling the progress bar, the first example allows you to define fractions of the progress bar and how long they will take to fill. The second example just allows you to specify that the bar fills to a certain fraction at whatever point during the flashing process.
The command is defined as: (progress bar fraction, duration in seconds to fill defined fraction);
For example the following code lines interspersed with your other commands would fill a fifth of the progress bar every five seconds:
Code:
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
This process will only complete if the script takes long enough to flash, therefore you need to be aware of what you are actually flashing and how long it will take when defining these values.
If you wish to just define a fraction without fill without a time scale you can use the following command:
Code:
set_progress(0.000000);
It is also best practice to include this element in your scripts as it will reassure people that their handset hasn't frozen during a flash.
Mount/Unmount a partition:
To mount a partition you need to use the following syntax:
Code:
mount("filesystem-type", "partition-type", "device-specific-location", "mount-point");
filesystem-type: "ext4" or "yaffs2" (maguro is ext4)
partition-type: "EMMC" or "MTD" (maguro is EMMC)
location: Device specific address
mount-point: /system etc
So far I have managed to define the following Maguro specific mount points:
Code:
"/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata", "/data"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/cache", "/cache"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/efs" "/factory"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata", "/mnt/sdcard"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/boot"
Example command would be:
Code:
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");
I have taken these mount points from the file output by the maguro when you enter the following adb command:
Code:
adb shell "mount > /sdcard/maguro_mountinfo.txt"
I have to admit I am a little in the dark about the "/factory" partition, any info would be greatly appreciated!
To unmount a partition you need to input the following command:
Code:
unmount("/system");
Obviously replace the mount partition with whatever partition you are working in.
Format a partition:
To format a partition you need to use the following syntax:
Code:
format("filesystem-type", "partition-type", "device-specific-location", "0");
Example:
Code:
format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0");
Some scripts include the "0" and some do not, not sure exactly on the function difference when included or not, again clarification would be great.
Flashing the contents of your ZIP file:
To flash an entire directory:
Code:
package_extract_dir("system", "/system");
To flash a single file:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
These commands are structured as follows:
Entire directory: ("zipfileSource", "destination-partition");
Single File: ("file", "device-specific-mountpoint");
Deleting folders & files:
You can delete multiple folders or files using just one command, as follows:
To delete files:
Code:
delete("file-path-1", "file-path-2", "file-path-3);
To delete folders/directories:
Code:
delete_recursive("directory-path-1", "directory-path-2", "directory-path-3");
Setting Permissions
Here are the basics for setting permissions.
If you want to research the reasons behind this, there is some useful information on Linux permissions here: chmod wiki, linuxquestions.org linux wiki.
Thanks to JoeSyr for his input and help understanding this section of the tutorial.
Set permissions of a file or set of files:
Code:
set_perm(uid, gid, mode, "filepath1", "filepath2")
Example:
Code:
set_perm(0, 0, 06755, "/system/xbin/su");
uid - user id
gid - group id
mode - permission mode
filepath... - file to set permission on
Set permissions of a directory or set of directories and all files and folders within them:
Code:
set_perm_recursive(uid, gid, dirmode, filemode, "dirpath1", "dirpath2")
Example:
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
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
Permissions syntax explained...so I can understand it lol (if I do then anyone can!):
The following are the pre-defined Android UID's & GID's. Taken from the following link: Android UIDs and GIDs
Code:
AID_ROOT 0 /* traditional unix root user */
AID_SYSTEM 1000 /* system server */
AID_RADIO 1001 /* telephony subsystem, RIL */
AID_BLUETOOTH 1002 /* bluetooth subsystem */
AID_GRAPHICS 1003 /* graphics devices */
AID_INPUT 1004 /* input devices */
AID_AUDIO 1005 /* audio devices */
AID_CAMERA 1006 /* camera devices */
AID_LOG 1007 /* log devices */
AID_COMPASS 1008 /* compass device */
AID_MOUNT 1009 /* mountd socket */
AID_WIFI 1010 /* wifi subsystem */
AID_ADB 1011 /* android debug bridge (adbd) */
AID_INSTALL 1012 /* group for installing packages */
AID_MEDIA 1013 /* mediaserver process */
AID_DHCP 1014 /* dhcp client */
AID_SHELL 2000 /* adb and debug shell user */
AID_CACHE 2001 /* cache access */
AID_DIAG 2002 /* access to diagnostic resources */
/* The 3000 series are intended for use as supplemental group id's only. */
/* They indicate special Android capabilities that the kernel is aware of. */
AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */
AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap sockets */
AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */
AID_NET_RAW 3004 /* can create raw INET sockets */
AID_MISC 9998 /* access to misc storage */
AID_NOBODY 9999
AID_APP 10000 /* first app user */
"root", AID_ROOT
"system", AID_SYSTEM
"radio", AID_RADIO
"bluetooth", AID_BLUETOOTH
"graphics", AID_GRAPHICS
"input", AID_INPUT
"audio", AID_AUDIO
"camera", AID_CAMERA
"log", AID_LOG
"compass", AID_COMPASS
"mount", AID_MOUNT
"wifi", AID_WIFI
"dhcp", AID_DHCP
"adb", AID_ADB
"install", AID_INSTALL
"media", AID_MEDIA
"shell", AID_SHELL
"cache", AID_CACHE
"diag", AID_DIAG
"net_bt_admin", AID_NET_BT_ADMIN
"net_bt", AID_NET_BT
"inet", AID_INET
"net_raw", AID_NET_RAW
"misc", AID_MISC
"nobody", AID_NOBODY
You will need to also understand the way file permissions are represented:
Example = drwxrwxrwx
-Use 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:
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
Most of the time you set "Read" and "eXecute" together on directories (kind of useless when set by themselves)
Interestingly through further research it seems this system is based on the Octal Binary system...I may be wrong...
Code:
Octal
Binary is also easily converted to the octal numeral system, since octal uses a radix of 8, which is a power of two (namely, 23, so it takes exactly three binary digits to represent an octal digit).
The correspondence between octal and binary numerals is the same as for the first eight digits of hexadecimal in the table above.
Binary 000 is equivalent to the octal digit 0, binary 111 is equivalent to octal 7, and so forth.
Octal Binary
0 000
1 001
2 010
3 011
4 100
5 101
6 110
7 111
Converting from octal to binary proceeds in the same fashion as it does for hexadecimal:
658 = 110 1012
178 = 001 1112
And from binary to octal:
1011002 = 101 1002 grouped = 548
100112 = 010 0112 grouped with padding = 238
And from octal to decimal:
658 = (6 × 81) + (5 × 80) = (6 × 8) + (5 × 1) = 5310
1278 = (1 × 82) + (2 × 81) + (7 × 80) = (1 × 64) + (2 × 8) + (7 × 1) = 8710
Flash boot partition
This uses the following command but with some caveats:
Code:
write_raw_image("path to boot.img", "boot");
An example of this commands use would be to flash a custom kernel, as far as I can tell though you need to place the boot.img in a temp file before the actual flash (clarification on this would be helpful). You would therefore use the following commands as part of your edify script:
Code:
package_extract_file("boot.img","/tmp/boot.img");
write_raw_image("/tmp/boot.img", "device-specific-boot-partition-mount-point");
delete("/tmp/boot.img");
It seems this may only be for specific handsets though e.g HTC, having looked through quite a few updater-script files from maguro zips it seems this can just be flashed directly with the following command:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
Many thanks for further clarification on this particular command from efrant below:
I feel more comfortable using something like this:
Code:
package_extract_file("boot.img", "/tmp/boot.img");
run_program("/sbin/busybox", "dd", "if=/tmp/radio.img", "of=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
delete("/tmp/boot.img")
The second line is using the "dd" command to flash the image.
The dd command (included in busybox) is:
Code:
dd if=xxx of=yyy
where xxx is the source image/partition and yyy is the target image/partition. So, for example, to flash a radio image stored in /sdcard called xxlf1.img to a GNex, it would be:
Code:
busybox dd if=/sdcard/xxlf1.img of=/dev/block/platform/omap/omap_hsmmc.0/by-name/radio (I've added "busybox" the the beginning, just to be explicit.)
So, to put it in edify format, it becomes:
Code:
run_program("/sbin/busybox", "dd", "if=/sdcard/xxlf1.img", "of=/dev/block/platform/omap/omap_hsmmc.0/by-name/radio");
However, as I said, I believe your one line:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
would work.
Further Commands:
In progress...
So, this is by no means an exhaustive list and I would appreciate it that if I have made any mistakes people make me aware in this thread and I can update this tutorial.
I would also like to add further commands and their uses, if people can provide more I will add them too.
I hope this helps people out! Many thanks!

Thx for your work. Will try it when I back @ home.
Mfg Daniel
Gesendet von meinem Galaxy Nexus mit Tapatalk 2

very interesting 3ad.i'm learning right now how to make these,yours guide resolve me a lot of questions!thanks mate!+1

Awesome. Thank you!

Thanks for the feedback folks!
Top post updated with guides for:
Signing ZIP files
Creating private ZIP signing keys

I have updated the second post with edify commands:
Contents:
Post #1: Tutorials
Post #2: Edify Commands
I would like to expand and update this information to help both others and myself learn, if people can help with more commands or any corrections this would be much appreciated!

Thanx a lot . Ive been looking into editing apks and themeing and this answers a lot of my questions. Exactly what I've been looking for.
Sent from my Galaxy Nexus using XDA

graffitiwriter said:
Thanx a lot . Ive been looking into editing apks and themeing and this answers a lot of my questions. Exactly what I've been looking for.
Click to expand...
Click to collapse
Many thanks for the feedback.
Everything I know about Android has been learned from internet research and tutorials. So as far as I can I like to then re-share the things I have learned in way that I understand in the hope it will in turn help others!

wilskywalker said:
Many thanks for the feedback.
Everything I know about Android has been learned from internet research and tutorials. So as far as I can I like to then re-share the things I have learned in way that I understand in the hope it will in turn help others!
Click to expand...
Click to collapse
Me too. What I've been doing is opening other people's flashable .zips and making changes that I needed to make so I can flash what I wanted to flash. I have something that I want to change in a ROM I've been helping to work on, and your guide will help in the setup process.

dsmryder said:
Me too. What I've been doing is opening other people's flashable .zips and making changes that I needed to make so I can flash what I wanted to flash. I have something that I want to change in a ROM I've been helping to work on, and your guide will help in the setup process.
Click to expand...
Click to collapse
Glad my guide helped out buddy! This community has helped me to learn so much, it's nice to give something back.

I'm looking to create a script that deletes system apps/sounds I don't want upon updating CM9 (nightly). I've taken a script from a different device and modified, what I hope is, accordingly. I only edited the mounts to: ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name /system and of course the apps I want to delete upon first boot. Edit removed the detailed path as per someone's advice.
Does this look like it will accomplish my objective?
Edit: Annnnnnnd it doesn't.
Code:
#!/system/bin/sh
#mount system rw
mount -o remount, rw -t /system
#apps to delete
#send installed apps to /data/packages
pm list packages -f > /data/packages
for i in HoloSpiralWallpaper LiveWallpapers LiveWallpapersPicker MagicSmokeWallpapers Music PhaseBeam RomManager VisualizationWallpapers
do
if [ -e /system/app/$i.apk ]
then
rm -f /system/app/$i.apk
grep $i.apk /data/packages > /data/pname
pname2=$(sed 's/\(.*=\)\(.*\)/\2/' /data/pname)
pm uninstall $pname2
fi
done
rm -f /data/packages
rm -f /data/pname
#delete camera_click sound
if [ -e /system/media/audio/ui/camera_click.ogg ]
then
rm -f /system/media/audio/ui/camera_click.ogg
fi
#delete camera_focus sound
if [ -e /system/media/audio/ui/camera_focus.ogg ]
then
rm -f /system/media/audio/ui/camera_focus.ogg
fi
#mount system ro
mount -o remount,ro -t /system
Source: http://forum.xda-developers.com/showthread.php?t=1050288

CMNein said:
I'm looking to create a script that deletes system apps/sounds I don't want upon updating CM9 (nightly). I've taken a script from a different device and modified, what I hope is, accordingly. I only edited the mounts to: ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name /system and of course the apps I want to delete upon first boot. Edit removed the detailed path as per someone's advice.
Does this look like it will accomplish my objective?
Edit: Annnnnnnd it doesn't.
Code:
#!/system/bin/sh
#mount system rw
mount -o remount, rw -t /system
#apps to delete
#send installed apps to /data/packages
pm list packages -f > /data/packages
for i in HoloSpiralWallpaper LiveWallpapers LiveWallpapersPicker MagicSmokeWallpapers Music PhaseBeam RomManager VisualizationWallpapers
do
if [ -e /system/app/$i.apk ]
then
rm -f /system/app/$i.apk
grep $i.apk /data/packages > /data/pname
pname2=$(sed 's/\(.*=\)\(.*\)/\2/' /data/pname)
pm uninstall $pname2
fi
done
rm -f /data/packages
rm -f /data/pname
#delete camera_click sound
if [ -e /system/media/audio/ui/camera_click.ogg ]
then
rm -f /system/media/audio/ui/camera_click.ogg
fi
#delete camera_focus sound
if [ -e /system/media/audio/ui/camera_focus.ogg ]
then
rm -f /system/media/audio/ui/camera_focus.ogg
fi
#mount system ro
mount -o remount,ro -t /system
Source: http://forum.xda-developers.com/showthread.php?t=1050288
Click to expand...
Click to collapse
Hey buddy,
This looks like an init.d script to me, this is different to Edify. init.d scripts are placed in the /system/etc/init.d folder and performs actions when you boot the phone.
Your post has piqued my interest in init.d scripting though, might have to make it my next thing to learn!

wilskywalker said:
Hey buddy,
This looks like an init.d script to me, this is different to Edify. init.d scripts are placed in the /system/etc/init.d folder and performs actions when you boot the phone.
Your post has piqued my interest in init.d scripting though, might have to make it my next thing to learn!
Click to expand...
Click to collapse
Yes init.d, wasn't sure if you'd have insight or not, but glad to have piqued your interest
Sent from my Galaxy Nexus

CMNein said:
Yes init.d, wasn't sure if you'd have insight or not, but glad to have piqued your interest
Click to expand...
Click to collapse
Sorry I couldn't help more buddy.
Interest definitely piqued though...only problem is that I am currently trying to teach myself HTML5, C++ and Edify as well...lol!
Whenever I am working on a particular project I always get sidetracked and end up trying to learn a whole new language...the only reason I started investigating Edify was so I could flash bootanimations and that led to this tutorial!

Hi, I just recently set out to teach myself making flashable zips and this was one of the more helpful guides that I found. Especially helps that it's for my phone, which eliminates a good chunk of confusion, and that it's recent, since a lot of guides that I've found seem to be a bit outdated.
However, you don't say anything about setting permissions and that's the topic that I've had the most trouble finding clear documentation for. I see it included enough that I figure that it's good practice to cover any time you're pushing files with a flash, instead of just assuming that you can run fix permissions afterwards out of habit. Without a background working with linux permissions this was all a lot to absorb, and googling terms was frustratingly unhelpful, but hopefully this goes on to help someone else.
Syntax:
Code:
set_perm (UID, GID, MODE, "PATH");
set_perm_recursive(UID, GID, DIRMODE, FILEMODE, "PATH");
So, I think I get this, but the UID and GID aspects, and the leading digit of mode still leaves me feeling like I can do this right, but not fully understand why. Here's what I'm working with:
-UID and GID set the ownership of the file/directory. List of options in android found here:
http://android-dls.com/wiki/index.php?title=Android_UIDs_and_GIDs
I've only ever seen this specified as 0 (root access) or 1000 (system access) in examples I've opened to look at. I'm not sure I entirely understand when to use 1000, but it seems like a good rule of thumb that pushing anything to a dir that usually requires root to access, set to 0.
-MODE is summed up nicely here, and it seems like for the most part you want to use a leading 0, or omit it (leave settings as is).
-And then path is just the file or directory in question. Multiple paths can be specified in the same command if desired.
So in general, a zip that pushes a file to an existing directory should include a line in the installer-script that sets the right permissions. Android seems to keep things pretty simple, so chances are you can browse to the directory and just check the permissions for anything there and use them. For example, everything in /system/app is set to rw-r--r--, which is 644. So if you wanted to push a file to /system/app, you'd use this:
Code:
set_perm (0, 0, 0644, "/system/app/[filename]");
.
If you are pushing multiple files to /system/app, you could use this:
Code:
set_perm (0, 0, 0644 "/system/app/[filename1]", "system/app/[filename2]");
Edit: I'm not sure I see an easy way to use set_perm_recursive to just cover all bases unless you're dealing with a folder that you know has only one uniform permission setting across the board (such as /system/app or /data/app). But if you're pushing a bunch of system apps, for example, you could use this:
Code:
set_perm_recursive (0, 0, 0755, 0644 "/system/app");
and it should have the same effect on the /system/app folder as just running fix permissions in recovery would do.
If I have anything wrong here please let me know. Gonna go tinker with it and try to make a working zip now as a test.

JoeSyr said:
Hi, I just recently set out to teach myself making flashable zips and this was one of the more helpful guides that I found. Especially helps that it's for my phone, which eliminates a good chunk of confusion, and that it's recent, since a lot of guides that I've found seem to be a bit outdated.
However, you don't say anything about setting permissions and that's the topic that I've had the most trouble finding clear documentation for...
...If I have anything wrong here please let me know. Gonna go tinker with it and try to make a working zip now as a test.
Click to expand...
Click to collapse
Ahh, permissions, this is my next set of commands in post #2. I really don't understand the whole permissions thing currently, so was having trouble writing it in simple terms for all to understand...if that makes sense!?
If you are happy, I would like to include your findings in the second post with all the commands (I may re-word/re-order etc for clarity as we learn more) I will of course credit you for all your help!?
I am literally trying to learn about setting permissions currently as well so its great to collaborate, this was what I was hoping for when I started this tutorial.

Ok, I have been researching Android file permissions and commands all afternoon, there really is not much documentation to be found.
I have found the info I think I need to add this to my tutorial, just need to make sense of it myself first and put it in some sort of understandable order!
Big update coming soon...

wilskywalker said:
Ahh, permissions, this is my next set of commands in post #2. I really don't understand the whole permissions thing currently, so was having trouble writing it in simple terms for all to understand...if that makes sense!?
If you are happy, I would like to include your findings in the second post with all the commands (I may re-word/re-order etc for clarity as we learn more) I will of course credit you for all your help!?
I am literally trying to learn about setting permissions currently as well so its great to collaborate, this was what I was hoping for when I started this tutorial.
Click to expand...
Click to collapse
Yes by all means feel copy and/or adapt anything I've written, and if I give the impression that I know what I'm talking about I'm happy to try and explain things as well.
I'll let you decide for yourself how much of an explanation you want to include in your guide, personally I'm going through and teaching myself a lot here, but I think I've just about figured out what you *need to know* to use the set_perm function in edify. You basically need one tool and the ability to do basic math in your head:
-Use 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).
-The permission string is a nine-character string. It is rwx repeated three times, each of which stands for one number. Within each rwx block, read r as 4, w as 2, and x as 1. A dash indicates 0 instead of whichever number. So, learn to read rwxrwxrwx as (4+2+1)|(4+2+1)|(4+2+1)=777; rwxr-xr-- is (4+2+1)|(4+0+1)|(4+0+0)=754, etc. This is what you enter for MODE, with one additional note:
-MODE is technically a 4-bit string, but the first bit is special and can be omitted. I've looked around, and have yet to find a single file on my phone that has anything set for the first bit. 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).
As another note, I personally use ES File Explorer w/ root access in my day-to-day tasks because I like the interface, but it will not give you UID or GID, or let you chance these settings.
For really understanding why this is all done this way, I think it helps to really get a grasp for why linux permissions work the way that they do (read this page) and how they are manipulated (this page). Then, consider that a lot of that is built on the assumption that there are multiple humans in the same environment, but android is built on the premise of one person and their phone. Security is largely reduced to limiting the abilities of apps (which all get their own user id, as though apps are a bunch of people signing into computers and trying to look at each others' files). Groups are pre-defined here, and the usual setup is that apps get to effectively request group permissions when installed, otherwise most things in userland don't get access to much other than writing and reading the sdcard.
Sort of makes you appreciate the work done to get phones rooted and turn them from a pallet of pre-defined actions set by OEMs into real computers.

wilskywalker said:
...
Format a partition:
To format a partition you need to use the following syntax:
Code:
format("filesystem-type", "partition-type", "device-specific-location", "0");
Example:
Code:
format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0");
Some scripts include the "0" and some do not, not sure exactly on the function difference when included or not, again clarification would be great.
...
Click to expand...
Click to collapse
How to format boot? There is no that menu in CWM and TWRP

[Q][Info][Tab3] System Dump / Kitchen

I'm trying to pull a system dump to make a Back it in kitchen for the Tab3 10.1
I did a ton of reading on this device, since there is not much developing with it
I pulled a Firmware/ system dump from My Samsung Galaxy Tab 3 10.1
GT-P5210 JDQ39.P5210UEUAMK1
It's rooted with recovery only
After pulling the dump I was able to load it up into kitchen
I loaded up the following three files:
boot.img, cache.img, and system.img
fired up the kitchen Set up working folder as usual
extracted it (no errors)
Added root permissions
Added Busybox
Added /etc/init.d script support
De-odex
zipalign all the APK's
updated the mounting point in the updater-script
Code:
unmount("/system");
format("ext4", "EMMC", "/dev/block/mmcblk0p8", "0");
mount("ext4", "EMMC", "/dev/block/mmcblk0p8", "/system");
-------------------------------------------------------------------------------------
I flashed it in recovery (seemed to have flashed) But when it reboots it just sits @ the boot screen.
Now I'm trying to figure out where i went wrong.
does below look correct?
are the commands i used correct?
Mounting points seem correct ?
I'm 99% sure the mounting points are correct..
I'm 50% sure I used the correct commands to create the sys dump etc
I'm not sure why the recovery img and boot img are the same exact size
(is it normal for the boot.img and the recovery.img to be the same exact size?)
I baked it in kitchen. with out any errors
here are the mounting points I used
1 '/efs' 'ext4' '/dev/block/mmcblk0p2'
2 '/config' 'ext4' '/dev/block/mmcblk0p3'
3 '/cache' 'ext4' '/dev/block/mmcblk0p6'
4 '/system' 'ext4' '/dev/block/mmcblk0p8'
5 '/data' 'ext4' '/dev/block/mmcblk0p9'
6 '/recovery' 'emmc' '/dev/block/mmcblk0p11'
7 '/modem' 'emmc' '/dev/block/mmcblk0p12'
8 '/preload' 'ext4' '/dev/block/mmcblk0p13'
9 '/boot' 'emmc' '/dev/block/mmcblk0p10'
10 '/sdcard' 'vfat' '/dev/block/mmcblk1p1'
I used these commands in terminal
Code:
dd if=/dev/block/mmcblk0p8 of=/mnt/extSdCard/backup/mmcblk0p8_system.img bs=4096
Code:
dd if=/dev/block/mmcblk0p10 of=/mnt/extSdCard/backup/mmcblk0p10_boot.img bs=4096
Code:
dd if=/dev/block/mmcblk0p6 of=/mnt/extSdCard/backup/mmcblk0p6_cache.img bs=4096
Code:
dd if=/dev/block/mmcblk0p12 of=/mnt/extSdCard/backup/mmcblk0p12_modem.img bs=4096
Code:
dd if=/dev/block/mmcblk0p11 of=/mnt/extSdCard/backup/mmcblk0p11_recovery.img bs=4096
So nowI ended up with
[*] mmcblk0p6_cache.img 350M
[*] mcblk0p8_system.img 2.3G
[*] mmcblk0p10_boot.img 20M
[*] mmcblk0p11_recovery.img 20M
[*] mmcblk0p12_modem.img 4.0M
etc
Any Help would be greatly appreciated

[Multi Boot] Boot Menu

Multiboot for Sony Xperia Z1
How to install boot menu
- download bootmenu_honami.rar, extract folder "bootmenu" to the your internal storage
- put boot.img or kernel.elf to the mainrom folder, make sure thats the same kernel like your primary rom (aka main rom)
- download bootmenu.img from attachment, flash bootmenu.img using fastboot commnd: fastboot flash boot bootmenu.img
Since your bootmenu folder not contain settings.ini (you runing bootmenu at a first time) that will be created easily. You need to complete main step aka main rom creation:
1. (mainrom creation) reboot into bootmenu, chose "patch...", navigate to bootmenu, navigate to mainrom, select mainrom.zip package (make sure boot.img or kernel.elf is the same like your current main rom kernel, and make sure boot.img is in folder mainrom), select mainrom.zip and click "yes". Main rom will be added into boot menu entry. Now reboot again into boot menu and you will see new menuentry, chose these menu to boot into your primary rom!
2. (other roms creation - you can do only if you completed main rom step) reboot into bootmenu, chose "patch...", principe is diferent (there is 2 steps):
- step 1: chose rom zip you want to patch, patch them
- step 2: reboot again into boot menu (new rom entry will be displayed), select these rom to boot, on led blinking press to boot into cwm, now you are in cwm of these rom, now navigate to the same folder where is your package, you will find zip with appended name "patched.zip", chose these patched zip to install trought these recovery, you are done!
If something fail, make sure look into bootmenu folder into main script aka "multiboot.sh", try to fix-improve something Enjoy!
WARNING:
- NEVER RENAME FOLDERS OR ZIP ARCHIVES TO HAVE SPACE IN NAME SINCE BOOTMENU WILL NOT WORK!!! INSTEAD OF WRITING SPACE " " WRITE "_" SOMETHING_LIKE_THIS" !
- there is possibility for your partitions of the main rom to get overwriten if multiboot.sh fail to patch these rom you going to patch, just to let you know! Two click solution is in testing stage so there is probably a lot of bugs! I am not responsible if you lost your private data! So guys if you willing to help, I am waiting. Things need to be improved in multiboot.sh !

Here is full source code of the my bootmenu project -> https://github.com/munjeni/bootmenu_z1_and_z1c
Public License for BOOTMENU and for my Auxiliary Work
You can Distribute my source without my Permissions. Distribution should include my XDA name 'munjeni' and Link to this 'BOOTMENU' thread in your Credits sections/About sections and Properly Visible to Human Eyes. If you use our source and have them modified, you need to make them public to everyone!!! If you not propertly use my source and you not give proper credit, and you not share your modified source code which is based on my source code, I will find you and I will report your post!
And... If You Like my BOOTMENU... Remember to Press...Thanks button

Credits
- @abbychauhan first one who helped me in testing boot menu, thanks!
- @krabappel2548 for kernel with kexec! I have used his kexec kernel in our boot menu for Z1, thanks!
- @HypoTurtle for sugestions, thanks!
- @DooMLoRD for opening my eyes since I had a wrong kernel on my local hard drive
- @SafiXS , @Chocolatetrain, @ntmohammad ...sory if I forgot someone, thanks to all for testing!

"Post Updated on 22/06/2014"
MultiBoot Totally Simplified (Noob Friendly)
Whole Multiboot Procedure for better understanding..
We will do this in two parts procedure as Follows -
Part 1 -
First we will do the mainrom creation. "Mainrom" - The ROM which is Currently installed on your phone.
1. First Download bootmenu_honami.rar, extract folder "bootmenu" to your Phone's Internal storage
2. Put boot.img or kernel.elf (Of the ROM which is Currently installed on your phone) to the mainrom folder (its in the bootmenu folder) of extracted rar file,
make sure thats the same kernel i.e, boot.img or kernel.elf like your primary rom of yours which is currently installed
boot.img - you can extract it from the ROM zip file or Custom Kernel zip file eg. ROM.zip or Doomloards Kernel zip
Kernel.elf - U ll have to convert kernel.sin from ROM zip file to kernel.elf via Flashtool (It has got option to do that)
3. Download bootmenu.img from attachment, flash bootmenu.img using fastboot commend: fastboot flash boot bootmenu.img
4. Reboot into bootmenu, choose "patch...", navigate to mainrom folder (it has to be in the internal memory, inside the folder bootmenu),
select mainrom.zip package (make sure boot.img or kernel.elf is the same like your current main rom kernel, and make sure boot.img or kernel.elf is in folder "mainrom" ),
select mainrom.zip and click "yes". Main rom will be added into boot menu entry.
Now reboot again into boot menu and you will see new Entry Mainrom and Mainrom - CWM, choose Mainrom from Multiboot Menu to boot into your primary rom or Choose mainrom - CWM to go into mainrom Recovery
Part 2 -
Other ROMs creation - You can do it only if you completed main rom step)
1. Reboot into bootmenu, chose "patch...",
2. Navigate to Second ROM ZIP file
(Keep it anywhere in External Memory Card Because you wont be able to access Internal Memory of your Phone via another ROM Recovery due to change of Partitions, All ROMs will be installed on Internal Memory),
Choose ROM zip you want to patch, patch them
3. Reboot again into boot menu (new ROM entry will be displayed), go into ROM - CWM to go into Recovery of the particular ROM,
Now you are in Recovery of New ROM, Go to install ZIP (Installation of ROM) and
navigate to the same folder where you kept the ROM ZIP file (on External Card Memory),
you will find a new zip with appended name "patched.zip",
chose these patched zip to install trough the Recovery,
4. Flash C6902 fix, if u have C6902 Device (keep it On External Memory too),
5. Boot into ROM then Do a REBOOT and again go to Secondary ROM - CWM
6. Flash Gapps (keep it On External Memory too)
7. Flash Any Mod or anything if you wanted to flash for Your ROM (keep it On External Memory too)
Except Custom Kernels or Something that will wipe bootmenu.img ( Its WIP you can check out the Conversations on Page 48/49/50 )
8. Do Reboot
9. In Bootmenu Select the Newly installed ROM.
You are done!
Enjoy!
Common Questions -
1. How many ROMs I can Install?
Answ - http://forum.xda-developers.com/showpost.php?p=53236187&postcount=399
2. How to go from One ROM Partation to Another ROM Partation via File Explorer?
Answ - http://forum.xda-developers.com/showpost.php?p=53318812&postcount=476
3. How to get kernel.elf?
Answ - http://forum.xda-developers.com/showpost.php?p=53234909&postcount=384
and http://forum.xda-developers.com/showpost.php?p=53234988&postcount=386
and http://forum.xda-developers.com/showpost.php?p=53235075&postcount=387
4. How to take Screenshot of CWM?
Answ - http://forum.xda-developers.com/showpost.php?p=53229901&postcount=358
and http://forum.xda-developers.com/showpost.php?p=53230193&postcount=362
5. We get ROM updates now and then how do we do it? If we want to remove The Whole Multiboot Thing or a ROM from Bootmenu and to uninstall it completely from our phone then what is the procedure?
Answ - http://forum.xda-developers.com/showpost.php?p=53076327&postcount=277
and http://forum.xda-developers.com/showpost.php?p=53077937&postcount=281
6. Stock Based ROMs ask to flash the Stripped FTF via flashtools in the END, if we keep Stock based ROMs as Secondary ROMs then how will it work then, it will wipe other ROMs Kernal and bootmenu kernal?
Answ - Its Hard but http://forum.xda-developers.com/showpost.php?p=53150024&postcount=325
and http://forum.xda-developers.com/showpost.php?p=53150187&postcount=326
7. Power Off Charging?
Answ - http://forum.xda-developers.com/showpost.php?p=53144286&postcount=322
8. The partition made by Multi Boot for other ROMs is very small, Why is that? Can it be increased?
Answ - http://forum.xda-developers.com/showpost.php?p=53116039&postcount=313
and http://forum.xda-developers.com/showpost.php?p=53118687&postcount=316
and http://forum.xda-developers.com/showpost.php?p=53118722&postcount=317
9. I want to change the name of "mainrom" and Secondary ROM names in boot menu?
Answ - http://forum.xda-developers.com/showpost.php?p=53107296&postcount=307
10. Gapps on Primary ROM?
Answ - http://forum.xda-developers.com/showpost.php?p=53027261&postcount=240
11. Main ROM Update / MainROM Kernal Change?
Answ - http://forum.xda-developers.com/showpost.php?p=53565558&postcount=571

Complicated and not for noobs, but hope some one do it for you if you are confused! Seccond tut will be more complicated since all ramdisks need to be moded specialy for every each android which you going to boot. I will try to explain

munjeni said:
Complicated and not for noobs, but hope some one do it for you if you are confused! Seccond tut will be more complicated since all ramdisks need to be moded specialy for every each android which you going to boot. I will try to explain
Click to expand...
Click to collapse
Ya this thread really need a helpful Dev. Who will answer all questions.. And Of course not for noobs.. I think i ll scratch my head all night..
Sent from my Micromax A110Q using Tapatalk

@munjeni Is this same as XGo Muilti Boot?That is very harder to install.
Sent from my C6903 using XDA Premium 4 mobile app

Awesome work :good:
Could you please give me some instructions on how to add your multiboot to a host kernel when building from source?
I'm working on a kernel for the z1, and I have krabappel's kexec patch implemented.

Androguide.fr said:
Awesome work :good:
Could you please give me some instructions on how to add your multiboot to a host kernel when building from source?
I'm working on a kernel for the z1, and I have krabappel's kexec patch implemented.
Click to expand...
Click to collapse
Simple extract ramdisk and make boot.img with your kernel! I will upload new version now, version v1.1 (support for booting from booth internal and external sdcard)! Since booting from extrernal sdcard sause some lags if sd cards is not "best speed", recomended is booting from internal sdcard since performance is the same like booting from regular boot! Wait a moment, going to upload new version in next 10 minutes! When I get more free time I will give you preconfigured menu entry with installed CM11 into file partitions so you can multiboot them without needs for lookig into our tutorials, you will simple extract them and boot

New version of the bootmenu is out, enjoy!
Changelog:
- support for booting from booth internal or external sdcard
- fixed bug with reboot timer when there is no rom in settings ini or when there is no bootmenu folder

I'll try to release the multiboot I was working on. It is a lot easier for users then all this editing probably
Sent from my C6903 using xda app-developers app

krabappel2548 said:
I'll try to release the multiboot I was working on. It is a lot easier for users then all this editing probably
Sent from my C6903 using xda app-developers app
Click to expand...
Click to collapse
We all will be very thankful to u
Sent from my Xperia Z1 using Tapatalk

krabappel2548 said:
I'll try to release the multiboot I was working on. It is a lot easier for users then all this editing probably
Sent from my C6903 using xda app-developers app
Click to expand...
Click to collapse
How you think to make that simple? Since external partitions is needed, allso since standard flashable zips will allso need to be modified in updater-script, allso since ramdisks need to be modified, all fstabs need to be modified, DTB need to be appended propertly to the zImage in order to boot them with kexec... a lot of other things, I think easy method is not possible definitely! Maybe a am wrong?
I have 2 ideas now for my boot menu:
- create 3 partitions (probably will open a new thread for sharing diferent partitions layout, for example cache 50mb, cache 100mb, cache 150mb, cache 200mb, system 500mb, system 1gb, system 1.6gb, data 500mb, data 1gb, data 2gb...) so after compresing them to rar size of the archive will be ~100mb
- or maybe we can implement on the fly partitions creation by the updter-script
Problem will be kernel and ramdisk since it need modification. Maybe we can ask devs to include ramdisk and kernel for multiboot in his posts.
I am out of ideas, but I think we need to make automated tool for these things. If you guys have idea please comment!
Tool needed:
- tool for extracting boot image and making zImage-dtb
- tool for extracting ramdisk, making changes needed for boot from loop device, compresing modified ramdisk
- tool for partitions creation with defined size and defined path for puting them to defined folder
- tool for entry in settings.ini creation

Partition creation is easy. There is few steps to create file based partition:
1. first of all - how to calculate size of the partition:
Simple using calculator. Formula is: (size * 1024 * 1024) / 4096
Foe example: you want 500mb partition, ok, formula is: (500 * 1024 * 1024) / 4096
So command for making them with adb will be:
adb shell
mkdir /data/media/0/bootmenu/folder_you_want
dd if=/dev/zero of=/data/media/0/bootmenu/folder_you_want/system.ext4 bs=4096 count=count_from_your_calculation
dd if=/dev/zero of=/data/media/0/bootmenu/folder_you_want/data.ext4 bs=4096 count=count_from_your_calculation
dd if=/dev/zero of=/data/media/0/bootmenu/folder_you_want/cache.ext4 bs=4096 count=count_from_your_calculation
Click to expand...
Click to collapse
2. get UUID of the system partition (need for step 3):
blkid /dev/block/platform/msm_sdcc.1/by-name/system
Click to expand...
Click to collapse
3. format created partiton:
losetup /dev/block/loop1 /data/media/0/bootmenu/folder_you_want/system.ext4
losetup /dev/block/loop2 /data/media/0/bootmenu/folder_you_want/data.ext4
losetup /dev/block/loop3 /data/media/0/bootmenu/folder_you_want/cache.ext4
mke2fs -T ext4 -O has_journal,ext_attr,resize_inode,filetype,extent,sparse_super,large_file,uninit_bg -U paste here your UUID -I 256 /dev/block/loop1
mke2fs -T ext4 -O has_journal,ext_attr,resize_inode,filetype,extent,sparse_super,large_file,uninit_bg -U paste here your UUID -I 256 /dev/block/loop2
mke2fs -T ext4 -O has_journal,ext_attr,resize_inode,filetype,extent,sparse_super,large_file,uninit_bg -U paste here your UUID -I 256 /dev/block/loop3
tune2fs -o journal_data_writeback /dev/block/loop2
tune2fs -o journal_data_writeback /dev/block/loop3
losetup -d /dev/block/loop1
losetup -d /dev/block/loop2
losetup -d /dev/block/loop3
Click to expand...
Click to collapse
Partitions created easily
Note:
These things must be done while you are in bootmenu since I am not sure if mke2fs, blkid and tune2fs tool is available while you are on android! So you can done that in bootmenu via adb!

CWM ramdisk modifications
all fstabs need to be modified, for example fstab.qcom:
Code:
/dev/block/platform/msm_sdcc.1/by-name/boot /boot emmc defaults recoveryonly
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 noatime,nosuid,nodev,barrier=1,data=ordered,nomblk_io_submit,noauto_da_alloc,errors=panic wait,check
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,nomblk_io_submit,noauto_da_alloc,errors=panic wait,check,encryptable=footer,length=-16384
remove line:
/dev/block/platform/msm_sdcc.1/by-name/boot /boot emmc defaults recoveryonly
Click to expand...
Click to collapse
changed:
Code:
/dev/block/loop1 /system ext4 ro,barrier=1 wait
/dev/block/loop3 /cache ext4 noatime,nosuid,nodev,barrier=1,data=ordered,nomblk_io_submit,noauto_da_alloc,errors=panic wait,check
/dev/block/loop2 /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,nomblk_io_submit,noauto_da_alloc,errors=panic wait,check,encryptable=footer,length=-16384
In etc you can see another recovery.fstab, change them like you done for qcom.fstab!
init.rc:
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
write /sys/class/android_usb/android0/iManufacturer ${ro.product.manufacturer}
write /sys/class/android_usb/android0/iProduct ${ro.product.model}
write /sys/class/android_usb/android0/iSerial ${ro.serialno}
on boot
ifup lo
hostname localhost
domainname localdomain
Click to expand...
Click to collapse
add:
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
write /sys/class/android_usb/android0/iManufacturer ${ro.product.manufacturer}
write /sys/class/android_usb/android0/iProduct ${ro.product.model}
write /sys/class/android_usb/android0/iSerial ${ro.serialno}
on fs
wait /dev/block/platform/msm_sdcc.1/by-name/userdata
mkdir /sde
mount ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata /sde rw wait
exec /sbin/losetup /dev/block/loop1 /sde/media/0/bootmenu/cm11/system.ext4
exec /sbin/losetup /dev/block/loop2 /sde/media/0/bootmenu/cm11/data.ext4
exec /sbin/losetup /dev/block/loop3 /sde/media/0/bootmenu/cm11/cache.ext4
on boot
ifup lo
hostname localhost
domainname localdomain
Click to expand...
Click to collapse
red line "cm11" mean that you have created cm11 folder in boot menu and use these folder for example for booting into cm11! On these "cm11" folder you have created partitons, ramdisks, kernel...etc!

munjeni said:
Problem will be kernel and ramdisk since it need modification. Maybe we can ask devs to include ramdisk and kernel for multiboot in his posts.
Click to expand...
Click to collapse
Yes that will do some work for the people.. Atleast Custom Kernal Devs can include it.
Sent from my Xperia Z1 using Tapatalk

ROM ramdisk modifications
For example CM11 ramdisk.
when you unpack cm11 boot.img, when you unpack ramdisk you will notice 2 ramdisks, one is rom ramdisk and one is recovery ramdisk (ramdisk.cpio and ramdisk.recovery.cpio). Look into previous post for CWM ramdisk modification.
Modification for ROM ramdisk (ramdisk.cpio):
init.rc file:
look for line "mkdir /system", added one line before these line: "mkdir /sde"
fstab.qcom:
the same like you done on CWM ramdisk!
init.qcom.rc:
look for lines:
on fs
mount_all ./fstab.qcom
setprop ro.crypto.fuse_sdcard true
Click to expand...
Click to collapse
add:
on fs
wait /dev/block/platform/msm_sdcc.1/by-name/userdata
mkdir /sde
mount ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata /sde rw wait
exec /sbin/losetup /dev/block/loop1 /sde/media/0/bootmenu/cm11/system.ext4
exec /sbin/losetup /dev/block/loop2 /sde/media/0/bootmenu/cm11/data.ext4
exec /sbin/losetup /dev/block/loop3 /sde/media/0/bootmenu/cm11/cache.ext4
exec /sbin/e2fsck -y /dev/block/loop2
exec /sbin/e2fsck -y /dev/block/loop3
mount_all ./fstab.qcom
setprop ro.crypto.fuse_sdcard true
Click to expand...
Click to collapse
red line "cm11" mean that you have created cm11 folder in boot menu and use these folder for example for booting into cm11! On these "cm11" folder you have created partitons, ramdisks, kernel...etc!

updater script in rom zip modification
For example you want to install cm11 in multiboot, ok, download an rom, for example download CM11 by FXP or one by Cyanogenmod, open zip, find, open and modify updater-script and change all lines:
1. for system:
Code:
.........."/dev/block/platform/msm_sdcc.1/by-name/system"............
change to:
Code:
.............."/dev/block/loop1"..............
2. for userdata:
Code:
............."/dev/block/platform/msm_sdcc.1/by-name/userdata"............
change to:
Code:
..........."/dev/block/loop2"................
3. for cache:
Code:
........"/dev/block/platform/msm_sdcc.1/by-name/cache"..........
change to:
Code:
..........."/dev/block/loop3"...........
4. for boot:
Code:
.........."/dev/block/platform/msm_sdcc.1/by-name/boot".........
change to:
Code:
............"/dev/null"...........
Note:
To understand this step. You doing these modifications since you going to install rom to partitions which you created on your internal sdcard! For example: if you not modify ramdisk, your rom will be installed to your phone partitions instead of one created by you! So to install rom to partitions which you have created, you must modify updater script to point installation to install rom into partitions which you created earlier instead of intalling them to regular partition! If you install rom to regular partitions that mean you will overwrite your main rom and bootmenu, so you will boot into cm11 on reboot instead of buting into multiboot! Hope thing clear?

Creating menuentry for new rom in multiboot (boot menu) settings.ini
Since you created partitions, since you modified ramdsiks, since you created kernel (sorry I removed post entry related to kernel modification... I will instruct you later!), since you modified rom zip which you want to install... you are ready for flashing! Before flashing rom to partitions, you need to add menu entry in settings.ini of the bootmenu!
How to add new rom entry to boot menu:
For example you created all partitons in .../bootmenu/cm11 folder
For example you have system.ext4, data.ext4, cache.ext.4, initrd.gz (modified cm11 ramdisk), and Zimage-dtb (modified CM11 zImage) in cm11 folder
Ok now you can add menuentry to setting.ini:
[rom-1]
menutitle=CM11
kernel=/data/media/0/bootmenu/cm11/zImage-dtb
ramdisk=/data/media/0/bootmenu/cm11/initrd.gz
cmdline=no_need_anymore
Click to expand...
Click to collapse
You are done! Title you have defined in "menutitle" will be displayed in boot menu!
Now you need to boot into cm11. When you boot into cm11 you will get "timing for recovery boot, led light!", if everything is propertly modified in all of the things you will get lucky to see led light where you need to pres volume button to get into recovery! If you enter into cm11 recovery that mean that you are in sucess , Ok now install your modified rom zip package (in these step cm11 will be installed to partitions which you have created earlier) and you are done! Reboot and enjoy cm11 in multiboot! The same steps is for all roms which you want in multi boot! Max roms is 10!

Not for noobs but hope our things is clear now for experienced users?

Help with unpacking system apps

Hello everybody .. Hiw i can unpack lollipop system.dat file??

@Skin1980

@S3V3N

Akhayev said:
@Skin1980
Click to expand...
Click to collapse
system.dat? Explain better pls

Skin1980 said:
system.dat? Explain better pls
Click to expand...
Click to collapse
I am sorry .. I downloaded cm12 that based on lollipop and when i opened the rom theres a file named system.new.dat and all the apps inside this file and i wants to port some apps from this file but i cant open it cos its .dat file

Akhayev said:
I am sorry .. I downloaded cm12 that based on lollipop and when i opened the rom theres a file named system.new.dat and all the apps inside this file and i wants to port some apps from this file but i cant open it cos its .dat file
Click to expand...
Click to collapse
try to mount it

Skin1980 said:
try to mount it
Click to expand...
Click to collapse
7zip cannot extract a system.new.dat file and DAEMON tools cannot mount it. I'm hoping ROM devs release their ROMs with the standard format but if they don't, I'm sure someone from the community will easily find a way to extract them.

CM12 system.new.dat apps
Hi,
I had downloaded CM12 just now. There are no apks but only 1-img and 1-dat files in which "system.new.dat" file contains the stuff. Please provide a way to extract apks from system.new.dat file.

Unpack
Anyone figure how to do this?

I would like to know this as well.

I don't know for stock, I'm searching how to do it, but for cm12, you can compile from source directly, there is a thread in development section.

I'm stuck too.
Habaddon said:
I don't know for stock, I'm searching how to do it, but for cm12, you can compile from source directly, there is a thread in development section.
Click to expand...
Click to collapse
This is a chicken and egg problem for me. I want to build a ROM but first want to extract the device firmware for my ROM. (I don't have access to the Nexus 4 phone to install a ROM on and then extract the firmware.)
I've been Googling for a solution without luck.
Followed a clue. I uncommented a debug print statement in simg2img. No luck.
Code:
$ file system.new.dat
system.new.dat: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)
$ simg2img.py system.new.dat system.new.raw
424620032
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Not a compressed ext4 file!!
Any ideas?

Yeah, I tried that too, it doesn't work. I ask a dev, in fact, it is simple. All you need to do is mount the img.
mkdir system
sudo mount system.img system
Click to expand...
Click to collapse

Still stuck
Habaddon said:
Yeah, I tried that too, it doesn't work. I ask a dev, in fact, it is simple. All you need to do is mount the img.
Click to expand...
Click to collapse
I'm still confused.
I suspect that the system.new.dat is not a simple image file and is most probably signed in some way. I don't know why the file command says that it is an ext4 filesystem while simg2img.py, with the debug statement which prints the first bytes uncommented, prints only nulls.
BTW, I asked my relative who owns the device to try flashing this ROM and it didn't work because of a known problem whereby rooting was lost. He will try a new ROM.
Plan B will be to pull the firmware via adb but I'm certainly curious about the new Lollipop way of packaging the ROM.
Code:
$ ls -l cm-12-20141123-UNOFFICIAL-mako.zip
-rw-r--r-- 1 zippy zippy 238444354 Dec 6 08:20 cm-12-20141123-UNOFFICIAL-mako.zip
$ unzip cm-12-20141123-UNOFFICIAL-mako.zip
Archive: cm-12-20141123-UNOFFICIAL-mako.zip
signed by SignApk
extracting: system.patch.dat
inflating: META-INF/com/android/metadata
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/org/cyanogenmod/releasekey
inflating: boot.img
inflating: file_contexts
inflating: [COLOR="Red"]system.new.dat[/COLOR]
inflating: system.transfer.list
inflating: system/bin/backuptool.functions
inflating: system/bin/backuptool.sh
inflating: system/bin/otasigcheck.sh
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
$ ls -l system.new.dat
-rw-rw-r-- 1 zippy zippy 424620032 Feb 29 2008 system.new.dat
$ file system.new.dat
system.new.dat: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)
$ rm -rf # remove the extracted system directory from above
$ mkdir system
$ sudo mount system.new.dat system
[sudo] password for zippy:
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
$ dmesg | tail -2
[89035.798766] loop: module loaded
[89035.906824] EXT4-fs (loop0): bad geometry: block count 215040 exceeds size of device (103667 blocks)

I wonder why nobody put up a way to modify this?
I kept looking for the solution from the day lollipop releases, but without any success.
:crying:

Investigating ...
I know more now.
Below is the update-script which calls functions in the update-binary. I highlighted the code in question. This is obviously not a simple filesystem in the system.new.dat. I've hacked at it with ext4.fsck and resize2fs with no luck.
Code:
assert(getprop("ro.product.device") == "mako" || getprop("ro.build.product") == "mako" || abort("This package is for device: mako; this device is " + getprop("ro.product.device") + "."););
ifelse(is_mounted("/system"), unmount("/system"));
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
package_extract_file("system/bin/backuptool.sh", "/tmp/backuptool.sh");
package_extract_file("system/bin/backuptool.functions", "/tmp/backuptool.functions");
set_metadata("/tmp/backuptool.sh", "uid", 0, "gid", 0, "mode", 0755);
set_metadata("/tmp/backuptool.functions", "uid", 0, "gid", 0, "mode", 0644);
run_program("/tmp/backuptool.sh", "backup");
unmount("/system");
if is_mounted("/data") then
package_extract_file("system/bin/otasigcheck.sh", "/tmp/otasigcheck.sh");
package_extract_file("META-INF/org/cyanogenmod/releasekey", "/tmp/releasekey");
set_metadata("/tmp/otasigcheck.sh", "uid", 0, "gid", 0, "mode", 0755);
run_program("/tmp/otasigcheck.sh") != "31744" || abort("Can't install this package on top of incompatible data. Please try another package or run a factory reset");
else
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/userdata", "/data", "");
package_extract_file("system/bin/otasigcheck.sh", "/tmp/otasigcheck.sh");
package_extract_file("META-INF/org/cyanogenmod/releasekey", "/tmp/releasekey");
set_metadata("/tmp/otasigcheck.sh", "uid", 0, "gid", 0, "mode", 0755);
run_program("/tmp/otasigcheck.sh") != "31744" || abort("Can't install this package on top of incompatible data. Please try another package or run a factory reset");
unmount("/data");
endif;
show_progress(0.750000, 0);
[COLOR="red"]block_image_update("/dev/block/platform/msm_sdcc.1/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");[/COLOR]
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
delete("/system/bin/otasigcheck.sh");
unmount("/system");
show_progress(0.020000, 10);
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
package_extract_file("system/bin/backuptool.sh", "/tmp/backuptool.sh");
package_extract_file("system/bin/backuptool.functions", "/tmp/backuptool.functions");
set_metadata("/tmp/backuptool.sh", "uid", 0, "gid", 0, "mode", 0755);
set_metadata("/tmp/backuptool.functions", "uid", 0, "gid", 0, "mode", 0644);
run_program("/tmp/backuptool.sh", "restore");
delete("/system/bin/backuptool.sh");
delete("/system/bin/backuptool.functions");
unmount("/system");
show_progress(0.050000, 5);
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
show_progress(0.200000, 10);
Next, one can look in the source code and try to figure out what it is doing.
Or maybe the next step is to see if there is a host build (i.e. Ubuntu, Fedora, etc) of the binary-update which can be run from the command line into a file which can be mounted.
I'm sure that there is an easy way but finding it is difficult!

Ext2Explorer, Diskinternals Linux Reader can mount, read and extract those system images. But I m not sure if they are fully compatible because in both of these apps which I tried priv-app and some other folders are shown empty. I don't know if normaly there are files in these folders or not.

I've been struggling with these system.new.dat block images since lollipop came out since I need to convert roms to flash onto F2FS system partitions. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... Luckily I've an extra device at my disposal atm. These are the steps I take:
Clean flash a lollipop rom that has a system.new.dat image in twrp.
Reboot system.
When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
In twrp make a backup of only the system partition.
Boot back to system and use the method you prefer to move the file system.ext4.win from /TWRP/BACKUPS/-ur-device-serial/-ur-backup-date on to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can now do with that as you please. :silly:

Well googling i found this solution http://forum.xda-developers.com/nexus-7/general/guide-unpack-dat-t2970707 @adomol:
I've been struggling with these system.new.dat block images since lollipop came out. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... These are the steps I take:
1.Clean flash a lollipop rom that has a system.new.dat image in twrp.
2.Reboot system.
3.When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
4.In twrp make a backup of only the system partition.
5.Boot back to system and use the method you prefer to move the file system.ext4.win from:
/TWRP/BACKUPS/-ur-device-serial/-ur-backup-date
to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can do with that as you please, or just throw it into a rom kitchen.
all credits to @adomol

adomol said:
I've been struggling with these system.new.dat block images since lollipop came out since I need to convert roms to flash onto F2FS system partitions. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... Luckily I've an extra device at my disposal atm. These are the steps I take:
Clean flash a lollipop rom that has a system.new.dat image in twrp.
Reboot system.
When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
In twrp make a backup of only the system partition.
Boot back to system and use the method you prefer to move the file system.ext4.win from /TWRP/BACKUPS/-ur-device-serial/-ur-backup-date on to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can now do with that as you please. :silly:
Click to expand...
Click to collapse
-droidberg- said:
Well googling i found this solution http://forum.xda-developers.com/nexus-7/general/guide-unpack-dat-t2970707 @adomol:
I've been struggling with these system.new.dat block images since lollipop came out. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... These are the steps I take:
1.Clean flash a lollipop rom that has a system.new.dat image in twrp.
2.Reboot system.
3.When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
4.In twrp make a backup of only the system partition.
5.Boot back to system and use the method you prefer to move the file system.ext4.win from:
/TWRP/BACKUPS/-ur-device-serial/-ur-backup-date
to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can do with that as you please, or just throw it into a rom kitchen.
all credits to @adomol
Click to expand...
Click to collapse
But this won't work when trying to port because you need to swap kernel's (for going between same-device, different-carrier)