9-patch image

9-patches images

1) What is the 9-patch image?

The Ninth Patch class is permit to drawing a bitmap in nine sections. The four corners are unscaled ; the four edges are scaled in one axis, and middle are scaled in two axis, and the middle is scaled in both axes. Normally , the middle is transparent so that that the patch can provide a selection around the rectangle. Essentially, it allows the creation of custom graphics that will scale the way that you define, when content added within the image exceeds the normal bounds of the graphic.  

Here's a quick guide to create a Nine-patch graphic using the Draw 9-patch tool. You'll need the PNG image with which you'd like to create a NinePatch.

1.    From a terminal, launch the draw9patch application from your SDK /tools directory.

2.    Drag your PNG image into the Draw 9-patch window (or File > Open 9-patch... to locate the file). Your workspace will now open.

The left pane is your drawing area, in which you can edit the lines for the stretchable patches and content area. The right pane is the preview area, where you can preview your graphic when stretched.

3.    Click within the 1-pixel perimeter to draw the lines that define the stretchable patches and (optional) content area. Right-click (or hold Shift and click, on Mac) to erase previously drawn lines.

4.    When done, select File > Save 9-patch...

Your image will be saved with the .9.png file name.

           optional controls include 

• Zoom: Adjust the zoom level of the graphic in the drawing area.
• Patch scale: Adjust the scale of the images in the preview area.
• Show lock: Visualize the non-drawable area of the graphic on mouse-over.
• Show patches: Preview the stretchable patches in the drawing area (pink is a stretchable patch).
• Show content: Highlight the content area in the preview images (purple is the area in which content is allowed).
• Show bad patches: Adds a red border around patch areas that may produce artifacts in the graphic when stretched. Visual coherence of your stretched image will be maintained if you eliminate all bad patches.

JAR DEX

Jar(java archive files)

JAR file is the compressed file format. You can store many files in a JAR file. JAR stands for the Java Archive. This file format is used to distribute a set of java classes. This file helps you to reduce the file size and collect many file in one by compressing files. Downloading the files are become completed in very short duration of time because of reducing the file size. You can make the jar file executable by collecting many class file of your java application in it. The jar file can execute from the javaw (Java Web Start).

The JAR file format is based on the popular ZIP file format. Usually these file format is not only used for archiving and distribution the files, these are also used for implementing various libraries, components and plug-ins in java applications. Compiler and JVMs (Java Virtual Machine) can understand and implement these formats for java application.

For mentioning the product information like vendor name, product version, date of creation of the product and many other things related to the product are mentioned in the manifest file. Such types of files are special which are mentioned in the jar file for making it executable for the application. This file format is to be used for collecting auxiliary files associated with the components.

To perform basic operations for the jar file there has to be used the Java Archive Tool (jar tool). It is provided by the jdk (Java Development Kit). Following are some jar commands which are invoked by the jar tool:

Functions	Command
creation a jar file viewing contents of a jar file viewing contents with detail of a jar file extract all the files of a jar file extract specific files from the jar file update jar files running a executable packaged jar file	jar cf jar-file-name file-name(s)_or_directory-name jar tf jar-file-name jar tvf jar-file-name jar xf jar-file-name jar xf jar-file-name file-name(s)_from_jar-file jar uf jar-file-name file-name(s)_from_jar-file java -jar jar-file-name

BLOCK Diagram of JAR File

       

                                                  

This is the one of the jar file shown here which contain java file which is convert in to the class file each class file contains HEADER at the top indicating which version of   file format your using than its contains Heterogeneous Constant Pool is nothing the private literals used in the class. CLASS is used to access the flags it tells which is current working object  with respect to class it used to access super class abstract class and interface. FIELDS is nothing what the parameters we are passing. METHODS what methods we are using in the class.

DEX(Dalvik Executable)

Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language. In the DEX all the class file is compressed in to single file and adding the essential informations which can shared among the other files . The size of the dex file is halved of jar files .

File Header

Dex files start with a simple header with some checksums and offsets to other structures

