1 page.title=Android Interfaces and Architecture 2 @jd:body 3 4 <!-- 5 Copyright 2015 The Android Open Source Project 6 7 Licensed under the Apache License, Version 2.0 (the "License"); 8 you may not use this file except in compliance with the License. 9 You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13 Unless required by applicable law or agreed to in writing, software 14 distributed under the License is distributed on an "AS IS" BASIS, 15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 See the License for the specific language governing permissions and 17 limitations under the License. 18 --> 19 <div id="qv-wrapper"> 20 <div id="qv"> 21 <h2>In this document</h2> 22 <ol id="auto-toc"> 23 </ol> 24 </div> 25 </div> 26 27 <p> 28 Android gives you the freedom to implement your own device specifications and 29 drivers. The hardware abstraction layer (HAL) provides a standard method for 30 creating software hooks between the Android platform stack and your hardware. 31 The Android operating system is also open source, so you can contribute your own 32 interfaces and enhancements. 33 </p> 34 35 <p> 36 To ensure devices maintain a high level of quality and offer a consistent user 37 experience, each device must pass tests in the compatibility test suite (CTS). 38 The CTS verifies devices meet a quality standard that ensures apps run reliably 39 and users have a good experience. For details on the CTS, see 40 <a href="{@docRoot}compatibility/index.html">Compatibility</a>. 41 </p> 42 43 <p> 44 Before porting Android to your hardware, take a moment to understand the Android 45 system architecture at a high level. Because your drivers and the HAL interact 46 with Android, knowing how Android works can help you navigate the many layers of 47 code in the Android Open Source Project (AOSP) source tree. 48 </p> 49 50 <img src="images/ape_fwk_all.png"> 51 52 <p class="img-caption"><strong>Figure 1.</strong> Android System Architecture</p> 53 54 <h2 id="Application framework">Application framework</h2> 55 <p> 56 The application framework is used most often by application developers. As a 57 hardware developer, you should be aware of developer APIs as many map directly 58 to the underlying HAL interfaces and can provide helpful information about 59 implementing drivers. 60 </p> 61 62 <h2 id="Binder IPC">Binder IPC</h2> 63 <p> 64 The Binder Inter-Process Communication (IPC) mechanism allows the application 65 framework to cross process boundaries and call into the Android system services 66 code. This enables high level framework APIs to interact with Android system 67 services. At the application framework level, this communication is hidden from 68 the developer and things appear to "just work." 69 </p> 70 71 <h2 id="System services">System services</h2> 72 <p> 73 Functionality exposed by application framework APIs communicates with system 74 services to access the underlying hardware. Services are modular, focused 75 components such as Window Manager, Search Service, or Notification Manager. 76 Android includes two groups of services: <em>system</em> (services such as 77 Window Manager and Notification Manager) and <em>media</em> (services involved 78 in playing and recording media). 79 </p> 80 81 <h2 id="Hardware Abstraction Layer">Hardware abstraction layer (HAL)</h2> 82 <p> 83 The hardware abstraction layer (HAL) defines a standard interface for hardware 84 vendors to implement and allows Android to be agnostic about lower-level driver 85 implementations. The HAL allows you to implement functionality without 86 affecting or modifying the higher level system. HAL implementations are 87 packaged into modules (<code>.so</code>) file and loaded by the Android system 88 at the appropriate time. 89 </p> 90 91 <img src="images/ape_fwk_hal.png"> 92 93 <p class="img-caption"><strong>Figure 2.</strong> Hardware abstraction layer 94 (HAL) components</p> 95 96 <p> 97 You must implement the corresponding HAL (and driver) for the specific hardware 98 your product provides. HAL implementations are typically built into shared 99 library modules (<code>.so</code> files). Android does not mandate a standard 100 interaction between your HAL implementation and your device drivers, so you have 101 free reign to do what is best for your situation. However, to enable the Android 102 system to correctly interact with your hardware, you <strong>must</strong> abide 103 by the contract defined in each hardware-specific HAL interface. 104 </p> 105 106 <h3 id="structure">Standard HAL structure</h3> 107 <p> 108 Each hardware-specific HAL interface has properties that are defined in 109 <code>hardware/libhardware/include/hardware/hardware.h</code>, which 110 guarantee that HALs have a predictable structure. 111 This interface allows the Android system to load the correct versions of your 112 HAL modules in a consistent way. There are two general components 113 that a HAL interface consists of: a module and a device. 114 </p> 115 <p> 116 A module represents your packaged HAL implementation, which is stored as a shared library (<code>.so file</code>). It contains 117 metadata such as the version, name, and author of the module, which helps Android find and load it correctly. The 118 <code>hardware/libhardware/include/hardware/hardware.h</code> header file defines a 119 struct, <code>hw_module_t</code>, that represents a module and contains information such as 120 the module version, author, and name.</p> 121 122 <p>In addition, the <code>hw_module_t</code> struct contains 123 a pointer to another struct, <code>hw_module_methods_t</code>, that contains a pointer to 124 an "open" function for the module. This open function is used to initiate communication with 125 the hardware that the HAL is serving as an abstraction for. Each hardware-specific HAL usually 126 extends the generic <code>hw_module_t</code> struct with additional information 127 for that specific piece of hardware. For example in the camera HAL, the <code>camera_module_t</code> struct 128 contains a <code>hw_module_t</code> struct along with other camera-specific function pointers: 129 </p> 130 131 <pre> 132 typedef struct camera_module { 133 hw_module_t common; 134 int (*get_number_of_cameras)(void); 135 int (*get_camera_info)(int camera_id, struct camera_info *info); 136 } camera_module_t; 137 </pre> 138 139 <p>When you implement a HAL and create the module struct, you must name it 140 <code>HAL_MODULE_INFO_SYM</code>. For instance, here is an example from the Nexus 9 audio HAL:</p> 141 <pre> 142 struct audio_module HAL_MODULE_INFO_SYM = { 143 .common = { 144 .tag = HARDWARE_MODULE_TAG, 145 .module_api_version = AUDIO_MODULE_API_VERSION_0_1, 146 .hal_api_version = HARDWARE_HAL_API_VERSION, 147 .id = AUDIO_HARDWARE_MODULE_ID, 148 .name = "NVIDIA Tegra Audio HAL", 149 .author = "The Android Open Source Project", 150 .methods = &hal_module_methods, 151 }, 152 }; 153 </pre> 154 <p> 155 A device abstracts the actual hardware of your product. For example, an audio module can contain 156 a primary audio device, a USB audio device, or a Bluetooth A2DP audio device. A device 157 is represented by the <code>hw_device_t</code> struct. Like a module, each type of device 158 defines a more-detailed version of the generic <code>hw_device_t</code> that contains 159 function pointers for specific features of the hardware. For example, the 160 <code>audio_hw_device_t</code> struct type contains function pointers to audio device operations: 161 </p> 162 163 <pre> 164 struct audio_hw_device { 165 struct hw_device_t common; 166 167 /** 168 * used by audio flinger to enumerate what devices are supported by 169 * each audio_hw_device implementation. 170 * 171 * Return value is a bitmask of 1 or more values of audio_devices_t 172 */ 173 uint32_t (*get_supported_devices)(const struct audio_hw_device *dev); 174 ... 175 }; 176 typedef struct audio_hw_device audio_hw_device_t; 177 </pre> 178 179 <p> 180 In addition to these standard properties, each hardware-specific HAL interface can define more of its 181 own features and requirements. See the <a href="{@docRoot}devices/halref/index.html">HAL reference documentation</a> 182 as well as the individual instructions for each HAL for more information on how to implement a specific interface. 183 </p> 184 185 <h3 id="modules">HAL modules</h3> 186 <p>HAL implementations are built into modules (<code>.so</code>) files and are dynamically linked by Android when appropriate. 187 You can build your modules by creating <code>Android.mk</code> files for each of your HAL implementations 188 and pointing to your source files. In general, your shared libraries must be named in a certain format, so that 189 they can be found and loaded properly. The naming scheme varies slightly from module to module, but they follow 190 the general pattern of: <code><module_type>.<device_name></code>.</p> 191 192 <p>For more information about setting up the build for each HAL, see its respective documentation.</p> 193 194 <h2 id="Linux kernel">Linux kernel</h2> 195 <p> 196 Developing your device drivers is similar to developing a typical Linux device 197 driver. Android uses a version of the Linux kernel with a few special additions 198 such as wake locks (a memory management system that is more aggressive in 199 preserving memory), the Binder IPC driver, and other features important for a 200 mobile embedded platform. These additions are primarily for system functionality 201 and do not affect driver development. 202 203 <p> 204 You can use any version of the kernel as long as it supports the required 205 features (such as the binder driver). However, we recommend using the latest 206 version of the Android kernel. For details on the latest Android kernel, see <a href="{@docRoot}source/building-kernels.html" >Building Kernels</a>. 207 </p> 208
