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.
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:
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 -BlueZ is Bluetooth 2.0 compatible and should work with any 2.0 chipset. There are two integration points:
The BlueZ kernel sub-system attaches to your hardware-specific UART driver using the hciattach daemon.
For example, for MSM7201A, this is drivers/serial/msm_serial.c. You may also need to edit command line options to hciattach via init.rc.
The method for powering on and off your bluetooth chip varies from Android V 1.0 to post 1.0.
@@ -58,14 +57,14 @@ Solid elements represent Android blocks and dashed elements represent partner-spTo compile Android with Bluetooth support enabled, add the following line to BoardConfig.mk.
BOARD_HAVE_BLUETOOTH := true-
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:
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).
BlueZ provides a rich set of command line tools for debugging and interacting with the Bluetooth sub-system, including:
This section provides a change history of Bluetooth features added in each Android release and provides some rough guidance as to future features.
The Android Build Cookbook offers code snippets to help you quickly implement some common build tasks. For additional instruction, please see the other build documents in this section.
-LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) @@ -27,7 +34,7 @@ pdk.version=-# Tell it to build an APK include $(BUILD_PACKAGE)
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) @@ -44,7 +51,7 @@ pdk.version=-# Tell it to build an APK include $(BUILD_PACKAGE)
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) @@ -60,7 +67,7 @@ pdk.version=-# Tell it to build an APK include $(BUILD_PACKAGE)
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) @@ -76,7 +83,7 @@ pdk.version=-# Tell it to build an APK include $(BUILD_PACKAGE)
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) @@ -89,7 +96,7 @@ pdk.version=-include $(BUILD_PREBUILT)
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) @@ -106,7 +113,7 @@ pdk.version=-# Build a static jar file. include $(BUILD_STATIC_JAVA_LIBRARY)
These are the variables that you'll commonly see in Android.mk files, listed alphabetically. First, a note on the variable naming:
diff --git a/pdk/docs/guide/build_new_device.jd b/pdk/docs/guide/build_new_device.jd index d914ebee9..b21371d23 100755 --- a/pdk/docs/guide/build_new_device.jd +++ b/pdk/docs/guide/build_new_device.jd @@ -1,15 +1,22 @@ -page.title=Building Android for a new Mobile Device +page.title=Building Android for a new Device pdk.version=1.0 @jd:body +The directions below describe how to configure make files for new mobile devices and products.
You should find new build binaries located in /out/target/product/<board_name>.
-
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-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 -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.
A makefile defines how to build a particular application. Makefiles typically include all of the following elements:
The snippet above includes artificial line breaks to maintain a print-friendly document.
-The build hierarchy includes the abstraction layers described in the table below.
@@ -92,12 +84,12 @@ include $(BUILD_EXECUTABLE) -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.
-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)-
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.
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:
ccache binaries are provided in //prebuilt/... and don't need to get installed on your system.
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
-PATHvariable.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
@@ -182,7 +174,7 @@ Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)android. To check out a different branch, execute the following: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
--aflag.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 librarylibcamera.soso that it will get loaded from/system/libat runtime. Place libcamera sources andAndroid.mkinpartner/acme/chipset_or_board/libcamera/.The following stub
@@ -49,23 +49,23 @@ include $(BUILD_SHARED_LIBRARY)Android.mkfile ensures thatlibcameracompiles and links to the appropriate libraries: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+
-Network Customization Platform
-Customizing pre-loaded applications
-Customizing browser bookmarks
-Email Provider Customization
-Platform Themes+ ++ +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.shhas agdbclientcommand that handles much of the setup. For example, to attach to the +The current version of
envsetup.shhas agdbclientcommand that handles much of the setup. For example, to attach the already-runningglobaltimeapplication, 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
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 +gdbserveron the device and an ARM awaregdb, namedarm-eabi-gdb, on the desktop machine.+ -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:629Crash in C / C++ code
+Crash in C / C++ code
If it crashes, connect with
aprotoand runlogcaton 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/fb0or/dev/graphics/fb0) and driver as described in thelinux/fb.hkernel 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.0To 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:
diff --git a/pdk/docs/guide/gps.jd b/pdk/docs/guide/gps.jd index da57bef33..3af7d7d16 100755 --- a/pdk/docs/guide/gps.jd +++ b/pdk/docs/guide/gps.jd @@ -2,18 +2,21 @@ page.title=GPS pdk.version=1.0 @jd:body + +
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
@@ -44,11 +47,11 @@ include $(BUILD_SHARED_LIBRARY)gps.h. You must name your shared librarylibgps.soso that it will get loaded from/system/libat runtime. Place GPS sources and Android.mk inpartner/acme/chipset_or_board/gps/(where "acme" is your product name and "chipset_or_board" is your hardware target).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 ++++In this document
--Introduction- -
-Instrumentation Framework
-Platform Test Suites
-Running Tests- -All Tests with Default TestRunner behavior-Writing Tests
-Running all Tests Under Single Package
-Running a Single Test Suite
-A Single Test Case
-A Single Test
-Attaching a debugger to your test- -Location of Files-Troubleshooting
-Contents of makefile
-Content of Manifest
-New Instrumentation TestRunner
-New InstrumentationTestCase
-Exploring a Test Case
-Deciding Kinds of Tests to WriteIntroduction
+ +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.0Each 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
Instrumentationwith JUnit testing.
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-
This section provides an overview for various unit and functional test cases that can be executed through the instrumentation framework.
-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 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.
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.
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).
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)-
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:
$ adb shell am instrument -w \ @@ -233,7 +215,7 @@ INSTRUMENTATION_CODE: -1-
$ adb shell am instrument -w \ @@ -250,7 +232,7 @@ INSTRUMENTATION_CODE: -1-
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,
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.
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:
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)-
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 \-
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-
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> {
-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:
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:
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 ++++- -In this document
-Introduction
+ +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 (
@@ -29,7 +23,7 @@ pdk.version=1.0 -/dev/event0) and driver as described in thelinux/input.hkernel header file. For more information regarding standard Linux input drivers, please see Linux Input drivers at http://kernel.org.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 withinput_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
@@ -60,17 +54,17 @@ pdk.version=1.0 -input_register_device().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/keylayoutand/data/usr/keylayout.For each keyboard device xxx, set the
-android.keylayout.xxxsystem 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:
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 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.
-
Key character maps are stored on the device as binary resources in order to reduce loading time. Key character maps have the following characteristics:
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 '+' '+' '+' '+' '+' '+' -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.
The following file, pguide_events.c, illustrates how to implement an Android keymap driver.
@@ -485,7 +479,7 @@ MODULE_LICENSE("GPL");
-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
- + ++ ++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 libraryliblights.soso that it will get loaded from/system/libat 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() {}
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:
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.
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 - -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:
See the Android Platform Development Kit for details.
-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.
Sent by SIM to signal end of session. No content and no response.
-Communication from the upper layers to the RIL uses the commands below (defined in ril.h):
This should cause the terminal response to be sent to the SIM.
-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.
-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 +
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:
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_timeoutto 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
locknameorlockname timeoutto/sys/power/wake_locklock and, if needed, create a wakelock. The timeout here is specified in nanoseconds. Writelocknameto/sys/power/wake_unlockto 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:
