xdaforums.com Open in urlscan Pro
3.214.214.173  Public Scan

URL: https://xdaforums.com/t/tutorial-making-flashable-zips-edify-script-zip-signing-key-creation-19-01-13.1611615/
Submission: On February 19 via manual from US — Scanned from US

Form analysis 2 forms found in the DOM

POST /search/search

<form action="/search/search" method="post" data-xf-init="quick-search">
  <div class="menu-row">
    <input type="text" class="input js-uix_syncValue uix_searchInput uix_searchDropdown__trigger" autocomplete="off" data-uixsync="search" name="keywords" placeholder="Search…" aria-label="Search" data-menu-autofocus="true">
  </div>
  <div class="menu-row" style="display: none;">
    <div class="inputGroup">
      <input name="keywords" class="js-uix_syncValue" data-uixsync="search" placeholder="Search…" aria-label="Search" type="hidden">
      <select name="constraints" class="js-quickSearch-constraint input" aria-label="Search within" style="width: 99px; flex-grow: 0; flex-shrink: 0;">
        <option value="{&quot;search_type&quot;:&quot;post&quot;,&quot;c&quot;:{&quot;thread&quot;:1611615}}">This thread</option>
      </select>
    </div>
  </div>
  <div class="menu-row">
    <label class="iconic"><input type="checkbox" name="c[title_only]" value="1"><i aria-hidden="true"></i><span class="iconic-label">Search titles only</span></label>
  </div>
  <div class="menu-row">
    <div class="inputGroup">
      <span class="inputGroup-text">By:</span>
      <input class="input" name="c[users]" data-xf-init="auto-complete" placeholder="Member" autocomplete="off">
    </div>
  </div>
  <div class="menu-footer">
    <span class="menu-footer-controls">
      <button type="submit" class="button--primary button button--icon button--icon--search rippleButton"><span class="button-text">Search</span></button>
      <a href="/search/" class="button rippleButton" rel="nofollow"><span class="button-text">Advanced…</span></a>
    </span>
  </div>
  <input type="hidden" name="_xfToken" value="1708371865,054d287358b4c8ac2c5e0680cca6c3ed">
</form>

<form style="display:none" hidden="hidden">
  <input type="text" name="_xfClientLoadTime" value="" id="_xfClientLoadTime" title="_xfClientLoadTime" tabindex="-1">
</form>

Text Content

 * Home
 * Forums
   
   TOPICS
   
   For Phone/Device Forums (Click/Tap) 3D Printing Android Auto Android Mods
   Android TV Apps & Games Themes Wear OS Smartwatches
   
   TOPICS
   
   Windows 11 XDA Computing Artificial Intelligence AI & Machine Learning ML
   ****Contact Us Regarding Forum or Account Issues****
 * Devices
   Phone/Device Forums (Click/Tap) Asus News Asus Forums Google News Google
   Forums HTC News HTC Forums Honor News Honor Forums Huawei News Huawei Forums
   Lenovo News Lenovo Forums
   LG News LG Forums Motorola News Motorola Forums Nokia News Nokia Forums Nubia
   News Nubia Forums OnePlus News OnePlus Forums OPPO News OPPO Forums Razer
   News Razer Forums
   RealMe News RealMe Forums Samsung News Samsung Forums Sony News Sony Forums
   Vivo News Vivo Forums Xiaomi News Xiaomi Forums ZTE News ZTE Forums
 * Guides

What's new
Log in

Register
 * New posts
 * Manufacturers
 * What's new
   New posts Latest activity
 * Members
   Current visitors

Menu

Install the app
Install
 * Topics
   3D Printing Android Auto Android Mods Android TV Apps & Games Themes Wear OS
   Smartwatches Windows 11 XDA Computing

 * Terms and rules
 * Privacy
 * Security

JavaScript is disabled. For a better experience, please enable JavaScript in
your browser before proceeding.


[TUTORIAL] MAKING FLASHABLE ZIPS, EDIFY SCRIPT, ZIP SIGNING & KEY CREATION
[19.01.13]

 * Thread starter wilskywalker
 * Start date Apr 21, 2012
 * Tags edify flashable permissions themes and apps tutorial zip

 * Home
 * Forums
 * Samsung
 * Samsung Galaxy Nexus

•••

BREADCRUMB

Home Forums Samsung Samsung Galaxy Nexus

 * 1
 * 2
 * 3
 * …
   
   GO TO PAGE
   
   
   Go
 * 16

Next
1 of 16

GO TO PAGE


Go
Next Last
Search This thread
This thread
Search titles only
By:
Search Advanced…


WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * Apr 21, 2012

 * 
 * #1

[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)
 

