Android Interfaces and Architecture 安卓接口和架构

背景：
AOSP （Android Open Source Progject）对于安卓开发者来说是一块宝藏，奈何国内的程序员很多都看不到（被墙了），鉴于有VPN可以访问谷歌的安卓网站，特作此学习笔记。

原：
Android gives you the freedom to implement your own device specifications and drivers. The hardware abstraction layer (HAL) provides a standard method for creating software hooks between the Android platform stack and your hardware. The Android operating system is also open source, so you can contribute your own interfaces and enhancements.
译：
安卓能够让你自由实现你自己的设备规格和驱动。硬件抽象层提供了一套标准的方法用来创建安卓平台栈和你的硬件之间的软件钩子（关联）。安卓操作系统也是开源的，所以你可以贡献你的接口以及优化。

原：
To ensure devices maintain a high level of quality and offer a consistent user experience, each device must pass tests in the compatibility test suite (CTS). The CTS verifies devices meet a quality standard that ensures apps run reliably and users have a good experience. For details on the CTS, see Compatibility.
译：
为了保证设备保持高质量并且提供一致的用户体验，每个设备必须通过兼容性测试工具的测试，兼容性测试工具确保设备满足标准的要求，保证应用程序可靠的运行且能够提供良好的用户体验。兼容性测试工具的细节，请参见Compatibility相关章节。

原：
Before porting Android to your hardware, take a moment to understand the Android system architecture at a high level. Because your drivers and the HAL interact with Android, knowing how Android works can help you navigate the many layers of code in the Android Open Source Project (AOSP) source tree.
译：
在为你的设备移植安卓系统之前，应该花点时间从一定的高度来理解安卓系统架构。因为你的驱动程序和硬件抽象层需要和安卓交互，了解安卓如何工作能够帮助你在安卓开放源代码工程（AOSP）的代码树中穿梭于各个层的代码之间，游刃有余（翻译得有点过了，但就是那个意思）。

图1：安卓系统架构

Application framework 安卓应用程序框架

原：
The application framework is used most often by application developers. As a hardware developer, you should be aware of developer APIs as many map directly to the underlying HAL interfaces and can provide helpful information about implementing drivers.
译：
安卓框架大多数情况下被应用程序的开发者使用。作为一个硬件的开发者，你应该知道尽可能多的API，并且知道这些API和硬件下面的抽象层接口的直接映射关系，还要能为实现驱动程序提供游泳的信息。

Binder IPC （原义，粘合剂; 引申义，安卓内部进程通信机制的实现载体）

原：
The Binder Inter-Process Communication (IPC) mechanism allows the application framework to cross process boundaries and call into the Android system services code. This enables high level framework APIs to interact with Android system services. At the application framework level, this communication is hidden from the developer and things appear to “just work.”
译：
Binder 机制允许应用程序框架跨越进程边界调用安卓系统服务的代码。这使得高层的框架API能够和安卓系统的服务进行交互。在应用程序框架层，这种通信对开发者隐藏（隐藏了实现细节），事情表现出一种“就这样自然而然发生了”。

System services 系统服务

原：
Functionality exposed by application framework APIs communicates with system services to access the underlying hardware. Services are modular, focused components such as Window Manager, Search Service, or Notification Manager. Android includes two groups of services: system (services such as Window Manager and Notification Manager) and media (services involved in playing and recording media).
译：
应用程序框架API提供的函数和系统服务进行通信一次获取底层的硬件资源。服务是模块化的，集中的组件，例如Window Manager窗口管理器，Search Service搜索服务，或者Notification Manager通知管理器。安卓包含两组服务：系统服务（例如窗口管理器服务和通知管理器服务）和媒体服务（例如播放和录制媒体服务）。

Hardware abstraction layer (HAL)

原：
The hardware abstraction layer (HAL) defines a standard interface for hardware vendors to implement and allows Android to be agnostic about lower-level driver implementations. The HAL allows you to implement functionality without affecting or modifying the higher level system. HAL implementations are packaged into modules (.so) file and loaded by the Android system at the appropriate time.
译：
硬件抽象层定义了一组标准的接口用来让硬件厂商去实现，允许安卓不必知道底层驱动的实现。硬件抽象层允许你在不影响且不修改上层系统的情况下实现相关功能。硬件抽象层被打包成模块文件（.so文件）并且在适当的时候被安卓系统加载。

图2：硬件抽象层

