From 5c40a48e4b0dee143515e5ac3562efdfd7f24903 Mon Sep 17 00:00:00 2001 From: David Warren Date: Fri, 5 Jun 2009 15:11:21 -0700 Subject: [PATCH] * Added in-page TOC to all pages. * Removed "Introduction" title from all pages. --- pdk/docs/guide/audio.jd | 6 +- pdk/docs/guide/bluetooth.jd | 37 +++++----- pdk/docs/guide/build_cookbook.jd | 43 +++++++----- pdk/docs/guide/build_new_device.jd | 23 +++--- pdk/docs/guide/build_system.jd | 54 ++++++-------- pdk/docs/guide/camera.jd | 30 ++++---- pdk/docs/guide/customization.jd | 31 ++++---- pdk/docs/guide/dalvik.jd | 29 ++++---- pdk/docs/guide/debugging_gdb.jd | 20 +++--- pdk/docs/guide/debugging_native.jd | 24 +++---- pdk/docs/guide/display_drivers.jd | 23 +++--- pdk/docs/guide/gps.jd | 21 +++--- pdk/docs/guide/instrumentation_testing.jd | 86 +++++++++-------------- pdk/docs/guide/keymaps_keyboard_input.jd | 54 +++++++------- pdk/docs/guide/lights.jd | 27 +++---- pdk/docs/guide/pdk_toc.cs | 11 +-- pdk/docs/guide/release_keys.jd | 4 +- pdk/docs/guide/sensors.jd | 25 ++++--- pdk/docs/guide/stk.jd | 40 +++++------ pdk/docs/guide/telephony.jd | 45 ++++++------ pdk/docs/guide/wakelock.jd | 25 ++++--- pdk/docs/guide/wifi.jd | 19 ++--- 22 files changed, 332 insertions(+), 345 deletions(-) diff --git a/pdk/docs/guide/audio.jd b/pdk/docs/guide/audio.jd index ae97e2191..0467d897e 100755 --- a/pdk/docs/guide/audio.jd +++ b/pdk/docs/guide/audio.jd @@ -7,14 +7,12 @@ pdk.version=1.0

In this document

-

Introduction

AudioHardwareInterface serves as the glue between proprietary audio drivers and the Android AudioFlinger service, the core audio service that handles all audio-related requests from applications.

@@ -23,7 +21,7 @@ Solid elements represent Android blocks and dashed elements represent partner-sp -

Building an Audio Library

+

Building an Audio Library

To implement an audio driver, create a shared library that implements the interface defined in AudioHardwareInterface.h. You must name your shared library libaudio.so so that it will get loaded from /system/lib at runtime. Place libaudio sources and Android.mk in partner/acme/chipset_or_board/libaudio/.

The following stub Android.mk file ensures that libaudio compiles and links to the appropriate libraries:

@@ -52,7 +50,7 @@ include $(BUILD_SHARED_LIBRARY) -

Interface

+

Interface

diff --git a/pdk/docs/guide/bluetooth.jd b/pdk/docs/guide/bluetooth.jd index 5d5e8064c..e514ef0eb 100755 --- a/pdk/docs/guide/bluetooth.jd +++ b/pdk/docs/guide/bluetooth.jd @@ -2,20 +2,19 @@ page.title=Bluetooth pdk.version=1.0 @jd:body +
+ - -

Introduction

Android's Bluetooth stack uses BlueZ version 3.36 for GAP, SDP, and RFCOMM profiles, and is a SIG-qualified Bluetooth 2.0 + EDR host stack.

@@ -31,7 +30,7 @@ Solid elements represent Android blocks and dashed elements represent partner-sp -

Porting

+

Porting

BlueZ is Bluetooth 2.0 compatible and should work with any 2.0 chipset. There are two integration points:

-Compiling

Compiling

+

Compiling

To compile Android with Bluetooth support enabled, add the following line to BoardConfig.mk. 

 BOARD_HAVE_BLUETOOTH := true
-

Troubleshooting

+

Troubleshooting

Debugging

To debug your bluetooth implementation, start by reading the logs (adb logcat) and look for ERRROR and WARNING messages regarding Bluetooth. Andoird uses Bluez, which comes with some useful debugging tools. The snippet below provides examples in a suggested order:

@@ -82,7 +81,7 @@ sdptool records ADDRESS # request the SDP records of another BT device.

hciconfig -a and hcitool

If you compile your own system.img for Android, and hciconfig -a works but hcitool scan doesn't, try installing the firmware for the Bluetooth chipset. This firmware isn't yet available in the open source codebase, but you can adb pull and then adb pushit from a stock T-Mobile G1 (located in /etc/firmware/brf6300.bin).

-

Tools

+

Tools

BlueZ provides a rich set of command line tools for debugging and interacting with the Bluetooth sub-system, including:

-

Detailed Instructions

+ +

Detailed Instructions

