diff options
Diffstat (limited to 'src/devices/porting.jd')
| -rw-r--r-- | src/devices/porting.jd | 98 |
1 files changed, 0 insertions, 98 deletions
diff --git a/src/devices/porting.jd b/src/devices/porting.jd deleted file mode 100644 index e0b6eb8f..00000000 --- a/src/devices/porting.jd +++ /dev/null @@ -1,98 +0,0 @@ -page.title=Porting -@jd:body - -<!-- - Copyright 2010 The Android Open Source Project - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. ---> -<div id="qv-wrapper"> - <div id="qv"> - <h2>In this document</h2> - <ol id="auto-toc"> - </ol> - </div> -</div> - - <p>Android provides you with the freedom to implement your own device specifications - and the drivers to support them. The hardware abstraction layer (HAL) gives you a - standard way to create software hooks in between the Android - platform stack and your hardware. In addition, the Android operating system - is open-sourced to help you through your device's bringup.</p> - - <p>To ensure that your devices maintain a high level of quality and offers a consistent - experience for your users, they must must also - pass the tests in the compatibility test suite (CTS). CTS ensures that anyone - building a device meets a quality standard that ensures apps run reliabaly well - and gives users a good experience. For more information, see the - <a href="{@docRoot}compatibility/index.html">Compatibility</a> section.</p> - - <h2>Android Low-Level System Architecture</h2> - -<p>Before you begin porting Android to your hardware, it is important to have an -understanding of how Android works at a high level. Because your drivers and HAL code interact -with many layers of Android code, this understanding can help you find -your way through the many layers of code that are available to you through the AOSP -(Android Open Source Project) source tree. The following diagram shows a system -level view of how Android works: -</p> - -<img src="images/system-architecture.png"> - -<p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p> - - <h4>Application framework</h4> - <p>This is the level that most application developers concern themselves with. You should be - aware of the APIs available to developers as many of them map 1:1 to the underlying HAL - interfaces and can provide information as to how to implement your driver. - </p> - - <h4>Binder IPC</h4> - <p> - The Binder Inter-Process Communication mechanism allows the application framework to - cross process boundaries and call into the Android system services code. This basically allows - high level framework APIs to interact with Android's system services. At the application framework level, all - of this communication is hidden from the developer and things appear to "just work." - </p> - - <h4>System services</h4> - <p>Most of the functionality exposed through the application framework APIs must - communicate with some sort of system service to access the underlying hardware. Services - are divided into modular components with focused functionality - such as the Window Manager, Search Service, or Notification Manager. System services are grouped - into two buckets: system and media. The system services include things such as the Window or - Notification Manager. The media services include all the services involved in playing and - recording media. - </p> - -<h4>Hardware abstraction layer (HAL)</h4> -<p>The HAL serves as a standard interface that allows the Android system to call into the device - driver layer while being agnostic about the lower-level implementations of your drivers and hardware. - You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product - provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so - you have free reign to do what is best for your situation. However, you must abide by the contract - defined in each hardware-specific HAL interface for the Android system to be able - to correctly interact with your hardware. HAL implementations are typically built into - shared library modules (<code>.so</code> files). -</p> -<h4>Linux Kernel</h4> -<p>For the most part, developing your device drivers is the same as developing a typical Linux device driver. - Android uses a specialized version of the Linux kernel with a few special additions such as - wakelocks, a memory management system that is more agressive in preserving memory, - the Binder IPC driver, and other features that are important for a mobile embedded platform like Android. - These additions have less to do with driver development than with the system's functionality. The PDK - does not provide kernel sources, so you must provide your own. You can use any version of the kernel that - you want as long as it supports the required features, such as the binder driver. However, we recommend - using the latest version of the Android kernel. For the latest Android kernel, see - <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>. -</p>
\ No newline at end of file |