ATTACHMENTS

 * maguroupdate.zip
   153.9 KB · Views: 3,595

Last edited: Jan 19, 2013
 * 

Reactions: DefyCM, DrXperience, nextheart and 120 others



WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * Apr 21, 2012

 * 
 * #2

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!


 
Last edited: Aug 18, 2012
 * 

Reactions: DefyCM, AsifKhan22, rajatgupta1998 and 70 others



ROADY85

MEMBER

Jun 26, 2009 38 9 Goslar

 * Apr 21, 2012

 * 
 * #3

Thx for your work. Will try it when I back @ home.


Mfg Daniel

Gesendet von meinem Galaxy Nexus mit Tapatalk 2
 
 * 

Reactions: wilskywalker and Raijynn



SERT00

SENIOR MEMBER

May 28, 2011 1,091 496 cesena,IT

 * Apr 22, 2012

 * 
 * #4

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

Reactions: wilskywalker




ARMANUV

SENIOR MEMBER

Jan 26, 2012 839 220

 * Apr 22, 2012

 * 
 * #5

Awesome. Thank you!
 
 * 

Reactions: wilskywalker



WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * Apr 23, 2012

 * 
 * #6

Thanks for the feedback folks!

Top post updated with guides for:

Signing ZIP files
Creating private ZIP signing keys


 
 * 

Reactions: waheem and ArmanUV



WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * May 4, 2012

 * 
 * #7

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!


 




GRAFFITIWRITER

SENIOR MEMBER

Oct 21, 2010 57 11 Macon Ga Google Pixel 6 Pro

 * May 5, 2012

 * 
 * #8

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
 
 * 

Reactions: wilskywalker




WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * May 5, 2012

 * 
 * #9

> 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!


 
 * 

Reactions: Crostantin


D

DSMRYDER

SENIOR MEMBER

Jan 26, 2012 101 17

 * May 5, 2012

 * 
 * #10

> 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.
 




WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * May 7, 2012

 * 
 * #11

> 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.


 
 * 

Reactions: efrant



CMNEIN

SENIOR MEMBER

Apr 23, 2012 3,181 1,483 Calgary

 * May 8, 2012

 * 
 * #12

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://xdaforums.com/showthread.php?t=1050288
 
Last edited: May 8, 2012





WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * May 9, 2012

 * 
 * #13

> 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://xdaforums.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!


 
 * 

Reactions: CMNein



CMNEIN

SENIOR MEMBER

Apr 23, 2012 3,181 1,483 Calgary

 * May 9, 2012

 * 
 * #14

> 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
 




WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * May 11, 2012

 * 
 * #15

> 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!


 



J

JOESYR

SENIOR MEMBER

Feb 7, 2012 242 86

 * May 11, 2012

 * 
 * #16

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.
 
Last edited: May 12, 2012
 * 

Reactions: Diliban and wilskywalker




WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * May 12, 2012

 * 
 * #17

> 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.


 




WILSKYWALKER

SENIOR MEMBER


Dec 30, 2009 319 413

 * May 12, 2012

 * 
 * #18

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...


 



J

JOESYR

SENIOR MEMBER

Feb 7, 2012 242 86

 * May 12, 2012

 * 
 * #19

> 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.
 
 * 

Reactions: espeon, strumcat, Diliban and 1 other person



NEXUS.PRIME

SENIOR MEMBER

Mar 14, 2012 360 120

 * May 14, 2012

 * 
 * #20

> 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
 



 * 1
 * 2
 * 3
 * …
   
   GO TO PAGE
   
   
   Go
 * 16

Next
1 of 16

GO TO PAGE


Go
Next Last
You must log in or register to reply here.

Share:
Facebook Twitter Reddit WhatsApp Email Share Link


SIMILAR THREADS

L
Post your Galaxy Nexus home screens
 * leafkicker
 * Nov 18, 2011
   716 717 718

Replies 14K
Views 4M
O
Nov 2, 2015
ohussain
 * Locked

[RECOVERY] [GN] [maguro] ClockworkMod Recovery 6.0.4.7 + Nightlies [Flashable
Zip]
 * osm0sis
 * Jul 7, 2012
   77 78 79

Replies 2K
Views 636K

Jan 5, 2015
osm0sis
[KERNEL] [TUNA] [3.0.80+] [4.2.x] [SKL v256 - KUBO r50^] [30/05] AK
 * ak
 * Sep 12, 2012
   1576 1577 1578

Replies 32K
Views 3M
S
Feb 25, 2015
Sik-1
[KERNEL] [GPL] [GN] franco.Kernel r398
 * franciscofranco
 * Nov 29, 2011
   2262 2263 2264