原：
You must implement the corresponding HAL (and driver) for the specific hardware your product provides. HAL implementations are typically built into shared library modules (.so files). 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, to enable the Android system to correctly interact with your hardware, you must abide by the contract defined in each hardware-specific HAL interface.
译：
你必须为你产品中具体的硬件设备实现硬件抽象层和驱动层的相关代码。典型情况下，硬件抽象层是被编译成静态链接库（.so文件）的形式实现的。安卓并对你的硬件抽象层实现和你的设备驱动程序没有严格要求。但是，为了让安卓系统能够和你的硬件进行正确的交互，你必须遵照定义在每个具有硬件特性的硬件抽象层接口的协议。

Standard HAL structure 标准硬件抽象层结构

原：
Each hardware-specific HAL interface has properties that are defined in hardware/libhardware/include/hardware/hardware.h, which guarantee that HALs have a predictable structure. This interface allows the Android system to load the correct versions of your HAL modules in a consistent way. There are two general components that a HAL interface consists of: a module and a device.
译：
每个具有硬件特性的硬件抽象层都有其特性，这些特性在hardware/libhardware/include/hardware/hardware.h文件中定义，这些特性保证了硬件抽象层拥有可预见的结构。这些接口允许安卓系统能够一致性地加载你的硬件抽象层模块的正确版本。一个硬件抽象层接口由两个基本的组件组成：一个模块（module）和一个设备（device）。

原：
A module represents your packaged HAL implementation, which is stored as a shared library (.so file). It contains metadata such as the version, name, and author of the module, which helps Android find and load it correctly. The hardware/libhardware/include/hardware/hardware.h header file defines a struct, hw_module_t, that represents a module and contains information such as the module version, author, and name.
译：

原：
In addition, the hw_module_t struct contains a pointer to another struct, hw_module_methods_t, that contains a pointer to an “open” function for the module. This open function is used to initiate communication with the hardware that the HAL is serving as an abstraction for. Each hardware-specific HAL usually extends the generic hw_module_t struct with additional information for that specific piece of hardware. For example in the camera HAL, the camera_module_t struct contains a hw_module_t struct along with other camera-specific function pointers:
译：

typedef struct camera_module {
    hw_module_t common;
    int (*get_number_of_cameras)(void);
    int (*get_camera_info)(int camera_id, struct camera_info *info);
} camera_module_t;

原：
When you implement a HAL and create the module struct, you must name it HAL_MODULE_INFO_SYM. For instance, here is an example from the Nexus 9 audio HAL:
译：

struct audio_module HAL_MODULE_INFO_SYM = {
    .common = {
        .tag = HARDWARE_MODULE_TAG,
        .module_api_version = AUDIO_MODULE_API_VERSION_0_1,
        .hal_api_version = HARDWARE_HAL_API_VERSION,
        .id = AUDIO_HARDWARE_MODULE_ID,
        .name = "NVIDIA Tegra Audio HAL",
        .author = "The Android Open Source Project",
        .methods = &hal_module_methods,
    },
};

原：
A device abstracts the actual hardware of your product. For example, an audio module can contain a primary audio device, a USB audio device, or a Bluetooth A2DP audio device. A device is represented by the hw_device_t struct. Like a module, each type of device defines a more-detailed version of the generic hw_device_t that contains function pointers for specific features of the hardware. For example, the audio_hw_device_t struct type contains function pointers to audio device operations:
译：

struct audio_hw_device {
    struct hw_device_t common;

    /**
     * used by audio flinger to enumerate what devices are supported by
     * each audio_hw_device implementation.
     *
     * Return value is a bitmask of 1 or more values of audio_devices_t
     */
    uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
  ...
};
typedef struct audio_hw_device audio_hw_device_t;

原：
In addition to these standard properties, each hardware-specific HAL interface can define more of its own features and requirements. See the HAL reference documentation as well as the individual instructions for each HAL for more information on how to implement a specific interface.
HAL modules
译：

原：
HAL implementations are built into modules (.so) files and are dynamically linked by Android when appropriate. You can build your modules by creating Android.mk files for each of your HAL implementations and pointing to your source files. In general, your shared libraries must be named in a certain format, so that they can be found and loaded properly. The naming scheme varies slightly from module to module, but they follow the general pattern of: ..
译：

原：
For more information about setting up the build for each HAL, see its respective documentation.
译：

Linux kernel 内核

原：
Developing your device drivers is similar to developing a typical Linux device driver. Android uses a version of the Linux kernel with a few special additions such as wake locks (a memory management system that is more aggressive in preserving memory), the Binder IPC driver, and other features important for a mobile embedded platform. These additions are primarily for system functionality and do not affect driver development.
译：

原：
You can use any version of the kernel 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 details on the latest Android kernel, see Building Kernels.
译：