The directions below describe how to configure make files for new mobile devices and products.

    @@ -104,7 +111,7 @@ pdk.version=1.0

    You should find new build binaries located in /out/target/product/<board_name>. -

    New Product File Tree

    +

    New Product File Tree

    The file tree below illustrates what your own system should look like after completing the steps above.

    @@ -127,7 +134,7 @@ pdk.version=1.0

    -

    Product Definition Files

    +

    Product Definition Files

    Product-specific variables are defined in product definition files. A product definition file can inherit from other product definition files, thus reducing the need to copy and simplifying maintenance.

    Variables maintained in a product definition files include:

    @@ -244,7 +251,7 @@ PRODUCT_PACKAGE_OVERLAYS := vendor/acme/overlay -

    Build Variants

    +

    Build Variants

    When building for a particular product, it's often useful to have minor diff --git a/pdk/docs/guide/build_system.jd b/pdk/docs/guide/build_system.jd index 36936aa54..64216d8cb 100755 --- a/pdk/docs/guide/build_system.jd +++ b/pdk/docs/guide/build_system.jd @@ -3,34 +3,26 @@ pdk.version=1.0 @jd:body +

    Android uses a custom build system to generate tools, binaries, and documentation. This document provides an overview of Android's build system and instructions for doing a simple build.

    Android's build system is make based and requires a recent version of GNU Make (note that Android uses advanced features of GNU Make that may not yet appear on the GNU Make web site). Before continuing, check your version of make by running % make -v. If you don't have version 3.80 or greater, you need to upgrade your version of make.

    -

    Understanding Android's Build System

    -

    Understanding the makefile

    + +

    Understanding the makefile

    A makefile defines how to build a particular application. Makefiles typically include all of the following elements:

      @@ -58,7 +50,7 @@ include $(BUILD_EXECUTABLE)

      The snippet above includes artificial line breaks to maintain a print-friendly document.

      -

      Layers

      +

      Layers

      The build hierarchy includes the abstraction layers described in the table below.

      @@ -92,12 +84,12 @@ include $(BUILD_EXECUTABLE) -

      Building the Android Platform

      +

      Building the Android Platform

      This section describes how to build the default version of Android. Once you are comfortable with a generic build, then you can begin to modify Android for your own target device.

      -

      Device Code

      +

      Device Code

      To do a generic build of android, source build/envsetup.sh, which contains necessary variable and function definitions, as described below.

      @@ -117,12 +109,12 @@ include $(BUILD_EXECUTABLE)
      -

      Cleaning Up

      +

      Cleaning Up

      Execute % m clean to clean up the binaries you just created. You can also execute % m clobber to get rid of the binaries of all combos. % m clobber is equivalent to removing the //out/ directory where all generated files are stored.

      -

      Speeding Up Rebuilds

      +

      Speeding Up Rebuilds

      The binaries of each combo are stored as distinct sub-directories of //out/, making it possible to quickly switch between combos without having to recompile all sources each time.

      However, performing a clean rebuild is necessary if the build system doesn't catch changes to environment variables or makefiles. If this happens often, you should define the USE_CCACHE environment variable as shown below:

      @@ -134,7 +126,7 @@ include $(BUILD_EXECUTABLE)

      ccache binaries are provided in //prebuilt/... and don't need to get installed on your system.

      -

      Troubleshooting

      +

      Troubleshooting

      The following error is likely caused by running an outdated version of Java.

      @@ -155,7 +147,7 @@ Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
 
      If you do have Java 1.5 or later and your receive this error, verify that you have properly updated your PATH variable.
      
 
 
-
      Building the Android Kernel
      
+
      Building the Android Kernel
      
 
 
      This section describes how to build Android's default kernel. Once you are comfortable with a generic build, then you can begin to modify Android drivers for your own target device.
      
 
@@ -168,7 +160,7 @@ Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
 
      Then switch to the kernel directory /home/joe/android/kernel.
 
 
-
      Checking Out a Branch
      
+
      Checking Out a Branch
      
 
 
      The default branch is always android. To check out a different branch, execute the following:
      
 
@@ -182,7 +174,7 @@ Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
 
      To simplify code management, give your local branch the same name as the remote branch it is tracking (as illustrated in the snippet above). Switch between branches by executing % git checkout <branchname>.
      
 
 
-
      Verifying Location
      
+
      Verifying Location
      
 
 
      Find out which branches exist (both locally and remotely) and which one is active (marked with an asterisk) by executing the following:
      
 
      @@ -197,7 +189,7 @@ Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
 
      To only see local branches, omit the -a flag.
       
 
 
-
      Building the Kernel
      
+
      Building the Kernel
      
 
 
      To build the kernel, execute:
      
 
      diff --git a/pdk/docs/guide/camera.jd b/pdk/docs/guide/camera.jd
index 204c0702b..f4c9c8503 100755
--- a/pdk/docs/guide/camera.jd
+++ b/pdk/docs/guide/camera.jd
@@ -2,24 +2,24 @@ page.title=Camera
 pdk.version=1.0
 @jd:body
 
+
+
 
 
      Android's camera subsystem connects the camera application to the application framework and user space libraries, which in turn communicate with the camera hardware layer that operates the physical camera.
      
 
      The diagram below illustrates the structure of the camera subsystem.
      
 
      
 
 
-
      Building a Camera Library
      
+
      Building a Camera Library
      
 
 
      To implement a camera driver, create a shared library that implements the interface defined in CameraHardwareInterface.h. You must name your shared library libcamera.so so that it will get loaded from /system/lib at runtime.  Place libcamera sources and Android.mk in partner/acme/chipset_or_board/libcamera/.
      
 
      The following stub Android.mk file ensures that libcamera compiles and links to the appropriate libraries:
      