Replies 45K
Views 8M
C
Feb 24, 2020
Ctzokas
[SOFTKEYS] Zenyth Keys v3 - The SEXIEST keys EVER! [FLASHABLE
ZIP+ZIPTHEMER][ICS/JB]
 * arzbhatia
 * May 23, 2012
   42 43 44

Replies 870
Views 252K

Jan 30, 2015
condor97
 * Home
 * Forums
 * Samsung
 * Samsung Galaxy Nexus

•••

BREADCRUMB

Home Forums Samsung Samsung Galaxy Nexus



TOP LIKED POSTS

24 Hours All time
 * There are no posts matching your filters.
 * 123
   wilskywalker
   [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)
   
   Apr 21, 2012 View
   73
   wilskywalker
   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!
   
   
   
   Apr 21, 2012 View
   28
   T
   trevd
   Hi Folks ( Again )
   
   I figured that I just couldn't throw the idea of a test app out there and not
   do anything about it ,
   
   So I did a little hacking around with the updater-binary code and stripped
   everything out apart from the script-parsing and validation and I like to
   introduce the edify_checker v0.1 ( Not Even Close To BETA ).
   
   Feature's:
   Validates function name.
   Validates function parameter count.
   
   And that's it, for the moment but I figured it was something to be going on
   with.....
   
   I've built a windows version and linux version, I tested the windows one on a
   win7 vm. It's a command line app, so windows users, do whatever you do to run
   command line applications!
   
   Usage : edify_checker <path_to_updater-script>
   
   Example outputs:
   
   1 Invalid Argument Code
   
   Code:
   
   C:\Users\test>edify_checker.exe c:\users\test\updater-script
   edify syntax checker v0.1
   Opening Script File:c:\users\test\updater-script        File size:1711 bytes
   validating function names
   validating function parameters
   script aborted: ui_print() expects at least 1 arg, got 0
   
   
   2 Unknown Function Name
   
   Code:
   
   test@test:/home/test $ ./edify_checker /home/test/scripts/updater-script
   edify syntax checker v0.1
   Opening Script File:upater-script	File size:1887 bytes
   validating function names
   line 3 col 35: unknown function "uiprint"
   1 parse errors
   
   
   3. Parsed Successfully
   
   Code:
   
   edify syntax checker v0.1
   Opening Script File:upater-script	File size:1887 bytes
   validating function names
   validating function parameters
   script result was []
   
   
   As I mentioned this is still a very early build, I've got a couple of ideas
   of where I can take this to feature wise but I'd be open to suggestion,
   feature ideas etc.
   
   I think being able to simulate different device environments would be useful,
   i.e mount points, build properties , disk sizes etc, basically any variables
   which affect how an update executes.......
   
   Finally Here's the link to the github source tree,
   https://github.com/trevd/android_external_edify_checker, if anyone wants to
   get involved.
   
   Dec 30, 2012 View
   7
   T
   trevd
   Hi Folks.
   
   Figure I may as well share this cheeky little number I was playing around
   with
   
   
   Code:
   
   package_extract_dir("bin","/tmp");
   package_extract_dir("patches","/tmp");
   set_perm(0, 0, 0755, "/tmp/busybox");
   set_perm(0, 0, 0755, "/tmp/unpack-bootimg");
   set_perm(0, 0, 0755, "/tmp/mkbootimg");
   set_perm(0, 0, 0755, "/tmp/cpio-ramdisk.sh");
   set_perm(0, 0, 0755, "/tmp/cpio-pack-ramdisk.sh");
   run_program("/tmp/busybox", "dd", "if=/dev/block/mmcblk0p2", "of=/tmp/boot.img");
   run_program("/tmp/unpack-bootimg", "-i","/tmp/boot.img","-o","/tmp");
   run_program("/tmp/busybox", "gunzip","-d", "/tmp/ramdisk.cpio.gz");
   run_program("/tmp/busybox", "mkdir","/tmp/ramdisk");
   run_program("/tmp/cpio-ramdisk.sh", "/tmp/ramdisk","/tmp/ramdisk.cpio");
   run_program("/tmp/busybox", "patch","-p1","-i","/tmp/default.prop.patch","/tmp/ramdisk/default.prop");
   run_program("/tmp/busybox", "patch","-p1","-i","/tmp/ueventd.grouper.rc.patch","/tmp/ramdisk/ueventd.grouper.rc");
   run_program("/tmp/cpio-pack-ramdisk.sh", "/tmp/ramdisk","/tmp/new-ramdisk.cpio.gz");
   run_program("/tmp/mkbootimg", "--ramdisk","/tmp/new-ramdisk.cpio.gz","--kernel","/tmp/kernel","-o","/tmp/newboot.img");
   run_program("/tmp/busybox", "dd", "of=/dev/block/mmcblk0p2", "if=/tmp/newboot.img");
   
   
   This script demonstrates an on device method of updating the boot image
   ramdisk' while leave the kernel untouched, it uses standard patch files.
   The main gain here is if folks are using custom kernels they can still apply
   the update without too much fuss.
   
   [ devhost ] | [goo.im]
   Here is an example which applies the insecure boot image patch to the nexus-7
   grouper ramdisk , feel free to reuse the binaries for you own evil deeds!
   :laugh:
   
   This being said I wouldn't be surprised if the apply_patch edify function is
   doing something similar with the .p files It's probably something we should
   get an handle on because that may well do in one line what I've demonstrated
   here, I think there some code and tools in the AOSP source tree which create
   will create ota's given 2 update zips, I see if I can find some documentation
   on it. :good:
   
   Jan 19, 2013 View
   5
   T
   trevd
   > wilskywalker said:
   > That seems like a great idea, it would be a really useful tool for people
   > learning what all the commands do without worrying about borking their
   > phone in the test process!!
   > Click to expand...
   > Click to collapse
   
   
   Well I did make a little progress as I had an impending need to test an
   update script. so I set myself up a cheeky schroot on my linux install and
   hacked it a bit to run the android sh command ( compiled for x86, obviously)
   as it's login shell. This gave me a clean root tree to test with on my
   desktop....
   
   Obviously this is a Linux only solution, but It does the job of testing
   pretty well. Somewhat bizzarely, given my contributions to this thread, I
   rarely do anything with edify and update zips so my personal motivation to go
   any further isn't that great, I'm not seeking any glory ( or support burden )
   that goes with releasing and maintaining these sort of tools. I'm just not
   that dev. , this was more just something I thought about while having a cig
   under the stars LOL If you're using window, however , I'll look into a
   windows compatible version of the updater binary, just let me know, although
   I make no promises. It could probably be combined with cygwin or someone
   could take the reins with a .Net UI wrapper or whatever.
   
   As a little christmas treat I've attached the contents recovery based ramdisk
   for x86, contains busybox, a statically linked version of androids toolbox,
   the updater and cwm recovery. The contents can be used in combination with an
   x86 android kernel and grub2,
   
   The binaries are also good to go on any linux installation that supports
   executing 32bit binaries. Just for sh*ts and giggles you can even run full
   cwm from within linux :laugh: Basically you just need to make the framebuffer
   device in the right location
   
   
   > sudo mkdir /dev/graphics
   > sudo mknod /dev/graphics/fb0 c 29 0 # makes a framebuffer that cwm wants
   > sudo <path to recovery>
   > Click to expand...
   > Click to collapse
   
   
   You need the /res directory in your rootfs and this will wipeout your
   /etc/fstab ( it back's it up to /etc/fstab~ ), which is not good if you've
   not chroot'd
   
   Anyway I digress, but I thought I share this bit a hackery nonesense. :good:
   
   Dec 25, 2012 View


NEW POSTS

 * UPDATE ROM AC8227L - Android JCAC10003-OC2-V1.0.04R7-211119_1742
    * Latest: AmboJx1
    * 1 minute ago
   
   Android Head-Units
 * Oneui port salvo thanks to @corsicanu
    * Latest: salvo_port
    * 2 minutes ago
   
   Xiaomi Redmi S2 ROMs, Kernels, Recoveries, & Other
 * N
   Question Poco F5 Pro Serious Error
    * Latest: Nos430s
    * 2 minutes ago
   
   Poco F5 Pro / Redmi K60 (China)
 * A
   General Nothing Phone (1) [ ROM ][ OTA ][ Nothing OS ] Repo of Nothing OS
    * Latest: AnotherM1m
    * 2 minutes ago
   
   Nothing Phone 1
 * i have LG velvet Lm-G900W i need androd 13
    * Latest: babar989
    * 3 minutes ago
   
   LG Velvet ROMs, Kernels, Recoveries, & Other Devel



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.

| Crafted by Audentio


MORE INFO

Contact Us (Forum Issues) Advertise Terms and rules Suggest Content Change Ad
Consent Do not sell my data


USEFUL LINKS

Best Phones Tutorials Recognized Developer Program Admin & Moderators Delete XDA
Account
 * 
 * XDA - Dark

 * Contact us
 * Terms and rules
 * Privacy policy
 * Help
 * Home
 * 
 * RSS

| Crafted by Audentio
 * 
 * 
 * 
 * 
 * 
 * 





Freestar.com


LIVE

Preview is not yet available


Tap to unmute
Learn more



Advertisement