Full Analysis of Android "Gravity acceleration sensor" from driver to Application Layer

1. Architecture

2. Data Structure

3. Four major functions

In this paper, G-sensor is used as an example to explore the android hierarchy.

1. Architecture

The architecture of android can be divided into four layers.

 

• The first layer is the underlying driver layer, which includes the standard Linux, Android core drivers, Android-related device drivers, and G-sensor device drivers.
• Level 2: Android standard C/C ++ libraries, including hardware abstraction layer, Android underlying libraries, local libraries, and JNI
• Level 3: Android Java Framwork framework layer
• Level 4 Java applications

This article focuses on the hardware abstraction layer, JNI, and framework.

1.1 Hardware Abstraction Layer

The Hardware Abstraction Layer interacts with underlying device drivers by calling functions such as open (), read (), write (), IOCTL (), and Poll, these function calls are prepared by the underlying Device Driver in advance.

The key to interaction is file descriptor FD. FD is obtained by opening the G-sensor device node through open (), that is, FD = open ("/dev/bma220", o_rdonly ); the/dev/bma220 device node is registered in the underlying device driver.

Other function calls, such as read () and write (), all use the file descriptor FD to operate the G-sensor device.

1.2 JNI (Java Native Interface)

The JNI layer can be considered as a supporting role in the entire architecture. In a nutshell, it completes a task that converts the C ++ language to the Java language. The JNI layer provides a series of interfaces for the Java Framework layer, and the specific implementation of these interface functions, such as module-> methods-> open (), sSensorDevice-> data_open (), callback functions such as sSensorDevice-> poll () interact with the hardware abstraction layer. These open () and poll () callback functions are implemented in the hardware abstraction layer.

1.3 Java Framework

The Framework layer provides objects of various types and classes, which can be run as the system daemon or used by upper-layer applications.

For example, the SensorManager class starts to run as the system daemon during initialization. The SensorThreadRunnable subclass in the SensorThread class implements round-training access to G-sensor data through sensors_data_poll, sensors_data_poll () is converted to the hardware abstraction layer through the JNI layer to implement poll ().

2. Data Structure

In general, the hardware abstraction layer describes the hardware in two categories: control and data.

2.1 sensors_control_context_t

Struct sensors_control_context_t {
Struct sensors_control_device_t device;

Int fd;
};

Struct sensors_control_device_t {
Struct hw_device_t common;
Int (* open_data_source) (struct sensors_control_device_t * dev );
Int (* activate) (struct sensors_control_device_t * dev, int handle, int enabled );
Int (* set_delay) (struct sensors_control_device_t * dev, int32_t MS );

Int (* wake) (struct sensors_control_device_t * dev );
};

2.2 sensors_data_context_t

Struct sensors_data_context_t {
Struct sensors_data_device_t device;

Int fd;
};

Struct sensors_data_device_t {
Struct hw_device_t common;

Int (* data_open) (struct sensors_data_device_t * dev, int fd );
Int (* data_close) (struct sensors_data_device_t * dev );
Int (* poll) (struct sensors_data_device_t * dev,
Sensors_data_t * data );
}

Struct hw_device_t {
Uint32_t tag; uint32_t version;

Struct hw_module_t * module;

Int (* close) (struct hw_device_t * device );
};

Struct hw_module_t {
Uint32_t tag; uint16_t version_major; uint16_t version_minor;

Const char * id; const char * name; const char * author;

Struct hw_module_methods_t * methods;
};

Struct hw_module_methods_t {
Int (* open) (const struct hw_module_t * module, const char * id,
Struct hw_device_t ** device );
};

The following describes the code analysis of (* open), (* open_data_source), (* data_open), and (* poll) to explore the Android architecture at various levels.

3. Four functions

3.1 module-> methods-> open ()

 

 

 

1) Framework

SensorService runs as a system daemon, and its class constructor implements _ sensors_control_init ().

2) JNI

Provide the android_init () interface for _ sensors_control_init (), and execute the callback function module-> methods-> open ();

3) Hardware Abstraction Layer

Specific implementation (* open), which assigns a value to the pointer of all G-sensor callback functions.

3.2 sSensorDevice-> open_data_source ()

 

1) Framework

SensorService runs as a system daemon. ParcelFileDescriptor, a Public Member of its class, obtains the file descriptor of the device by implementing _ sensors_control_open.

2) JNI

Provide the android_open () interface for _ sensors_control_open () and execute the callback function sSensorDevice-> open_data_source ();

3) Hardware Abstraction Layer

Specific implementation (* open_data_source). This function obtains the file descriptor fd = open ("/dev/bma220", O_RDONLY) by opening the device node of G-sensor );

4) device driver layer

Use misc_register () to register the G-sensor device and create a device node.

3.3 sSensorDevice-> data_open ()

 

 

 

1) Framework

SensorManager runs as a system daemon. The behavior function run () of its subclass SensorThreadRunnable implements sensors_data_open ().

2) JNI

Provide the sensors_data_open () interface sensors_data_open (), and execute the callback function sSensorDevice-> data_open ();

3) Hardware Abstraction Layer

For specific implementation (* data_open), the function is to copy the obtained file descriptor fd to dev-> fd in the sensors_data_context structure, this function can be used for data processing callback functions such as (* poll.

3.4 sSensorDevice-> poll ()

(If the figure below cannot be seen clearly, press Ctrl + mouse pulley to zoom in)

 

1) Framework

SensorManager runs as a system daemon. The behavior function run () of its subclass SensorThreadRunnable implements sensors_data_poll (values, status, timestamp ), the purpose of this function is to obtain the data values, status, and timestamp about G-sensor from the underlying layer, and then use this kind of behavior function listener. onSensorChangedLocked (sensorObject, values,
Timestamp, accuracy); provides an interface function for upper-layer applications to obtain G-sensor device data.

2) JNI

Provide the sensors_data_poll () interface sensors_data_poll (), and execute the callback function sSensorDevice-> poll (sSensorDevice, & data); where, the obtained data is the G-sensor data uploaded from the underlying layer, and then the corresponding data in the data is assigned to values, status, and timestamp respectively.

3) Hardware Abstraction Layer

Specific implementation (* poll). This function interacts with the underlying driver through ioctl.

Ioctl (dev-> fd, BMA220_GET_ORIENTATION, & orient_value );

Dev-> fd is the file descriptor obtained from (* data_open). BMA220_GET_ORIENTATION is a command of ioctl. The implementation is completed by the underlying driver, orient_value is the obtained G-sensor data. It assigns the corresponding data to the values, status, and time in the data struct, thus realizing data Communication from the bottom layer to the upper layer.

4) device driver layer

The read (), write (), and ioctl () functions that interact with the hardware abstraction layer are implemented by the device driver. Take an ioctl () command BMA220_GET_ORIENTATION as an example,

 

Use bma220_get_orientation (data) to obtain the data of G-sensor, and then upload it from the kernel space to the arg of the user space.