pdk/docs/guide/bring_up.jd - platform/development - Git at Google

 page.title=Bring Up
 pdk.version=1.0
 doc.type=guide
 @jd:body

 <p>Once your code is built and you have verified that all necessary directories exist, power on and test your device with basic bring up, as described below. Bring up tests are typically designed to stress certain aspects of your system and allow you to characterize the device's behavior. </p>
 <p>&nbsp;</p>
 <h3>1. Confirm a Clean Installation of a Basic Linux Kernel </h3>
 <p>Before considering Android-specific modifications to the Linux kernel, verify that you can build, deploy, and boot a core Linux kernel on your target hardware. </p>
 <p>&nbsp;</p>
 <h3>2. Modify Your Kernel Configuration to Accommodate Android Drivers</h3>
 <p>Your kernel configuration file should include the following:</p>
 <pre class="prettyprint">
 #
 # Android
 #
 # CONFIG_ANDROID_GADGET is not set
 # CONFIG_ANDROID_RAM_CONSOLE is not set
 CONFIG_ANDROID_POWER=y
 CONFIG_ANDROID_POWER_STAT=y
 CONFIG_ANDROID_LOGGER=y
 # CONFIG_ANDROID_TIMED_GPIO is not set
 CONFIG_ANDROID_BINDER_IPC=y
 </pre>
 <h3>3. Write Drivers</h3>
 <p>Android ships with default drivers for all basic functionality but you'll likely want to write your own drivers (or at least customize the default drivers) for your own device depending on your hardware configuration. See the following topics for examples of how to write your own drivers. </p>
 <ul>
   <li><a href="audio_subsystem.html">Audio</a></li>
   <li><a href="keymaps_keyboard_input.html">Keymaps and Keyboard</a></li>
   <li><a href="display_drivers.html">Display</a></li>
 </ul>
 <p>&nbsp;</p>
 <h3>4. Burn Images to Flash</h3>
 <p>An image represents the state of a system or part of a system  stored in non-volatile memory. The build process should produce the following system images:</p>
 <ul>
   <li><strong>bootloader</strong>: The bootloader is a small program responsible for initiating loading of the operating system. </li>
   <li><strong>boot</strong>: </li>
   <li><strong>recovery</strong>: </li>
   <li><strong>system</strong>: The system image stores a snapshot of the Android operating system.</li>
   <li><strong>data</strong>: The data image stores user data. Anything not saved to the <code>device/data</code> directory will be lost on reboot.</li>
 </ul>
 <ul>
   <li><strong>kernel</strong>: The kernel represents the most basic element of an operating system. Android's Linux kernel is responsible for managing the system's resources and acts as an abstraction layer between hardware and a system's applications. </li>
   <li><strong>ramdisk</strong>: RAMdisk defines a portion of Random Access Memory (RAM) that gets used as if it were a hard drive. </li>
 </ul>
 <p>&nbsp;</p>
 <p>Configure the bootloader to load the kernel 	and RAMdisk into RAM and pass the RAMdisk address to the kernel on 	startup. </p>
 <p>&nbsp;</p>
 <h3>5. Boot the kernel and mount the RAMdisk.</h3>
 <p>&nbsp;</p>
 <h3>6. Debug Android-specific init programs on RAMdisk</h3>
 <p>Android-specific init programs are found in <code>device/system/init</code>. Add LOG messages to help you debug potential problems with the LOG macro defined in <code>device/system/init/init.c</code>.</p>
 <p> The init program directly mounts all filesystems and devices using either hard-coded file names or device names generated by probing the sysfs filesystem (thereby eliminating the need for a <code>/etc/fstab</code> file in Android).  After <code>device/system</code> files are mounted, init  reads <code>/etc/init.rc</code> and invokes the programs listed there (one of the first of which is the 	console shell).</p>
 <p>&nbsp;</p>
 <h3>7. Verify that applications have started </h3>
 <p>Once the shell becomes available, execute <code>% ps</code> to confirm that the following applications are running:</p>
 <ul>
     <li><code>/system/bin/logd</code></li>
     <li><code>/sbin/adbd</code></li>
     <li><code>/system/bin/usbd</code></li>
     <li><code>/system/bin/debuggerd</code></li>
     <li><code>/system/bin/rild</code></li>
     <li><code>/system/bin/app_process</code></li>
     <li><code>/system/bin/runtime</code></li>
     <li><code>/system/bin/dbus-daemon</code></li>
     <li><code>system_server</code></li>
 </ul>
 <p>Each of these applications is embedded Linux C/C++ and you can use any standard Linux debugging tool to troubleshoot applications that aren't running. Execute <code>% make showcommands</code> to determine precise build commands. <code>gdbserver</code> (the GNU debugger) is available in the <code>bin</code> directory of the system partition (please see <a href="http://sourceware.org/gdb/">http://sourceware.org/gdb/</a> for more information).  </p>
 <p>&nbsp;</p>
 <h3>8. Pulling it all together </h3>
 <p>If bring up was successful, you should see the following Java applications (with icons) visible on the LCD panel:</p>
 <ul>
     <li>com.google.android.phone: The Android contact application. </li>
     <li>com.google.android.home</li>
     <li>android.process.google.content</li>
 </ul>
 <p>If they are not visible or unresponsive to keypad control, run the <code>framebuffer/keypad</code> tests.</p>


 <a name="androidInitLanguage"></a><h1>Android Init Language</h1>


 <p>The Android Init Language consists of four broad classes of statements:</p>
 <ul>
   <li>Actionn</li>
   <li>Commands</li>
   <li>Services</li>
   <li>Options</li>
 </ul>
 <p>The language syntax includes the following conventions: </p>
 <ul>
   <li>All classes are line-oriented and consist of tokens separated by whitespace. c-style backslash escapes may be used to insert whitespace into a token. &nbsp;Double quotes may also be used to prevent whitespace from breaking text into multiple tokens. A backslash <br />
   appearing as the last character on a line is used for line-folding.</li>
   <li> Lines that start with a # (leading whitespace allowed) are comments.</li>
   <li>Actions and Services implicitly declare new sections. All commands
     or options belong to the section most recently declared. &nbsp;Commands
     or options before the first section are ignored.  </li>
   <li>Actions and Services have unique names. &nbsp;If a second Action or Service is declared with the same name as an existing one, it is ignored as an error.</li>
 </ul>
 <p>  Actions</p>
 <p> Actions are named sequences of commands. Actions have a trigger used to determine when the action should occur. When an event
   occurs which matches an action's trigger, that action is added to
   the tail of a to-be-executed queue (unless it is already on the
   queue).<br />
   <br />
   Each action in the queue is dequeued in sequence. Each command in
   an action is executed in sequence.&nbsp;Init handles other activities
   (such as, device creation/destruction, property setting, process restarting) &quot;between&quot; the execution of the commands in activities.
 <p>Actions take the form of:</p>
 <pre class="prettify">
 on &lt;trigger&gt;
 &nbsp; &lt;command&gt;
 &nbsp; &lt;command&gt;
 &nbsp; &lt;command&gt;
 </pre>
 <p>Services</p>
 <p>Services are programs that init launches and (optionally) restarts
 when they exit. </p>
 <p>Services take the form of:</p>
 <pre class="prettify">
   service &lt;name&gt; &lt;pathname&gt; [ &lt;argument&gt; ]*
 &nbsp; &lt;option&gt;
 &nbsp; &lt;option&gt;
 &nbsp; ...
 </pre>
 <p>Options</p>
   <p> Options are modifiers to services that affect how and when init
 runs a service. Options are described in the table below:</p>
 <table>
   <tr>
     <th scope="col">Option</th><th scope="col">Description</th></tr>
   <tr>
     <td><code>disabled</code></td>
     <td>This service will not automatically start with its class. It must be explicitly started by name.</td>
   </tr>
   <tr>
     <td><code>socket &lt;type&gt; &lt;name&gt; &lt;perm&gt; [ &lt;user&gt; [ &lt;group&gt; ] ]</code></td>
     <td> Create a unix domain socket named <code>/dev/socket/&lt;name&gt;</code> and pass its fd to the launched process. Valid <code>&lt;type&gt;</code> values include <code>dgram</code> and <code>stream</code>. <code>user</code> and <code>group</code> default to 0.</td>
   </tr>
   <tr>
     <td><code>user &lt;username&gt;</code></td>
     <td>Change to username before exec'ing this service. Currently defaults to root.</td>
   </tr>
   <tr>
     <td><code>group &lt;groupname&gt; [ &lt;groupname&gt; ]*</code></td>
     <td> Change to groupname before exec'ing this service. &nbsp;Additional&nbsp; groupnames beyond the first, which is required, are used to set additional groups of the process (with <code>setgroups()</code>). Currently defaults to root.</td>
   </tr>
   <tr>
     <td><code>capability [ &lt;capability&gt; ]+</code></td>
     <td>Set linux capability before exec'ing this service</td>
   </tr>
   <tr>
     <td><code>oneshot</code></td>
     <td>Do not restart the service when it exits.</td>
   </tr>
   <tr>
     <td><code>class &lt;name&gt;</code></td>
     <td>Specify a class name for the service. &nbsp;All services in a named class must start and stop together. A service is considered of class &quot;default&quot; if one is not specified via the class option.</td>
   </tr>
 </table>
   <p>  Triggers</p>
   <p>Triggers are strings used to match certain kinds of events that cause an action to occur.  </p>
   <table>
     <tr>
       <th scope="col">Trigger</th>
       <th scope="col">Description</th>
     </tr>
     <tr>
       <td><code>boot</code></td>
       <td>This is the first trigger that occurs when init starts (after <code>/init.conf</code> is loaded).</td>
     </tr>
     <tr>
       <td><code>&lt;name&gt;=&lt;value&gt;</code></td>
       <td>Triggers of this form occur when the property <code>&lt;name&gt;</code> is set to the specific value <code>&lt;value&gt;</code>.</td>
     </tr>
     <tr>
       <td><code>device-added-&lt;path&gt;<br />
   device-removed-&lt;path&gt;</code></td>
       <td>Triggers of these forms occur when a device node is added or removed.</td>
     </tr>
     <tr>
       <td><code> service-exited-&lt;name&gt;</code></td>
       <td>Triggers of this form occur when the specified service exits.</td>
     </tr>
   </table>
   <p><br />
   Commands</p>
   <table>
     <tr>
       <th scope="col">Command</th>
       <th scope="col">Description</th>
     </tr>
     <tr>
       <td><code>exec &lt;path&gt; [ &lt;argument&gt; ]*</code></td>
       <td>Fork and execute a program (<code>&lt;path&gt;</code>). This will block until the program completes execution. Try to avoid exec. Unlike the <code>builtin</code> commands, it runs the risk of getting init &quot;stuck&quot;.</td>
     </tr>
     <tr>
       <td><code>export &lt;name&gt; &lt;value&gt;</code></td>
       <td>Set the environment variable <code>&lt;name&gt;</code> equal to <code>&lt;value&gt;</code> in the global environment (which will be inherited by all processes started after this command is executed).</td>
     </tr>
     <tr>
       <td><code>ifup &lt;interface&gt;</code></td>
       <td>Bring the network interface <code>&lt;interface&gt;</code> online.</td>
     </tr>
     <tr>
       <td><code>import &lt;filename&gt;</code></td>
       <td> Parse an init config file, extending the current configuration.</td>
     </tr>
     <tr>
       <td><code>hostname &lt;name&gt;</code></td>
       <td>Set the host name.</td>
     </tr>
     <tr>
       <td><code>class_start &lt;serviceclass&gt;</code></td>
       <td>Start all services of the specified class if they are not already running.</td>
     </tr>
     <tr>
       <td><code>class_stop &lt;serviceclass&gt;</code></td>
       <td>Stop all services of the specified class if they are currently running.</td>
     </tr>
     <tr>
       <td><code>domainname &lt;name&gt;</code></td>
       <td>Set the domain name.</td>
     </tr>
     <tr>
       <td><code>insmod &lt;path&gt;</code></td>
       <td>Install the module at <code>&lt;path&gt;</code>.</td>
     </tr>
     <tr>
       <td><code>mkdir &lt;path&gt;</code></td>
       <td>Make a directory at <code>&lt;path&gt;</code>.</td>
     </tr>
     <tr>
       <td><code>mount &lt;type&gt; &lt;device&gt; &lt;dir&gt; [ &lt;mountoption&gt; ]*</code></td>
       <td>Attempt to mount the named device at the directory <code>&lt;dir&gt;</code>         <code>&lt;device&gt;</code>. This may be of the form mtd@name to specify a mtd block device by name.</td>
     </tr>
     <tr>
       <td><code>setkey</code></td>
       <td>- currenlty undefined - </td>
     </tr>
     <tr>
       <td><code>setprop &lt;name&gt; &lt;value&gt;</code></td>
       <td>Set system property <code>&lt;name&gt;</code> to <code>&lt;value&gt;</code>.</td>
     </tr>
     <tr>
       <td><code> setrlimit &lt;resource&gt; &lt;cur&gt; &lt;max&gt;</code></td>
       <td>Set the rlimit for a resource.</td>
     </tr>
     <tr>
       <td><code>start &lt;service&gt;</code></td>
       <td>Start a service running if it is not already running.</td>
     </tr>
     <tr>
       <td><code> stop &lt;service&gt;</code></td>
       <td>Stop a service from running if it is currently running.</td>
     </tr>
     <tr>
       <td><code>symlink &lt;target&gt; &lt;path&gt;</code></td>
       <td>Create a symbolic link at <code>&lt;path&gt;</code> with the value <code>&lt;target&gt;</code>.</td>
     </tr>
     <tr>
       <td><code>write &lt;path&gt; &lt;string&gt; [ &lt;string&gt; ]*</code></td>
       <td>Open the file at <code>&lt;path&gt;</code> and write one or more strings to it with write(2).</td>
     </tr>
   </table>
   <p>    Properties</p>
     Init updates some system properties to provide some insight into<br />
     what it's doing:</p>
   <table>
     <tr>
       <th scope="col">Property</th>
       <th scope="col">Description</th>
     </tr>
     <tr>
       <td><code>init.action</code></td>
       <td>Equal to the name of the action currently being executed or &quot;&quot; if none.</td>
     </tr>
     <tr>
       <td><code>init.command</code></td>
       <td>Equal to the command being executed or &quot;&quot; if none.</td>
     </tr>
     <tr>
       <td><code>init.svc.&lt;name&gt;</code></td>
       <td>State of a named service (&quot;stopped&quot;, &quot;running&quot;, or &quot;restarting&quot;).</td>
     </tr>
   </table>
   <p>Example init.conf</p>
   <p>The following snippet is an incomplete example of the <code>init.conf</code> file, simply meant to give you an idea of what a proper configuration resembles.</p>
   <pre class="prettify">
 on boot
   export PATH /sbin:/system/sbin:/system/bin
   export LD_LIBRARY_PATH /system/lib

   mkdir /dev
   mkdir /proc
   mkdir /sys


   mount tmpfs tmpfs /dev
   mkdir /dev/pts
   mkdir /dev/socket
   mount devpts devpts /dev/pts
   mount proc proc /proc
   mount sysfs sysfs /sys


   write /proc/cpu/alignment 4


   ifup lo


   hostname localhost
   domainname localhost


   mount yaffs2 mtd@system /system
   mount yaffs2 mtd@userdata /data


   import /system/etc/init.conf


   class_start default


 service adbd /sbin/adbd
   user adb
   group adb


 service usbd /system/bin/usbd -r
   user usbd
   group usbd
   socket usbd 666


 service zygote /system/bin/app_process -Xzygote /system/bin --zygote
   socket zygote 666


 service runtime /system/bin/runtime
   user system
   group system


 on device-added-/dev/compass
   start akmd


 on device-removed-/dev/compass
   stop akmd


 service akmd /sbin/akmd
   disabled
   user akmd
   group akmd
 </pre>
	page.title=Bring Up
	pdk.version=1.0
	doc.type=guide
	@jd:body

	<p>Once your code is built and you have verified that all necessary directories exist, power on and test your device with basic bring up, as described below. Bring up tests are typically designed to stress certain aspects of your system and allow you to characterize the device's behavior. </p>
	<p> </p>
	<h3>1. Confirm a Clean Installation of a Basic Linux Kernel </h3>
	<p>Before considering Android-specific modifications to the Linux kernel, verify that you can build, deploy, and boot a core Linux kernel on your target hardware. </p>
	<p> </p>
	<h3>2. Modify Your Kernel Configuration to Accommodate Android Drivers</h3>
	<p>Your kernel configuration file should include the following:</p>
	<pre class="prettyprint">
	#
	# Android
	#
	# CONFIG_ANDROID_GADGET is not set
	# CONFIG_ANDROID_RAM_CONSOLE is not set
	CONFIG_ANDROID_POWER=y
	CONFIG_ANDROID_POWER_STAT=y
	CONFIG_ANDROID_LOGGER=y
	# CONFIG_ANDROID_TIMED_GPIO is not set
	CONFIG_ANDROID_BINDER_IPC=y
	</pre>
	<h3>3. Write Drivers</h3>
	<p>Android ships with default drivers for all basic functionality but you'll likely want to write your own drivers (or at least customize the default drivers) for your own device depending on your hardware configuration. See the following topics for examples of how to write your own drivers. </p>
	<ul>
	<li><a href="audio_subsystem.html">Audio</a></li>
	<li><a href="keymaps_keyboard_input.html">Keymaps and Keyboard</a></li>
	<li><a href="display_drivers.html">Display</a></li>
	</ul>
	<p> </p>
	<h3>4. Burn Images to Flash</h3>
	<p>An image represents the state of a system or part of a system stored in non-volatile memory. The build process should produce the following system images:</p>
	<ul>
	<li><strong>bootloader</strong>: The bootloader is a small program responsible for initiating loading of the operating system. </li>
	<li><strong>boot</strong>: </li>
	<li><strong>recovery</strong>: </li>
	<li><strong>system</strong>: The system image stores a snapshot of the Android operating system.</li>
	<li><strong>data</strong>: The data image stores user data. Anything not saved to the <code>device/data</code> directory will be lost on reboot.</li>
	</ul>
	<ul>
	<li><strong>kernel</strong>: The kernel represents the most basic element of an operating system. Android's Linux kernel is responsible for managing the system's resources and acts as an abstraction layer between hardware and a system's applications. </li>
	<li><strong>ramdisk</strong>: RAMdisk defines a portion of Random Access Memory (RAM) that gets used as if it were a hard drive. </li>
	</ul>
	<p> </p>
	<p>Configure the bootloader to load the kernel and RAMdisk into RAM and pass the RAMdisk address to the kernel on startup. </p>
	<p> </p>
	<h3>5. Boot the kernel and mount the RAMdisk.</h3>
	<p> </p>
	<h3>6. Debug Android-specific init programs on RAMdisk</h3>
	<p>Android-specific init programs are found in <code>device/system/init</code>. Add LOG messages to help you debug potential problems with the LOG macro defined in <code>device/system/init/init.c</code>.</p>
	<p> The init program directly mounts all filesystems and devices using either hard-coded file names or device names generated by probing the sysfs filesystem (thereby eliminating the need for a <code>/etc/fstab</code> file in Android). After <code>device/system</code> files are mounted, init reads <code>/etc/init.rc</code> and invokes the programs listed there (one of the first of which is the console shell).</p>
	<p> </p>
	<h3>7. Verify that applications have started </h3>
	<p>Once the shell becomes available, execute <code>% ps</code> to confirm that the following applications are running:</p>
	<ul>
	<li><code>/system/bin/logd</code></li>
	<li><code>/sbin/adbd</code></li>
	<li><code>/system/bin/usbd</code></li>
	<li><code>/system/bin/debuggerd</code></li>
	<li><code>/system/bin/rild</code></li>
	<li><code>/system/bin/app_process</code></li>
	<li><code>/system/bin/runtime</code></li>
	<li><code>/system/bin/dbus-daemon</code></li>
	<li><code>system_server</code></li>
	</ul>
	<p>Each of these applications is embedded Linux C/C++ and you can use any standard Linux debugging tool to troubleshoot applications that aren't running. Execute <code>% make showcommands</code> to determine precise build commands. <code>gdbserver</code> (the GNU debugger) is available in the <code>bin</code> directory of the system partition (please see <a href="http://sourceware.org/gdb/">http://sourceware.org/gdb/</a> for more information). </p>
	<p> </p>
	<h3>8. Pulling it all together </h3>
	<p>If bring up was successful, you should see the following Java applications (with icons) visible on the LCD panel:</p>
	<ul>
	<li>com.google.android.phone: The Android contact application. </li>
	<li>com.google.android.home</li>
	<li>android.process.google.content</li>
	</ul>
	<p>If they are not visible or unresponsive to keypad control, run the <code>framebuffer/keypad</code> tests.</p>


	<a name="androidInitLanguage"></a><h1>Android Init Language</h1>


	<p>The Android Init Language consists of four broad classes of statements:</p>
	<ul>
	<li>Actionn</li>
	<li>Commands</li>
	<li>Services</li>
	<li>Options</li>
	</ul>
	<p>The language syntax includes the following conventions: </p>
	<ul>
	<li>All classes are line-oriented and consist of tokens separated by whitespace. c-style backslash escapes may be used to insert whitespace into a token.  Double quotes may also be used to prevent whitespace from breaking text into multiple tokens. A backslash <br />
	appearing as the last character on a line is used for line-folding.</li>
	<li> Lines that start with a # (leading whitespace allowed) are comments.</li>
	<li>Actions and Services implicitly declare new sections. All commands
	or options belong to the section most recently declared.  Commands
	or options before the first section are ignored. </li>
	<li>Actions and Services have unique names.  If a second Action or Service is declared with the same name as an existing one, it is ignored as an error.</li>
	</ul>
	<p> Actions</p>
	<p> Actions are named sequences of commands. Actions have a trigger used to determine when the action should occur. When an event
	occurs which matches an action's trigger, that action is added to
	the tail of a to-be-executed queue (unless it is already on the
	queue).<br />
	<br />
	Each action in the queue is dequeued in sequence. Each command in
	an action is executed in sequence. Init handles other activities
	(such as, device creation/destruction, property setting, process restarting) "between" the execution of the commands in activities.
	<p>Actions take the form of:</p>
	<pre class="prettify">
	on <trigger>
	<command>
	<command>
	<command>
	</pre>
	<p>Services</p>
	<p>Services are programs that init launches and (optionally) restarts
	when they exit. </p>
	<p>Services take the form of:</p>
	<pre class="prettify">
	service <name> <pathname> [ <argument> ]*
	<option>
	<option>
	...
	</pre>
	<p>Options</p>
	<p> Options are modifiers to services that affect how and when init
	runs a service. Options are described in the table below:</p>
	<table>
	<tr>
	<th scope="col">Option</th><th scope="col">Description</th></tr>
	<tr>
	<td><code>disabled</code></td>
	<td>This service will not automatically start with its class. It must be explicitly started by name.</td>
	</tr>
	<tr>
	<td><code>socket <type> <name> <perm> [ <user> [ <group> ] ]</code></td>
	<td> Create a unix domain socket named <code>/dev/socket/<name></code> and pass its fd to the launched process. Valid <code><type></code> values include <code>dgram</code> and <code>stream</code>. <code>user</code> and <code>group</code> default to 0.</td>
	</tr>
	<tr>
	<td><code>user <username></code></td>
	<td>Change to username before exec'ing this service. Currently defaults to root.</td>
	</tr>
	<tr>
	<td><code>group <groupname> [ <groupname> ]*</code></td>
	<td> Change to groupname before exec'ing this service.  Additional  groupnames beyond the first, which is required, are used to set additional groups of the process (with <code>setgroups()</code>). Currently defaults to root.</td>
	</tr>
	<tr>
	<td><code>capability [ <capability> ]+</code></td>
	<td>Set linux capability before exec'ing this service</td>
	</tr>
	<tr>
	<td><code>oneshot</code></td>
	<td>Do not restart the service when it exits.</td>
	</tr>
	<tr>
	<td><code>class <name></code></td>
	<td>Specify a class name for the service.  All services in a named class must start and stop together. A service is considered of class "default" if one is not specified via the class option.</td>
	</tr>
	</table>
	<p> Triggers</p>
	<p>Triggers are strings used to match certain kinds of events that cause an action to occur. </p>
	<table>
	<tr>
	<th scope="col">Trigger</th>
	<th scope="col">Description</th>
	</tr>
	<tr>
	<td><code>boot</code></td>
	<td>This is the first trigger that occurs when init starts (after <code>/init.conf</code> is loaded).</td>
	</tr>
	<tr>
	<td><code><name>=<value></code></td>
	<td>Triggers of this form occur when the property <code><name></code> is set to the specific value <code><value></code>.</td>
	</tr>
	<tr>
	<td><code>device-added-<path><br />
	device-removed-<path></code></td>
	<td>Triggers of these forms occur when a device node is added or removed.</td>
	</tr>
	<tr>
	<td><code> service-exited-<name></code></td>
	<td>Triggers of this form occur when the specified service exits.</td>
	</tr>
	</table>
	<p><br />
	Commands</p>
	<table>
	<tr>
	<th scope="col">Command</th>
	<th scope="col">Description</th>
	</tr>
	<tr>
	<td><code>exec <path> [ <argument> ]*</code></td>
	<td>Fork and execute a program (<code><path></code>). This will block until the program completes execution. Try to avoid exec. Unlike the <code>builtin</code> commands, it runs the risk of getting init "stuck".</td>
	</tr>
	<tr>
	<td><code>export <name> <value></code></td>
	<td>Set the environment variable <code><name></code> equal to <code><value></code> in the global environment (which will be inherited by all processes started after this command is executed).</td>
	</tr>
	<tr>
	<td><code>ifup <interface></code></td>
	<td>Bring the network interface <code><interface></code> online.</td>
	</tr>
	<tr>
	<td><code>import <filename></code></td>
	<td> Parse an init config file, extending the current configuration.</td>
	</tr>
	<tr>
	<td><code>hostname <name></code></td>
	<td>Set the host name.</td>
	</tr>
	<tr>
	<td><code>class_start <serviceclass></code></td>
	<td>Start all services of the specified class if they are not already running.</td>
	</tr>
	<tr>
	<td><code>class_stop <serviceclass></code></td>
	<td>Stop all services of the specified class if they are currently running.</td>
	</tr>
	<tr>
	<td><code>domainname <name></code></td>
	<td>Set the domain name.</td>
	</tr>
	<tr>
	<td><code>insmod <path></code></td>
	<td>Install the module at <code><path></code>.</td>
	</tr>
	<tr>
	<td><code>mkdir <path></code></td>
	<td>Make a directory at <code><path></code>.</td>
	</tr>
	<tr>
	<td><code>mount <type> <device> <dir> [ <mountoption> ]*</code></td>
	<td>Attempt to mount the named device at the directory <code><dir></code> <code><device></code>. This may be of the form mtd@name to specify a mtd block device by name.</td>
	</tr>
	<tr>
	<td><code>setkey</code></td>
	<td>- currenlty undefined - </td>
	</tr>
	<tr>
	<td><code>setprop <name> <value></code></td>
	<td>Set system property <code><name></code> to <code><value></code>.</td>
	</tr>
	<tr>
	<td><code> setrlimit <resource> <cur> <max></code></td>
	<td>Set the rlimit for a resource.</td>
	</tr>
	<tr>
	<td><code>start <service></code></td>
	<td>Start a service running if it is not already running.</td>
	</tr>
	<tr>
	<td><code> stop <service></code></td>
	<td>Stop a service from running if it is currently running.</td>
	</tr>
	<tr>
	<td><code>symlink <target> <path></code></td>
	<td>Create a symbolic link at <code><path></code> with the value <code><target></code>.</td>
	</tr>
	<tr>
	<td><code>write <path> <string> [ <string> ]*</code></td>
	<td>Open the file at <code><path></code> and write one or more strings to it with write(2).</td>
	</tr>
	</table>
	<p> Properties</p>
	Init updates some system properties to provide some insight into<br />
	what it's doing:</p>
	<table>
	<tr>
	<th scope="col">Property</th>
	<th scope="col">Description</th>
	</tr>
	<tr>
	<td><code>init.action</code></td>
	<td>Equal to the name of the action currently being executed or "" if none.</td>
	</tr>
	<tr>
	<td><code>init.command</code></td>
	<td>Equal to the command being executed or "" if none.</td>
	</tr>
	<tr>
	<td><code>init.svc.<name></code></td>
	<td>State of a named service ("stopped", "running", or "restarting").</td>
	</tr>
	</table>
	<p>Example init.conf</p>
	<p>The following snippet is an incomplete example of the <code>init.conf</code> file, simply meant to give you an idea of what a proper configuration resembles.</p>
	<pre class="prettify">
	on boot
	export PATH /sbin:/system/sbin:/system/bin
	export LD_LIBRARY_PATH /system/lib

	mkdir /dev
	mkdir /proc
	mkdir /sys


	mount tmpfs tmpfs /dev
	mkdir /dev/pts
	mkdir /dev/socket
	mount devpts devpts /dev/pts
	mount proc proc /proc
	mount sysfs sysfs /sys


	write /proc/cpu/alignment 4


	ifup lo


	hostname localhost
	domainname localhost


	mount yaffs2 mtd@system /system
	mount yaffs2 mtd@userdata /data


	import /system/etc/init.conf


	class_start default


	service adbd /sbin/adbd
	user adb
	group adb


	service usbd /system/bin/usbd -r
	user usbd
	group usbd
	socket usbd 666


	service zygote /system/bin/app_process -Xzygote /system/bin --zygote
	socket zygote 666


	service runtime /system/bin/runtime
	user system
	group system


	on device-added-/dev/compass
	start akmd


	on device-removed-/dev/compass
	stop akmd


	service akmd /sbin/akmd
	disabled
	user akmd
	group akmd
	</pre>