@@ -49,23 +49,23 @@ include $(BUILD_SHARED_LIBRARY)
 
      
 
 
-
      Sequence Diagrams
      
+
      Sequence Diagrams
      
 
 
 
-
      Preview
      
+
      Preview
      
 
 
      The following diagram illustrates the sequence of function calls and actions necessary for your camera to preview.
      
 
 
 
-
      Taking a Picture
      
+
      Taking a Picture
      
 
 
      The following diagram illustrates the sequence of function calls and actions necessary for your camera to take a picture.
      
 
 
 
-
      Interface
      
+
      Interface
      
 
 
 
diff --git a/pdk/docs/guide/customization.jd b/pdk/docs/guide/customization.jd
index a405113c4..9c39cd735 100755
--- a/pdk/docs/guide/customization.jd
+++ b/pdk/docs/guide/customization.jd
@@ -2,21 +2,22 @@ page.title=Customization
 pdk.version=1.0
 @jd:body
 
- 
- 
+
+
+
  
 
      Boot Screen Customization
       
  
diff --git a/pdk/docs/guide/dalvik.jd b/pdk/docs/guide/dalvik.jd
index 30c92ef5d..948496a98 100755
--- a/pdk/docs/guide/dalvik.jd
+++ b/pdk/docs/guide/dalvik.jd
@@ -1,16 +1,19 @@
 page.title=Dalvik
 pdk.version=1.0
 @jd:body
- 
- 
-
- 
-
      Introduction
       
- 
+
+
      
+
+
      
+
 
       
 The Dalvik virtual machine is intended to run on a variety of platforms.
 The baseline system is expected to be a variant of UNIX (Linux, BSD, Mac
@@ -23,7 +26,7 @@ operating system.  This document covers the former.
 
      
  
  
-
      Core Libraries
       
+
      Core Libraries
       
  
 
       
 The native code in the core libraries (chiefly dalvik/libcore,
@@ -37,7 +40,7 @@ can be used.
 
       
  
  
-
      JNI Call Bridge
       
+
      JNI Call Bridge
       
  
 
       
 Most of the Dalvik VM runtime is written in portable C.  The one
@@ -82,7 +85,7 @@ method signature for things like the return value, total argument size,
 or inter-argument 64-bit alignment restrictions.
 
       
  
-
      Interpreter
       
+
      Interpreter
       
  
 
       
 The Dalvik runtime includes two interpreters, labeled "portable" and "fast".
diff --git a/pdk/docs/guide/debugging_gdb.jd b/pdk/docs/guide/debugging_gdb.jd
index fe633071f..9717cf384 100755
--- a/pdk/docs/guide/debugging_gdb.jd
+++ b/pdk/docs/guide/debugging_gdb.jd
@@ -2,21 +2,23 @@ page.title=Debugging with GDB
 pdk.version=1.0
 @jd:body
 
+
      
+
      
+
      In this document
      
 
-
-
-
      Introduction
      
-
      The current version of envsetup.sh has a gdbclient command that handles much of the setup.  For example, to attach to the
+
      
+
+
      The current version of envsetup.sh has a gdbclient command that handles much of the setup.  For example, to attach the
   already-running globaltime application, execute the following, making sure that: 1) you do this from the same window used to build the software on the device you are debugging and 2) verify that the symbols in the object files in the build tree match up with what is installed on the device or emulator.
      
 
       gdbclient app_process :5039 globaltime
 
      
+
      Debugging
      
 
 
      Short Instructions
      
 
      Android runs gdbserver on the device and an ARM aware gdb, named arm-eabi-gdb, on the desktop machine.
      
diff --git a/pdk/docs/guide/debugging_native.jd b/pdk/docs/guide/debugging_native.jd
index 435048bbc..5f9f0f75c 100755
--- a/pdk/docs/guide/debugging_native.jd
+++ b/pdk/docs/guide/debugging_native.jd
@@ -3,18 +3,18 @@ pdk.version=1.0
 @jd:body
 
 
+
      
+
 
-
      Capturing logs
      
+
      Capturing logs
      
 
 
      To capture log output:
      
 
        
@@ -24,7 +24,7 @@ pdk.version=1.0
 
 
      
 
-
      Debug Scenarios
      
+
      Debug Scenarios
      
 
         # command to device shell (via adb)
   % command to host pc shell
@@ -32,7 +32,7 @@ pdk.version=1.0
 
      
 
      
 
-
      Crash but no exit...stuck
      
+
      Crash but no exit...stuck
      
 
 
      In this scenario, the GTalk app crashed but did not actually exit or seems stuck. Check the debug logs to see if there is anything unusual: 
      
 
@@ -237,7 +237,7 @@ Previous frame identical to this frame (corrupt stack?)
 #2  0x6b022c2c in shell (args=0x51b58) at extlibs/jamvm-1.4.1/src/thread.c:629
 
      
 
-
      Crash in C / C++ code
      
+
      Crash in C / C++ code
      
 
      If it crashes, connect with aproto and run logcat on the device. You should see output like this:
      
 
 
      diff --git a/pdk/docs/guide/display_drivers.jd b/pdk/docs/guide/display_drivers.jd
index 94d5467fc..ac41c55ce 100755
--- a/pdk/docs/guide/display_drivers.jd
+++ b/pdk/docs/guide/display_drivers.jd
@@ -4,20 +4,23 @@ pdk.version=1.0
 
 
 
