Android interface and Framework Learning

Android interface and Framework Learning

Abbreviation:

Hal:hardwareabstraction layer, hardware abstraction level

Cts:compatibilitytest Suite, Compatibility test suite

Android gives you the freedom to implement device specifications and drivers, and HAL provides a standard way to create software hooks (hooks) between the Android platform stack (platform stack) and hardware, the Android system is open source, and you can contribute your own interface and add functionality.

To ensure that the equipment remains high quality and provides a consistent user experience, each device must pass the CTS test. CTS ensures that the equipment meets quality standards, ensuring the reliable operation of the app and a good user experience.

On porting Android to your hardware platform, take the time to understand the Android system framework from a certain height. Because your drive and Hal want to interact with Android, learn how Android works to help you effectively control the multi-layered code of the Android source code tree.

Figure 1

1. Application framework Layer (APPLICATIONFRAMEWORK)

The application framework layer is mostly used by application developers, and as a hardware developer, you should know as many APIs as possible, and know the mappings between these APIs and the underlying HAL interface, which can provide useful information about implementing drivers.

2. IPC Inter-process communication mechanism binder (binder IPC)

The binder mechanism allows the application framework layer to cross process boundaries and access the Android system service code, which enables high-level framework APIs and Android system services to interact, and at the application framework level, this communication is hidden from the developer and behaves as if it were done naturally.

3. System Services

The Application Framework API provides functions and system service communication to access the underlying hardware, and the services are modular, such as the more important Windows Manager window manager, the Serarch service search services, or the Notification Manager Notification Manager. Android includes two groups of services: systems (such as Windows Manager and Notification Manager) and multimedia services (such as recording and playing media services)

4. Hal hardware abstraction level (Hardware abstraction layer)

HAL defines a standard set of interfaces for device vendors to implement, allowing Android to not know the implementation of the underlying driver. HAL allows you to implement functionality without affecting or modifying the upper system, and the HAL implementation is packaged as a module (. so file) file and loaded by the Android system when appropriate.

Figure 2

You must implement the corresponding HAL (and drive) for the hardware of the product, and the implementation of the HAL is typically compiled into a shared library module (. so file), and Android does not require a standard interaction between the HAL implementation and the device driver, so you can do the most appropriate thing based on your own situation. However, to ensure that the Android system is able to interact properly with the hardware, you must adhere to each HAL interface protocol with hardware features.

5. Standard HAL structure (STANDARE HAL structure)

Each specific hardware HAL interface has its characteristics, defined by the hardware/libhardware/include/hardware/hardware.h structure hw_module_t, which ensures that the HAL has a predictable structure. The HAL interface allows the Android system to consistently load the correct version of your HAL module. The HAL interface consists of two general-purpose components: A module and a device.

5.1 Modules (module)

The module packages the implementation of the HAL, which is embodied as a shared library. so file. It contains the version, name, and author of the module, which help Android to find and load the module, the corresponding structure of the module is hw_module_t, in hardware/libhardware/include/hardware/ Hardware.h definition, this struct describes a module and contains such as module version, author, and name.

In addition, the hw_module_t structure contains a pointer to the hw_module_methods_t struct methods,hw_module_methods_t struct contains a function pointer open that opens the module. This open function acts as an abstraction for service initiation and hardware communication, and each specific hardware HAL typically expands the generic hw_module_t structure, adding additional information to better describe the specific hardware. Like the camera HAL,

Typedefstruct Camera_module {    hw_module_t common;    Int (*get_number_of_cameras) (void);//Extended part    Int (*get_camera_info) (int camera_id,struct camera_info *info);//Extensions }camera_module_t;

When you implement a HAL and create a module structure, you must assign a value to the name member with Hal_module_info_sym, for example:

Structaudio_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 sourceproject",        . Methods = &hal_module_meth ODS,    },};

5.2 Devices (device)

The device abstracts the actual hardware of the product, such as an audio module that contains a basic audio device, a USB audio device, or a Bluetooth A2DP audio device. A device is described by a hw_device_t structure, like a module, in which each type of device can define more details on the basis of a hw_device_t struct, such as a function pointer to a hardware feature, Audio_hw_device_ T contains the function pointer get_supported_devices that points to the audio device operation.

struct Audio_hw_device {   struct hw_device_t common;    /**    * Used by audio Flinger to enumerate what devices is 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) (cons T-struct audio_hw_device *dev);  ...}; typedef struct AUDIO_HW_DEVICEAUDIO_HW_DEVICE_T;

In addition to these standard attributes, each specific hardware Halc interface can define multiple hardware-specific properties and requirements

6. Hal Module

The implementation of HAL is compiled into a module (. So) file and is dynamically linked when Android is appropriate. You can create a android.mk file for each of your HAL implementations to compile your module and point to your source code file. In general, your shared libraries must be named in some format so that they may be found and loaded. The naming scheme from module to module is slightly different, but generally follows the following form:<module_type>.<device_name>

Very important, such as module_type can be a GPS, but if the use of different GPS peripherals, can be distinguished by device_name.

7. Linux kernel

Developing your device driver is similar to developing a typical Linux device driver, Android uses a version of the Linux kernel, which adds some Android-specific content, such as wake-up lock (Wave lock, a memory manager system is more proactive to protect memory), Binder IPC drives and other important features for mobile embedded platforms, these characteristics are the main functions of the system and do not affect the development of drivers.

You can use any version kernel (such as binder driver) that supports the required special functions, but we recommend the latest version of the Android kernel.

Reference Links:

Http://source.android.com/devices/index.html

Android interface and Framework Learning