Offset	Size	Description
0x0	8	'Magic' value: "dex\n009\0"
0x8	4	Checksum
0xC	20	SHA-1 Signature
0x20	4	Length of file in bytes
0x24	4	Length of header in bytes (currently always 0x5C)
0x28	8	Padding (reserved for future use?)
0x30	4	Number of strings in the string table
0x34	4	Absolute offset of the string table
0x38	4	Not sure. String related
0x3C	4	Number of classes in the class list
0x40	4	Absolute offset of the class list
0x44	4	Number of fields in the field table
0x48	4	Absolute offset of the field table
0x4C	4	Number of methods in the method table
0x50	4	Absolute offset of the method table
0x54	4	Number of class definitions in the class definition table
0x58	4	Absolute offset of the class definition table

Notes: All non-string fields are stored in little-endian format. It would appear that the checksum and signature fields are assumed to be zero when calculating the checksum and signature.

String Table

This table stores the length and offsets for every string in the Dex file including string constants, class names, variable names and more. Each entry has the following format:

Offset	Size	Description
0x0	4	Absolute offset of the string data
0x4	4	Length of the string (not including the null-terminator)

Notes: Although the length of the string is stored in this table. All strings also have C-style null-terminators

Class List

A list of all classes referenced or conatined in this dex file. Each entry has the following format:

Offset	Size	Description
0x0	4	String index of the name of the class

Field Table

A table of fields of all classes defined in this dex file. Each entry has the following format:

Offset	Size	Description
0x0	4	Class index of the class this field belongs to
0x4	4	String index of the field name
0x8	4	String index of the field type descriptor

Method Table

A table of methods of all classes defined in this dex file. Each entry has the following format:

Offset	Size	Description
0x0	4	Class index of the class this field belongs to
0x4	4	String index of the method name
0x8	4	String index of the method type descriptor

Class Definition Table

A table of class definitions for all classes either defined in this dex file or has a method or field accessed by code in this dex file. Each entry has the following format:

Offset	Size	Description
0x0	4	Class index
0x4	4	Access Flags (not 100% sure what this is for, I think it has to do with private/protected/public status)
0x8	4	Index of superclass
0xC	4	Absolute offset of interface list
0x10	4	Absolute offset of static field list
0x14	4	Absolute offset of instance field list
0x18	4	Absolute offset of direct method list
0x1C	4	Absolute offset of virtual method list

Notes: Any of the list offset fields can be NULL in which case the class doesn't have any elements of that type. Not every class in the class list will necessarily have an entry in the class definition table.

Field List

Stores data for pre-initialized fields in a class. The list is formed of a 32-bit integer containing the number of entries followed by the entries themselves. Each field has an entry with the following format:

Offset	Size	Description
0x0	8	Index of string or object constant or literal "primitive" constant

Notes: If the field does not have a pre-initialized value it will be filled with 0 for primitive types and -1 for object types.

Method List

A list of methods for a particular class. Begins with a 32-bit integer that contains the number of items in the list followed by entries in the following format.

Offset	Size	Description
0x0	4	Method index
0x4	4	Access flags (not 100% sure what this is for, I think it has to do with private/protected/public status)
0x8	4	Throws list off (no idea what this is)
0xC	4	Absolute offset of header for code that implements the method

Code Header

This header contains information about the code that implements a method.

Offset	Size	Description
0x0	2	Number of registers used by this method
0x2	2	Number of inputs this method takes (includes "this" pointer for non-static methods)
0x4	2	Output size? (presumably the size of whatever object the method returns)
0x6	2	Padding
0x8	4	String index of the source file name this method is implemented in
0xC	4	Absolute offset of the actual code that implements this method
0x10	4	Absolute offset of the list of exceptions this method can throw (not 100% sure)
0x14	4	Absolute offset of the list of address and line number pairs for debugging purposes
0x1C	4	Absolute offset of the local variable list of this method (includes arguments to the method and "this")

Notes: The code offset field actually points to a 32-bit integer that contains the number of 16-bit words in the instruction stream. The actual VM instructions follow this integer.

Local Variable List

A list of local variables for a particular method. Begins with a 32-bit integer that contains the number of items in the list. Each entry has the following format:

Offset	Size	Description
0x0	4	Start (not a clue)
0x4	4	End (not a clue)
0x8	4	String index of variable name
0xC	4	String index of variable type descriptor
0x10	4	Register number this variable will be stored in (not 100% sure)

BLOCK DIAGRAM OF DEX FILE

                                                                                                                                                                                                              is the block diagram shown above it convert all the class file in to one .dex file with the top of manifest file which class file will use first .

