Hal Technology for Android

Document directory

• Hal Technology of Android, #1: Introduction and development
• Hal Technology of Android, #2: Using Service Architecture
• Hal Technology of Android, #3: Exploring Android service and native service
• Hal Technology of Android, #4: Android service and Hal stub
• Hal Technology of Android, #5: drawing the struct hw_module_t of Hal
• Hal Technology of Android, #6: Summary Hal stub
• Hal Technology of Android, #7: Get proxy object
• Hal Technology of Android, #8: Hal stub

Hal Technology of Android, #1: Introduction and development

Jollen posted on October 8, 2009 AM

Android's Hal (hard image rendering) is a new concept launched by Google due to the demand of its WeChat vendors "unfair access to the source market". Its architecture is as follows. Although Hal's current "Abstraction Level" is insufficient, the current section does not fully comply with Hal's architectural specifications, but it does give us good room for thinking.

Protocol 1: Android Hal Architecture

This is the android Hal architecture proposal proposed by Patrick Brady (Google) in the speech "Anatomy & Physiology of an android" published by 2008 Google I/O. We know from this architecture that Hal aims to completely "separate" the android framework from the Linux kernel 」. So that android does not overwrite Linux kernel, it is a bit like "kernel independent, allows the development of Android framework to be carried out without considering the mobile program.

In the original Android repository, Hal mainly stores the following examples:

1. libhardware_legacy/-the past implementation, and the reading of the program's memory module.
2. libhardware/-Implementation of the new version and completion of the complete reading of Hal stub
3. RIL/-radio interface layer

Before Hal's architecture is mature (that is, the specification of Protocol 1), we will first make a simple analysis of Hal's current architecture. In addition, the Hal of Android is still scattered in different places, such as camera and WiFi. Therefore, the preceding contents do not contain all Hal program libraries.

Hal's past

Protocol 2: Android hal/libhardware_legacy

Past libhardware_legacy practices are compared to Runtime's "module" approach, that is, *. so memory is used for shared library, and Hal module is used for direct function call in Runtime (JNI. You can use the direct call method to operate the mobile program.

Of course, the application can also be directly written into * without passing through JNI *. so disconnect (dlopen) Call Method *. so is also a method.

Hal's real-time deployment

Release 3: Android hal/libhardware

The current libhardware practice has the taste of "stub. Hal stub is a proxy concept. Stub still exists in the form of *. So much, but Hal has hidden *. So many characters. Stub "provides" operation functions (operations) to Hal, while runtime obtains the operations of a specific mode (stub) to Hal, and then callback these operation functions. This kind of architecture is based on indirect function call, making Hal stub a "include" relationship, that is, Hal contains many stub (agents ). Runtime only needs to specify the "type", that is, the module ID, to obtain the operation function.

Hal's coming soon?

The new Hal practice is implemented by using JNI in zookeeper. That is, in the android architecture, modify the android runtime implementation ("core library") and perform the callback operation after obtaining the operations of the Hal model. Place the Hal modulo in Hal.

-- Jollen

Hal Technology of Android, #2: Using Service Architecture

Jollen posted at October 14,200 pm

In the previous article, we introduced the concept of Android Hal. Next, we will conduct further analysis and research. First, we should first discuss Hal's current situation first, and then submit our ideas on Hal's design.

Protocol 1: used service architecture and non-used service architecture

For example, when using a program to access a notebook, the process can be divided into the following two types:

• Using Service Architecture
• Do not use the service architecture

Using the service architecture is a more standard approach than using the service architecture, that is, the hidden parts on the rack; the hidden parts are non-service architecture. Previously, in the "Android mobile development and related technical skills: Hal and porting to users", we proposed the latest led example, this is a non-structural approach. There is a regular example on zookeeper, and you are welcome to take an exam.

Android Hal Introduction: libhardware and its legacy View more documents from jollen Chen.

The method of retrieving the service architecture is a recommended practice. Of course, this architecture should also be used because it is a standard architecture.

The role of the Service in the android framework is to "access the bottom-layer Hardware". If it is used up, it can be connected to the application program. As a result, the standard service approach is better to be unified in the processing of data communication. In this regard, Android provides the standard processing architecture, and then further discusses the architecture.