+
+
      
 
 
      This section describes how the display driver functions and offers a functional template designed to help you build your own device-specific driver.
      
 
      Android relies on the standard frame buffer device (/dev/fb0 or /dev/graphics/fb0) and driver as described in the linux/fb.h kernel header file. For more information regarding the standard Linux frame buffer, please see The Frame Buffer Device at http://kernel.org.
 
 
-
      Functionality
      
+
      Functionality
      
 
 
      In Android, every window gets implemented with an underlying Surface object, an object that gets placed on the framebuffer by SurfaceFlinger, the system-wide screen composer. Each Surface is double-buffered. The back buffer is where drawing takes place and the front buffer is used for composition. 
      
 
       When unlockCanvas() is called, the back buffer is posted, which 
@@ -32,7 +35,7 @@ pdk.version=1.0
 
      To maintain adequate performance, framebuffer memory should be cacheable. If you use write-back, flush the cache before the frame buffer is written from DMA to the LCD. If that isn't possible, you may use write-through. As a last resort, you can also use uncached memory with the write-bugger enabled, but performance will suffer.
      
 
 
-
      Implementing Your Own Driver (Driver Template)
      
+
      Implementing Your Own Driver (Driver Template)
      
 
 
      The following sample driver offers a functional example to help you build your own display driver. Modify PGUIDE_FB... macros as desired to match the requirements of your own device hardware.
      
 
      @@ -330,7 +333,7 @@ MODULE_LICENSE("GPL");
 
      
 
 
-
      Troubleshooting
      
+
      Troubleshooting
      
 
 
      Both of the following problems have a similar cause:
      
 
      
 
 
      Android defines a user space C abstraction interface for GPS hardware. The interface header is defined in include/hardware/gps.h. In order to integate GPS with Android, you need to build a shared library that implements this interface. 
      
 
 
-
      Building a GPS Library
      
+
      Building a GPS Library
      
 
 
      To implement a GPS driver, create a shared library that implements the interface defined in gps.h. You must name your shared library libgps.so so that it will get loaded from /system/lib at runtime. Place GPS sources and Android.mk in partner/acme/chipset_or_board/gps/ (where "acme" is your product name and "chipset_or_board" is your hardware target).
      
 
@@ -44,11 +47,11 @@ include $(BUILD_SHARED_LIBRARY)
 
      
 
 
-
      Interface
      
+
      Interface
      
 
 
 
-
      
+
      
 
 
      Note: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, click here.
      
 
diff --git a/pdk/docs/guide/instrumentation_testing.jd b/pdk/docs/guide/instrumentation_testing.jd
index 1302217f6..00c824818 100755
--- a/pdk/docs/guide/instrumentation_testing.jd
+++ b/pdk/docs/guide/instrumentation_testing.jd
@@ -2,37 +2,19 @@ page.title=Instrumentation Testing
 pdk.version=1.0
 @jd:body
 
+
 
 
      This document describes how to use the Instrumentation Framework to write test cases. Instrumentation testing allows you to verify a particular feature or behavior with an automated JUnit TestCase. You can launch activities and providers within an application, send key events, and make assertions about various UI elements. 
      
 
      You should have a working knowledge of the following:
      
@@ -45,11 +27,11 @@ pdk.version=1.0
 
       Each Android application runs in its own process. Instrumentation kills the application process and  restarts the process with Instrumentation. Instrumentation gives a handle to the application context used to poke around the application to validate test assertions, allowing you to write test cases to test applications at a much lower level than UI screen shot tests. Note that Instrumentation cannot catch UI bugs. 
      
 
 
-
      Instrumentation Framework
      
+
      Instrumentation Framework
      
 
 
 
-
      Classes
      
+
      Classes
      
 
 
       The following classes help glue together Instrumentation with JUnit testing. 
      
 
@@ -95,7 +77,7 @@ pdk.version=1.0
 
      
 
 
-
      Understanding the am Command
      