At the top of the header is situated which display the version of android api with apk file name

Than there is series of constant pools which have used many times in our application which are different methods, fields,  class, strings

Than after that we have class definition

Field list what different fields or data types we used in our application to store values.

Methods list what different methods we used to run our applications.

Local variables which are used for each class only.

Zygote

                                                                     

It is the important process in the system appear to be zygote (Which application process is binary), and runtime. These are both started by the init process. The following fragment of init.rc is relevant. It is important to note that these services auto started to noted that these services have the autostart 1 attribute, indicating they are restarted if they quit.

Zygote {

exec/system/bin/app_process

args {

0 – zygote

1 /system/bin

2 – zygote

}

autostart 1

}

runtime {

exec/system/bin/runtime

autostart 1  }

if we go kill zygote process and runtime process something interesting happens. Firstly the order of the process kills himself, and the whole system seems to restart himself , changing the ramdisk space.

We wanted to get a bit more control of what things are started up when. To do this I need to modify the init.rc file. To do this we will first extracted the ramdisk to system file so that I can modify ram disk image. After  this we simply commented out the line from init.rc . Then we can recreate it (gnucpio –I –t –F../ramdisk.img | gnucpio –o –H newc -0../rootfs.img)

We can then use emulator –ramdisk option to load our new ramdisk.

Now we can start things up manually. First we started up zygote process. As # app_process – zygote/system/bin/ --zygote . When we do that there is not output in console, or on the LCD . Next when we start runtime process(#runtime), and now things  start to happen.

Registered based

Registered  Based Machine

Processor registers are normally at the top of the memory hierarchy, and provide the fastest way to access data. The term normally refers only to the group of registers that are directly encoded as part of an instruction, as defined by the instruction set. However, modern high performance CPUs often have duplicates of these "architectural registers" in order to improve performance via register renaming, allowing parallel and speculative execution. Modern x86 is perhaps the most well known example of this technique.^[1]

Allocating frequently used variables to registers can be critical to a program's performance. This register allocation is either performed by a compiler, in the code generation phase, or manually, by an assembly language programmer.

Categories of register

Registers are normally measured by the number of bits they can hold, for example, an "8-bit register" or a "32-bit register". A processor often contains several kinds of registers, that can be classified accordingly to their content or instructions that operate on them:

1.     User-accessible Registers – The most common division of user-accessible registers is into data registers and address registers.

2.     Data registers can hold numeric values such as integer and floating-point values, as well as characters, small bit arrays and other data. In some older and low end CPUs, a special data register, known as the accumulator, is used implicitly for many operations.

3.     Address registers hold addresses and are used by instructions that indirectly access primary memory.

a.     Some processors contain registers that may only be used to hold an address or only to hold numeric values (in some cases used as an index register whose value is added as an offset from some address); others allow registers to hold either kind of quantity. A wide variety of possible addressing modes, used to specify the effective address of an operand, exist.

b.    The stack pointer is used to manage the run-time stack. Rarely, other data stacks are addressed by dedicated address registers, seestack machine.

4.     Conditional registers hold truth values often used to determine whether some instruction should or should not be executed.

5.     General purpose registers (GPRs) can store both data and addresses, i.e., they are combined Data/Address registers.

6.     Floating point registers (FPRs) store floating point numbers in many architectures.

7.     Constant registers hold read-only values such as zero, one, or pi.

8.     Vector registers hold data for vector processing done by SIMD instructions (Single Instruction, Multiple Data).

9.     Special purpose registers ( SPR ) hold program state; they usually include the program counter (aka instruction pointer) and status register (aka processor status word). The aforementioned stack pointer is sometimes also included in this group. Embedded microprocessors can also have registers corresponding to specialized hardware elements.

Instruction register store the instruction currently being executed.

10.  In some architectures, model-specific registers (also called machine-specific registers) store data and settings related to the processor itself. Because their meanings are attached to the design of a specific processor, they cannot be expected to remain standard between processor generations.

11.  Control and status registers – It has three types: program counter, instruction registers and program status word (PSW).

12.  Registers related to fetching information from RAM, a collection of storage registers located on separate chips from the CPU (unlike most of the above, these are generally not architectural registers):

a.     Memory buffer register

13. Memory data register
14. Memory address register
15. Memory Type Range Registers (MTRR)