Android Sensor System Architecture "go"

This article was reproduced from: http://blog.csdn.net/qianjin0703/article/details/5942579

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

1. Architecture

2. Data structure

3. Four functions

This paper explores the various levels of Android using the gravity sensor device g-sensor as an example.

1. Architecture

Android's architecture can be divided into 4 levels.

• The first level of the underlying drive layer, including the standard linux,android core driver, Android-related device driver, g-sensor device driver is present in this
• Second-level Android standard C + + library, including hardware abstraction layer, Android underlying library, local library, JNI
• Third level Android Java framwork Framework Layer
• Level four Java applications

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

1.1 Hardware Abstraction Layer

The hardware abstraction layer interacts with the underlying device driver through function calls such as open (), read (), write (), IOCTL (), poll (), and these function calls are prepared beforehand by the underlying device driver.

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

Other function calls such as read (), write (), and so on, are manipulated by the file descriptor FD on the g-sensor device.

1.2 JNI (Java Native Interface)

The JNI layer can be thought of as a supporting role in the entire architecture, and in a nutshell, it accomplishes a task, from the C + + language to the Java Language conversion. The JNI layer provides a series of interfaces for the Java framework layer, and these interface functions are implemented using, for example, Module->methods->open (), Ssensordevice->data_open (), The callback functions such as Ssensordevice->poll () interact with the hardware abstraction layer. These open (), poll () callback functions are implemented specifically in the hardware abstraction layer.

1.3 Java Framework

The framework layer provides objects of various classes and classes that can be run as daemons of the system or used by upper-level applications.

For example, Class Sensormanager, which runs as the daemon of the system at initialization time, subclasses of its subclass Sensorthread sensorthreadrunnable through Sensors_data_poll () The rotation access to the G-sensor data is realized, and Sensors_data_poll () is converted to the hardware abstraction layer by the JNI layer to implement poll () specifically.

2 Data structures

In general, hardware abstraction layer of hardware description is divided into control and data two categories.

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 will explore the various levels of Android through the Code Analysis of (*open), (*open_data_source), (*data_open) and (*poll).

34 Major functions

3.1 Module->methods->open ()

1) Framework

Sensorservice is run as a system daemon and its class constructor implements _sensors_control_init ().

2) JNI

Provides interface Android_init () for _sensors_control_init (), and executes a callback function Module->methods->open ();

3) Hardware Abstraction Layer

A concrete implementation (*open) that assigns a value to all pointers to the g-sensor callback function.

3.2 Ssensordevice->open_data_source ()

1) Framework

Sensorservice is run as a system daemon, and a public member of its class Parcelfiledescriptor obtains the device's file descriptor by implementing _sensors_control_open ().

2) JNI

Provides interface Android_open () for _sensors_control_open (), and executes a callback function Ssensordevice->open_data_source ();

3) Hardware Abstraction Layer

Specifically implemented (*open_data_source), the function obtains the file descriptor FD = open ("/dev/bma220", o_rdonly) by opening the G-sensor device node;

4) Device driver layer

The device node is established by registering the G-sensor device with Misc_register ().

3.3 Ssensordevice->data_open ()

1) Framework

Sensormanager runs as a system daemon, and its subclasses sensorthreadrunnable the behavior function run () to implement Sensors_data_open ().

2) JNI

Provides interface Sensors_data_open () for Sensors_data_open (), and executes a callback function Ssensordevice->data_open ();

3) Hardware Abstraction Layer

Implementation (*data_open), the function is to copy the obtained file descriptor FD to a DEV->FD in the sensors_data_context structure, in order to handle the data callback function such as (*poll) use.

3.4 Ssensordevice->poll ()

1) Framework

Sensormanager as a system daemon, its subclasses sensorthreadrunnable the behavior function run () implementation Sensors_data_poll (values, status, timestamp), The purpose of this function is to get the data from the bottom up about the g-sensor values, status and timestamp, and then through a behavior function of this class listener.onsensorchangedlocked (Sensorobject , values, timestamp, accuracy); Provides an interface function for the upper-level application to get g-sensor device data.

2) JNI

Provides interface Sensors_data_poll () for Sensors_data_poll (), and executes a callback function Ssensordevice->poll (Ssensordevice, &data); The resulting data is the g-sensor data that is transmitted from the bottom layer, and then, in a way, assigns the corresponding information in the database to values, status, and timestamp.

3) Hardware Abstraction Layer

Implementation (*poll), which implements interaction with the underlying driver through the IOCTL ().

IOCTL (DEV->FD, bma220_get_orientation, &orient_value);

Among them, DEV->FD is just a file descriptor (*data_open), bma220_get_orientation as a command of the IOCTL, the implementation is done by the underlying driver, Orient_ Value is the resulting g-sensor data, which assigns the corresponding data to the values, status, and time in the data structure, resulting in data communication from the underlying to the upper layer.

4) Device driver layer

Read (), write (), the IOCTL () function that interacts with the hardware abstraction layer is implemented by the device driver. Take a command of the IOCTL () Bma220_get_orientation as an example,

The data of the g-sensor is obtained through bma220_get_orientation, which is then uploaded from the kernel space to the arg of the user space.

Android Sensor System Architecture "go"