+
      Understanding the am Command
      
 
 
      The am command is a command-line interface to the ActivityManager (see http://code.google.com/android/reference/android/app/ActivityManager.html for details). am is used to start and instrument activities using the adb shell command, as shown in the snippet below:
      
 
      @@ -112,22 +94,22 @@ For example, to start the Contacts application you can use
 
      
 
 
-
      Platform Test Suites
      
+
      Platform Test Suites
      
 
 
      This section provides an overview for various unit and functional test cases that can be executed through the instrumentation framework.
      
 
 
-
      Framework Tests
      
+
      Framework Tests
      
 
 
      Framework test cases test the Android application framework or specific Android application functionality that requires an Android runtime context.  These tests can be found in //device/tests and //device/apps/AndroidTests.
      
 
 
-
      Core Library
      
+
      Core Library
      
 
 
      Core library test cases test the Android library functionality that does not require an Android runtime context.  These tests are split into Android library (android.* package space) tests at //device/java/tests and Java library (java.*, javax.*, etc. packages) tests at //device/dalvik/libcore/.../tests.
      
 
 
-
      Running Tests
      
+
      Running Tests
      
 
 
      Each instrumentation test case is similar to an Android application with the distinction that it starts another application. For example, have a look in the tests/Contacts directory. 
      
 
        
@@ -165,7 +147,7 @@ $
      -

      All Tests with Default TestRunner behavior

      +

      All Tests with Default TestRunner behavior

      If no class or package is passed in to run, InstrumentationTestRunner will automatically find and run all tests under the package of the test application (as defined by the android:targetPackage attribute of the instrumentation defined in its manifest file).

      @@ -183,7 +165,7 @@ INSTRUMENTATION_CODE: -1 -

      Running all Tests Under Single Package

      +

      Running all Tests Under Single Package

      If you have many tests under one package, use the -e package <packagename> option to run all tests under that package without having to manually create a test suite.

       
@@ -197,7 +179,7 @@ OK (8 tests)
      -

      Running a Single Test Suite

      +

      Running a Single Test Suite

      If you prefer to explicitly state which tests comprise all of your tests, you can define a test suite and run that directly. By convention, all test packages in your system should have at least one suite called AllTests (see AllTests.java). To run all of the tests using the AllTests suite for the api demos test app:

      @@ -216,7 +198,7 @@ INSTRUMENTATION_CODE: -1 -

      A Single Test Case

      +

      A Single Test Case

       
 $ adb shell am instrument -w \
@@ -233,7 +215,7 @@ INSTRUMENTATION_CODE: -1
      -

      A Single Test

      +

      A Single Test

       
 $ adb shell am instrument -w \
@@ -250,7 +232,7 @@ INSTRUMENTATION_CODE: -1
      -

      Attaching a debugger to your test

      +

      Attaching a debugger to your test

      In order to debug your test code, instruct the controller to stop and wait for the debugger by adding -e debug true to your command line. This causes the test runner to stop and wait for the debugger just before calling your setUp() method. For example,

      @@ -262,12 +244,12 @@ $ adb shell am instrument -w \ -

      Writing Tests

      +

      Writing Tests

      When writing tests, refer to the ApiDemos tests as models (located at //device/samples/ApiDemos). This section provides an overview of the test structure with ApiDemos.

      -

      Location of Files

      +

      Location of Files

      Test packages should use the following structure and include Android.mk, AndroidManifest.xml, AllTests.java, and a src directory that mirrors the src directory of the tested application.

      Files are located within a tests directory found in the root directory:

      @@ -291,7 +273,7 @@ samples/ApiDemos/tests/src/com/google/android/samples/view/Focus2AndroidTest.jav -

      Contents of makefile

      +

      Contents of makefile

      The contents of the makefile are similar to a normal application with the addition of a LOCAL_INSTRUMENTATION_FOR declaration.

       
@@ -317,7 +299,7 @@ include $(BUILD_PACKAGE)
      -

      Content of Manifest

      +

      Content of Manifest

      Use the following example to create an AndroidManifest.xml file that declares the instrumentation. Specify that the framework supplied Instrumentation TestRunner targest the package of your application, allowing the tests that are run with the instrumentation to get access to all of the classes of your application without having to build the source into the test app. The name of the test application is typically the same as your target application with .tests appended. 

       
@@ -346,7 +328,7 @@ $ adb shell am instrument -w \
      -

      New Instrumentation TestRunner

      +

      New Instrumentation TestRunner

      Create a class that derives from this class. You must override two abstract methods; one that returns the class loader of the target package, and another that defines all of the tests within the package. For example, the snippet below displays the test runner for the framework tests.

      @@ -378,7 +360,7 @@ public class FrameworkInstrumentationTestRunner extends InstrumentationTestRunne
      -

      New InstrumentationTestCase

      +

      New InstrumentationTestCase

      To create a new test case, write a class that extends InstrumentationTestCase in the same application as your test runner. The following snippet illustrates an example ActivityTestCase that tests an activity named MyActivity.

      @@ -409,7 +391,7 @@ public class ButtonPressTest extends ActivityTestCase<MyActivity> {
      -

      Exploring a Test Case

      +

      Exploring a Test Case

      The test case described in this section adds and tests a new Contact. Note that you can send intents, register intent receivers, etc.

      Instrumentation.java has helper functions that send key events and strings, for example:

      @@ -481,7 +463,7 @@ private void addNewContact(String name, int star, int phoneType, String number, -

      Deciding Kinds of Tests to Write

      +

      Deciding Kinds of Tests to Write

      Once you are bootstrapped with your test application, you can start writing tests. There are three of types of tests you may wish to write:

        @@ -498,7 +480,7 @@ private void addNewContact(String name, int star, int phoneType, String number,

        -

        Troubleshooting

        +

        Troubleshooting

        If you run your test cases and nothing appears to happen, have a look at adb logcat. The following is a common problem:

        diff --git a/pdk/docs/guide/keymaps_keyboard_input.jd b/pdk/docs/guide/keymaps_keyboard_input.jd
index a71b5e9ed..e53149a6d 100755
--- a/pdk/docs/guide/keymaps_keyboard_input.jd
+++ b/pdk/docs/guide/keymaps_keyboard_input.jd
@@ -3,25 +3,19 @@ pdk.version=1.0
 @jd:body
 
 
+
+
 
 
        This document describes how keyboard input gets translated into Android actions and how you can customize key layout and key character maps to match the needs of your own device. 
        
 
        Android uses the standard Linux input event device (/dev/event0) and driver as described in the linux/input.h kernel header file. For more information regarding standard Linux input drivers, please see Linux Input drivers at http://kernel.org.
        
@@ -29,7 +23,7 @@ pdk.version=1.0
 
 
 
-
        Functionality
        
+
        Functionality
        
 
 
        Android's input event device is structured around an interrupt or polling routine that captures the device-specific scancode and converts it to a standard form acceptable to Linux (as defined in input.h) before passing it to the kernel with input_event().
        
 
        The keymap driver's other primary function is to establish a probe function that sets up the interrupt or polling function, handles hardware initialization, and attaches the driver to the input subsystem with input_register_device().
        
@@ -60,17 +54,17 @@ pdk.version=1.0
 
 
 
-
        Key Layout Map
        
+
        Key Layout Map
        
 
 
 
-
        Selection of a Key Layout Map
        
+
        Selection of a Key Layout Map
        
 
 
        Key layout maps are installed in /system/usr/keylayout and /data/usr/keylayout.
        
 
        For each keyboard device xxx, set the android.keylayout.xxx system property (see Building New Device for help setting system properties). If you don't specify a keylayout file, Android will default to /system/usr/keylayout/qwerty.kl.
        
 
 
-
        File Format
        
+
        File Format
        
 
 
        Key layout maps are stored on the device as UTF-8 text files and have the following characteristics:
        
 
          
@@ -88,7 +82,7 @@ pdk.version=1.0
 
          
 
 
-
          Example of a Key Layout Map File
          
+
          Example of a Key Layout Map File
          
 
 
          The following code comes from  android/src/device/product/generic/tuttle2.kl and is an example of a complete key layout file:
          
 
          @@ -171,17 +165,17 @@ key 399   GRAVE
 
          
 
 
-
          Key Character Map
          
+
          Key Character Map
          
 
 
 
-
          Selection of a Key Character Map
          
+
          Selection of a Key Character Map
          
 
 
          Key character maps are installed in /system/usr/keychars and /data/usr/keychars.
          
 
          For each keyboard device xxx, set the android.keychar.xxx system property to the full path of the desired keychar file. If you don't specify a keychar file, Android will default to /system/usr/keychar/qwerty.kl.
 
 
-
          File Format
          
+
          File Format
          
 
 
          Key character maps are stored on the device as binary resources in order to reduce loading time. Key character maps have the following characteristics:
          
 
            
@@ -220,7 +214,7 @@ key 399   GRAVE
 
          
 
 
-
          Example of a Key Character Map File
          
+
          Example of a Key Character Map File
          
 
 
          The following code comes from android/src/device/product/generic/tuttle2.kcm and represents a complete key character file:
          
 
          The type line indicates what kind of keyboard your device implements. Possible types include:
          
@@ -299,7 +293,7 @@ PLUS          '+'     '+'     '+'     '+'     '+'     '+'
        -

        Resource Binary File Format

        +

        Resource Binary File Format

        The file snippet above gets converted to the following by the makekcharmap tool as part of the build process. You can mmap this file in and share the approximately 4k of memory that it uses between processes to minimize load time.

        @@ -359,7 +353,7 @@ PLUS '+' '+' '+' '+' '+' '+'
        -

        Implementing Your Own Driver (Driver Template)

        +

        Implementing Your Own Driver (Driver Template)

        The following file, pguide_events.c, illustrates how to implement an Android keymap driver.

        @@ -485,7 +479,7 @@ MODULE_LICENSE("GPL");
        -

        Sample Implementation

        +

        Sample Implementation

        Assume the following for the setup of a new keypad device:

        diff --git a/pdk/docs/guide/lights.jd b/pdk/docs/guide/lights.jd
index 5437e631a..4f19c5d3c 100755
--- a/pdk/docs/guide/lights.jd
+++ b/pdk/docs/guide/lights.jd
@@ -1,15 +1,18 @@
 page.title=Lights
 pdk.version=1.0
 @jd:body
- 
- 
- 
- 
-
        Introduction
         
- 
+
+
        
+
        
+
        In this document
        
+
+
+
        
+
        
+
 
        Android defines a user space C abstraction interface for LED hardware. The interface header is defined in 
 hardware/libhardware/include/hardware/lights.h.
 In order to integrate LEDs with Android you need to build a shared library that implements this interface. 
@@ -25,17 +28,17 @@ The types of logical lights currently supported by Android include:

      -

      Building a Lights Library

      +

      Building a Lights Library

      To implement a Lights driver, create a shared library that implements the interface defined in lights.h. You must name your shared library liblights.so so that it will get loaded from /system/lib at runtime.

      Interface

      +

      Interface

      -

      +

      Note: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, click here.

      diff --git a/pdk/docs/guide/pdk_toc.cs b/pdk/docs/guide/pdk_toc.cs index 3b79cef32..f98f19489 100644 --- a/pdk/docs/guide/pdk_toc.cs +++ b/pdk/docs/guide/pdk_toc.cs @@ -34,7 +34,7 @@ function nothing() {}
    1. Wi-Fi
      2. - +
    2. Display Drivers
    3. Input Devices
      @@ -42,7 +42,7 @@ function nothing() {}
    4. Keymaps and Keyboard
      5. -
    5. LED
      6. +
    6. Lights
    7. Multimedia
        @@ -66,13 +66,6 @@ function nothing() {}
      8. -
    8. -
      Misc
      - -
      9. - diff --git a/pdk/docs/guide/release_keys.jd b/pdk/docs/guide/release_keys.jd index aa3a44b45..a57cb106a 100755 --- a/pdk/docs/guide/release_keys.jd +++ b/pdk/docs/guide/release_keys.jd @@ -2,7 +2,9 @@ page.title=Creating Release Keys and Signing Builds pdk.version=1.0 @jd:body
      -
      +
      +

      In this document

      +
      • Introduction
      • Generating keys
        • diff --git a/pdk/docs/guide/sensors.jd b/pdk/docs/guide/sensors.jd index 4463a951d..79a2ad3f9 100755 --- a/pdk/docs/guide/sensors.jd +++ b/pdk/docs/guide/sensors.jd @@ -1,14 +1,17 @@ page.title=Sensors pdk.version=1.0 @jd:body - - -
      - -

      Introduction

      - + +
      +
      +

      In this document

      + + +
      +
      +

      Android defines a user space C abstraction interface for sensor hardware. The interface header is defined in hardware/libhardware/include/hardware/sensors.h. In order to integrate sensors with Android you need to build a shared library that implements this interface. @@ -26,17 +29,17 @@ The types of sensors currently supported by Android include:

      -

      Building a Sensor Library

      +

      Building a Sensor Library

      To implement a Sensors driver, create a shared library that implements the interface defined in sensors.h. You must name your shared library libsensors.so so that it will get loaded from /system/lib at runtime.

      Interface

      +

      Interface

      -

      +

      Note: This document relies on some Doxygen-generated content that appears in an iFrame below. To return to the Doxygen default content for this page, click here.

      diff --git a/pdk/docs/guide/stk.jd b/pdk/docs/guide/stk.jd index 32f165cae..0ce0b4a04 100755 --- a/pdk/docs/guide/stk.jd +++ b/pdk/docs/guide/stk.jd @@ -2,26 +2,20 @@ page.title=Sim Toolkit Application (STK) pdk.version=1.0 @jd:body - - - -

      Introduction

      -

      This document offers a high-level overview of the SIM Toolkit Application for Android 1.0 and is primarily of interest for implementors of the Radio Interface Layer (RIL). The STK is R96 compatible (3GPP TS 11.14 v5.9.0) and complies partially with R99 (3GPP TS 101.267 v8.17.0). See the STK Feature List for the complete feature list.

      The Android STK implementation includes three layers:

        @@ -42,7 +36,7 @@ pdk.version=1.0

        See the Android Platform Development Kit for details.

        -

        Communication from the RIL up

        +

        Communication from the RIL up

        Communication to the upper layers is done using the RIL_UNSOL_xxx family of commands defined in /hardware/ril/include/ril.h. The payload for each command is encoded using BER-TLV. As stated above, it is not necessary to remove extraneous fields. This allows the SIM to pass a complete command to the upper layers and simplifies STK RIL code. Below is the mapping from RIL_UNSOL_xxx commands to the SIM commands.

        @@ -182,7 +176,7 @@ pdk.version=1.0

        Sent by SIM to signal end of session. No content and no response.

        -

        Communication from the application down

        +

        Communication from the application down

        Communication from the upper layers to the RIL uses the commands below (defined in ril.h):

        @@ -218,13 +212,13 @@ pdk.version=1.0

        This should cause the terminal response to be sent to the SIM.

        -

        Telephony

        +

        Telephony

        STK Telephony is a protocol translation layer used to convert messages from BERL-TLV format to Application messages and back.

        On the STK RIL side, STK Telphony receives raw buffer messages from RIL I/F and decodes them into a command parameters container before passing them on to the application. On the Application side, this layer receives application responses for commands and encodes them into raw buffer messages, which then get sent over the RIL I/F back to the SIM card.

        -

        Feature List

        +

        Feature List

        diff --git a/pdk/docs/guide/telephony.jd b/pdk/docs/guide/telephony.jd index 647a33be5..0fe522160 100755 --- a/pdk/docs/guide/telephony.jd +++ b/pdk/docs/guide/telephony.jd @@ -2,23 +2,18 @@ page.title=Radio Layer Interface pdk.version=1.0 @jd:body + +

        Android's Radio Interface Layer (RIL) provides an abstraction layer between Android telephony services (android.telephony) and radio hardware. The RIL is radio agnostic, and includes support for Global System for Mobile communication (GSM)-based radios. 

        @@ -36,7 +31,7 @@ Solid elements represent Android blocks and dashed elements represent partner-sp

        -

        RIL Initialization

        +

        RIL Initialization

        Android initializes the telephony stack and the Vendor RIL at startup as described in the sequence below:

          @@ -57,7 +52,7 @@ Solid elements represent Android blocks and dashed elements represent partner-sp
        1. ro.ril.enable.3g.prefix=1: adds the 3G prefix to the operator name.

          2. -

          RIL Interaction

          +

          RIL Interaction

          There are two forms of communication that the RIL handles:

            @@ -66,7 +61,7 @@ Solid elements represent Android blocks and dashed elements represent partner-sp
          -

          Solicited

          +

          Solicited

          The following snippet illustrates the interface for solicited commands:

          @@ -92,7 +87,7 @@ void OnRequestComplete (RIL_Token t, RIL_Error e, void *response, size_t respons
 
          
 
 
-
          Unsolicited
          
+
          Unsolicited
          
 
 
          The following snippet illustrates the interface for unsolicited commands:
          
 
          @@ -111,7 +106,7 @@ void OnUnsolicitedResponse (int unsolResponse, void *data, size_t datalen);
 
          
 
 
-
          Implementing the RIL
          
+
          Implementing the RIL
          
 
 
          To implement a radio-specific RIL, create a shared library that implements a set of functions required by Android to process radio requests. The required functions are defined in the RIL header (/include/telephony/ril.h).
          
 
          The Android radio interface is radio-agnostic and the Vendor RIL can use any protocol to communicate with the radio. Android provides a reference Vendor RIL, using the Hayes AT command set, that you can use as a quick start for telephony testing and a guide for commercial vendor RILs. The source code for the reference RIL is found at /commands/reference-ril/.
          
@@ -125,7 +120,7 @@ void OnUnsolicitedResponse (int unsolResponse, void *data, size_t datalen);
 
          
 
 
-
          RIL_Init
          
+
          RIL_Init
          
 
 
          Your Vendor RIL must define a RIL_Init function that provides a handle to the functions which will process all radio requests.  RIL_Init will be called by the Android RIL Daemon at boot time to initialize the RIL.
          
 
@@ -147,12 +142,12 @@ RIL_RadioFunctions;
 
          
 
 
-
          RIL Functions
          
+
          RIL Functions
          
 
 
          ril.h defines RIL states and variables, such as RIL_UNSOL_STK_CALL_SETUP, RIL_SIM_READY, RIL_SIM_NOT_READY, as well as the functions described in the tables below. Skim the header file (/device/include/telephony/ril.h) for details.
          
 
 
-
          RIL Solicited Command Requests
          
+
          RIL Solicited Command Requests
          
 
 
          The vendor RIL must provide the functions described in the table below to handle solicited commands. The RIL solicited command request types are defined in ril.h with the RIL_REQUEST_ prefix. Check the header file for details.
        @@ -214,7 +209,7 @@ RIL_RadioFunctions;

        -

        RIL Unsolicited Commands

        +

        RIL Unsolicited Commands

        The functions listed in the table below are call-back functions used by the Vendor RIL to invoke unsolicited commands on the Android platform. See ril.h for details.

        diff --git a/pdk/docs/guide/wakelock.jd b/pdk/docs/guide/wakelock.jd index 1d8b425c6..ee590539c 100755 --- a/pdk/docs/guide/wakelock.jd +++ b/pdk/docs/guide/wakelock.jd @@ -3,14 +3,17 @@ pdk.version=1.0 @jd:body +

        + -

        Introduction

        A locked wakelock, depending on its type, prevents the system from entering suspend or other low-power states. This document describes how to employ wakelocks.

        There are two settings for a wakelock:

          @@ -45,9 +48,9 @@ pdk.version=1.0 process-input-events +++ +++ -

          Driver API

          +

          Driver API

          A driver can use the wakelock API by adding a wakelock variable to its state and calling wake_lock_init, as illustrated in the snippet below:

          -
          +
             struct state {
   struct wakelock wakelock;
   }
@@ -60,18 +63,18 @@ pdk.version=1.0
   }
   
          
 
           When the driver determines that it needs to run (usually in an interrupt handler), it calls wake_lock:
          
-
          +
             wake_lock(&state->wakelock);
   
          
 
          When it no longer needs to run, it calls wake_unlock:
          
-
          +
             wake_unlock(&state->wakelock);
   
          
 
           It can also call wake_lock_timeout to release the wakelock after a delay:
          
-
          +
             wake_lock_timeout(&state->wakelock, HZ);
 
          
 
           This works whether or not the wakelock is already held. It is useful if the driver woke up other parts of the system that do not use wakelocks but still need to run. Avoid this when possible, since it will waste power if the timeout is long or may fail to finish needed work if the timeout is short.
          
-
          User-space API
          
+
          User-space API
          
 
          Write lockname or lockname timeout to /sys/power/wake_lock lock and, if needed, create a wakelock. The timeout here is specified in nanoseconds. Write lockname to /sys/power/wake_unlock to unlock a user wakelock.
          
 
           Do not use randomly generated wakelock names as there is no API to free a user-space wakelock.
          
\ No newline at end of file
diff --git a/pdk/docs/guide/wifi.jd b/pdk/docs/guide/wifi.jd
index aaf0acecc..5341954cb 100755
--- a/pdk/docs/guide/wifi.jd
+++ b/pdk/docs/guide/wifi.jd
@@ -2,18 +2,21 @@ page.title=Wi-Fi
 pdk.version=1.0
 @jd:body
 
+
 
 
          Android uses wpa_supplicant as the platform interface to the Wi-Fi device. Your Wi-Fi driver must be compatible with the standard wpa_supplicant in addition to extensions added to the supplicant (specifically, the "DRIVER" commands described in wifi.h/wifi_command()).
          
 
 
-
          Building a Wi-Fi Library
          
+
          Building a Wi-Fi Library
          
 
 
          To create a Wi-Fi driver for Android:
          
 
            
@@ -37,7 +40,7 @@ endif
 
          
 
 
-
          Interface
          
+
          Interface