The "core libraries" on libraries is the service program implementation, that is, Android applications are directed to the service through JNI (Dalvik, then pass through the Service Catalog *. so far; rather than standard, it is used to allow the application to directly pass through JNI *. so far.

Do not use the service architecture

Because the service architecture is not used, the "framework integration" workload is smaller than that of the slave architecture, so most actual operations do not need to change the framework itself. This method is similar to the method of jumping over the framework, at this time, application developers require more design questions than developers.

For example, in the case of block operation, do I need to handle the established Java thread?

-- Jollen

Hal Technology of Android, #3: Exploring Android service and native service

Jollen posted on November 27,200 9 AM

The first two tutorials mentioned "using service architectures to integrate Hal 」. This introduces how Hal integrates with the Service Architecture and framework.

Android services include Android services and native services.

Android Service

Android service refers to Java service, which is the "server" in the Framework framework 」. The "service" mentioned here is a system service and serves as a server. It is different from the Service (Android. App. Service) discussed in the application programming. Android service uses Java to create an example.

Native service

Native service is actually a server in the runtime. In architecture design, we have two options: one is to implement the android service, and the other is to communicate through JNI and Hal stub; the other is, skip the android service to allow the application (Manager API) to communicate directly with the native service.

In the future, the android development trend should be dominated by the second approach, that is, the manager API can communicate directly with the native service APIs to better demonstrate the performance.

Hal Technology of Android, #4: Android service and Hal stub

Jollen posted on November 28,200 pm

At present, we have mentioned the concept of "Hal stub" and learned that stub is an agent, instead of using module, the direct function call method of the library.

Next, we will also mention "how to retrieve the service architecture by using a secret 」. Before interpreting Hal stub as an example, you need to understand the relationship between Android service and Hal stub, the architecture is "getting the operations provided by Hal stub through Android service 」.

The program implementation that gets Hal stub operations is actually implemented in the native service. The relevant actual implementation will be reserved for later implementation.

Relationship between Android service and Hal stub

The application uses the manager API. The manager API is sent from the android service to the native Service Catalog, and the Native service catalog is then referenced (invoke) Hal stub. This process has always passed the following three interfaces.

1. This is a remote interface, and the application and Android service are running on different processes.

2. This is a Java Native interface. In fact, JNI table is used to apply native methods and native functions.

3. In theory, this is Hal operations. In practice, Stub operations are obtained using Hal APIs, and then native service callback stub.

Hal Technology of Android, #5: drawing the struct hw_module_t of Hal

Jollen posted on December 1, 2009

Writing Hal stub, in addition to thinking about systems software, is also important.

What are the different ways of thinking?

The first task of implementing Hal stub is to "inherit struct hw_module_t abstract type 」. Class is equivalent to an abstract class (ADT ).

First, introduce the most important header partition (header file ):

# Include

Then define a module ID 」. This mdoule ID will be used by Hal to find Hal stub. We recommend that you use the most simple linear "led" as an example:

# Define led_hardware_module_id "led"

Inherit the struct hw_module_t abstract type of Hal (that is, the concept of base class) and name it structLED_ Module_t (that is, derived class ):

struct led_module_t {
   struct hw_module_t common;
};

From the perspective of Data Structure, this practice only declares an abstract data type to improve the structural characteristics of the program. However, we need to solve this issue from the perspective of architecture. "android Hal stipulates that we should not directly use struct hw_module_t". The original Article means we need to do something different.

Implementation

In the C statement, the implementation method is roughly as follows:

1. Declare a Data Structure to bring up the original basic architecture package
2. Place the original basic structure in the first field

Therefore, consider the following:

struct led_module_t {
   struct hw_module_t common;
   　
   /* Place attributes here. */
　
   /* Place methods here. */
};

Unique, in this case, there is a lack of encapsulation like public and private in the OO feature. However, the focus here is to think in the OO way, how can I change the C-Program program as an example? The most explicit part is,The role code of the program has been greatly changed..

-- Jollen

Hal Technology of Android, #6: Summary Hal stub

Jollen posted on December 4, 2009

After discussing many basic concepts, let's take a look at the implementation steps of Hal stub. Hal stub starts with "inherit Hal's struct hw_module_t". This is the design concept of Hal stub. In addition to clarifying the structures, it is also easy to perform post-renewal and renewal. The following describes how to use the actually used role to implement step-by-step execution using Hal stub and provides an example.

Hal stub (Implementation)

1. design your own wrapper Data Structure

* Too many led. h
* Define struct led_module_t
* The struct hw_module_t provided by the framework must be placed in the first field and named "common ".
* Please refer to hardware/hardware. h.

2. The meaning of led_module_t

The supporting API of the new object during initialization will be used in the constructor.

3. Define led_control_device_t

The supporting API during the control period will be used in the Manager API. Design Documents will be written later.

4. Each Hal stub must declare the module ID.

5. Declare stub operations and call back Functions

The operations component of stub must be named hal_module_info_sym. The operator name cannot be changed.

Example: LED. h

#include 

#include 
#include 

#include 
#include 

/*****************************************************************************/

struct led_module_t {
   struct hw_module_t common;
};

struct led_control_device_t {
   struct hw_device_t common;
   /* supporting control APIs go here */
   int (*set_on)(struct led_control_device_t *dev, int32_t led);
   int (*set_off)(struct led_control_device_t *dev, int32_t led);
};

/*****************************************************************************/

#define LED_HARDWARE_MODULE_ID "led"

In practice, we will not explain more here, but we will explain the design issues separately.

-- Jollen

Hal Technology of Android, #7: Get proxy object

Jollen posted on December 26,200 pm

After the completion of Hal stub's practice, the next task is to create a native service.

Thanks to a lot of "android service" and "Hal stub", let's just try again. When an Android operating system is triggered, a process is scheduled as servicemanager. Servicemanager process zookeeper manages, provides, and saves "android service 」. Android service is a Java program. Therefore, it calls C/C ++ program's native service through JNI.

Native Service also provides the runtime function, that is, core library runtime. One of the important tasks of Runtime is to "obtain the API provided by Hal stub". Therefore, this is the frontend that creates a complete native service.

What is a proxy object?

Native service calls Hal's hw_get_module () API to obtain the stub object, that is, hal_module_info_sym.

Hal will go to the terminal to find the Hal stub Protocol case. Hal stub exists in the form of *. So, and is stored in the/system/lib/HW directory. Hal will root the module ID and "Ro. product. board to find the corresponding *. so far, in our led component example, Hal will return to the led_module_t structure object (an instance of led_module_t class) to the native service.

The information we send Hal back to native service is "stub object" or "proxy object", that is, the "agent" mentioned above. The native service is accessible through the agent and the Linux mobile program. The concept of this process is shown in Example 1.

Protocol 1: Get proxy object

Hw_get_module (), which is the API provided by Hal and the most important API for implementing Hal stub. What is strange about others, this is also the only API provided by Hal serving in aosp.

-- Jollen

Hal Technology of Android, #8: Hal stub

Jollen posted at January 2, 2010 pm

Remember "Hal tips for Android, #6: Summary Hal stub" and "Hal tips for Android, #7: Get proxy object 」. After learning about the basic concepts and design on the architecture, you can start implementing Hal stub. The following is an example of how to save program example as led. C:

static struct hw_module_methods_t led_module_methods = {
    open: led_device_open
};
　
const struct led_module_t HAL_MODULE_INFO_SYM = {
    common: {
        tag: HARDWARE_MODULE_TAG,
        version_major: 1,
        version_minor: 0,
        id: LED_HARDWARE_MODULE_ID,
        name: "Simple LED module",
        author: "The Mokoid Open Source Project",
        methods: &led_module_methods,
    }
　
    /* supporting APIs go here */
};

This program is actually designed for example 1. led_module_t is the main architecture of stub (or primary class). Its name must be named hal_module_info_sym, it cannot be changed. All stub primary class names must be named hal_module_info_sym.

Layout 1: LED stub design (OOD)

An important role is as follows:

• Tag: You must specify it as hardware_module_tag.
• ID: module ID of Hal stub. For example, the module ID is "led"
• Methods: struct hw_module_methods_t, for the "method" defined by hal 」
• Struct hw_module_methods_t is the standard interface defined by Hal. The current aosp (Android open source project) contains an "open" interface.

"Open" is an interface, which means that Hal stub must implement this interface. This part is more important to Hal.

-- Jollen