Android system transplantation and debugging ---> deep understanding of Android sensor system (4.0)

Once upon a time, I wrote an article on Android sensor "stunning entire basketball court "... in a twinkling of an eye, two years have passed. It's really a thing that's gone, and the technology is updated fast. Now it's 4.0 chocolate ice cream...

0. Overview

This article hopes to understand the sensor system from the dynamic perspective (application process) and static perspective (framework architecture.

1. Upper-layer applications

From the perspective of writing an application, it is relatively simple. You can obtain and process the value reported by a sensor in real time in four steps below,

1) Get the sensor service getsystemservice (sensor_service );

A sensormanager is obtained to manage the assignment and scheduling process of the sensor. Note that the sensorservice does not run on the backend. The system service actually belongs to the sensor is sensorservice. You can see the sensorservice in the # service list under the terminal: [android. gui. sensorserver].

2) the sensor type getdefasensensor (sensor. type_gravity) is obtained );

Of course, there are also a variety of strange sensors, you can refer to the android official website API or source code sensor. java.

3) register the listener sensoreventlistener

An application opens a listener interface to process sensor data. This listener is very important and widely used by the system.

4) Implement the listener callback function onsensorchanged and onaccuracychanged

For example, if the XYZ value of the gravity sensor is transformed by an algorithm to obtain the direction between the left and right sides, the callback function is used.

1.1 process space

An application corresponds to a virtual machine instance, a process, and a main thread. The main thread controls four components.

To get sensor data, you need to open a sub-thread to listen to the underlying reported data through Pol round training, and then the message mechanism sends the data to the main thread for processing.

In other words, an application has two tasks:

1) Prepare a listener interface for the main thread to accept data

2) Enable a subthread to accept the underlying data and send it to the main thread,

All the specific sensor tasks are handed over to the sensormanager for unified management.

1.2 Android SDK API

The upper layer obtains the Java framework through the sdk api. Here, the application obtains the sensormanager by remotely calling (RPC) through the aidl interface.

You can refer to the methods provided by the sdk api Android. Hardware. sensormanager class on the official website.

Simply and roughly speaking, the upper layer needs to take the underlying data, which is nothing more than two parts,

1) device type (control flow)

Get the sensor type by getsensorlist (). The process of obtaining the sensorlist is from top to bottom, Java framework-> JNI-> local framework-> standard abstraction layer-> Device Driver

2) device data (Data Stream)

When registerlistener () registers the listener, a thread is enabled. The sensor_data_poll also obtains the underlying data from top to bottom.

Here, I want to extract a paragraph from someone else...

When learning a new system, we first see the new concept. New terms, just like a large number of new terms for Android, start from code practice and start from application writing in the programmer's world. The SDK gives us a concept. In this framework, we use the function interfaces, data structures, and initialization processes provided by the SDK, we first came into contact with demo programs like "helloworld ".
World uses a variety of interface functions. For application programmers, the system he sees is the system call interface and programming process. In fact, as long as you use these interfaces, you have to accept a series of concepts. Only in this conceptual system can we work. However, we actually ignore the understanding of such a conceptual system, but only understand the system in the narrow space of programming interfaces. we understand that the system is only a tiny corner in the space for understanding the concept. There is little information to introduce the formation and understanding of this concept system. The programming interface is only one concept space, an external representation. We can abstract and describe the system situation using interfaces, protocols, and actions. The sdk api provides a semantic interface to the upstream layer, which implements an escape process between layers and becomes a collection of functions. But we seldom jump out like this to see what kind of concept space we are in. What kind of overall concept does the SDK return besides calling interfaces? The basic architecture of the target system is essentially the ing between a conceptual system and another conceptual system. Let our brain understand the concept system mapped to a ing of the concept domains that computers can implement. Assume that the Concept Domain e is m, and the machine can understand it. The essence of our software engineering is a ing process in the E? m field.

2. Java framework

Getsystemservice (sensor_service); obtains a sensormanager instance and provides a method for the upper layer.

Apart from the two methods mentioned above, it is necessary to look at the constructor of sensormanager itself,

Nativeclassinit (); On the JNI layer, obtain the JNI environment pointer env for Android. Hardware. sensor.

Sensors_module_init (); call the local framework through JNI to obtain the sensorservice. The sensorservice initializes the control flow functions.

New Sensor (); Create a Sensor Object. For details, refer to the API Android. Hardware. sensor on the official website.

Sensors_module_get_next_sensor (); the upper layer obtains all the sensor supported by the device, and stores it in the sensorlist linked list.

New sensorthread (); creates a sensor thread. When the application registerlistener () registers the listener, the thread run () is enabled. Note that the thread is blocked when no data changes.

From the perspective of the upper layer, we cannot see that sensormanager has done two important tasks:

1) obtain the local framework sensormanager. cpp and obtain the real background service sensorservice of sensor.

2) create eventqueue to manage data. This is a major change in the new version 4.0. This change leads to full rewriting of data stream content in the abstraction layer...

3. Local framework

In order not to fall into the vast sea of code, here is a simple summary,

Sensormanager is responsible for the control flow and communicates with sensorservice through the C/S Binder Mechanism.

Sensoreventqueue is responsible for data streams and reads and writes the underlying data through the pipeline mechanism.

Sensorsevice delivers the task to sensordevice, which calls the standard abstraction layer interface.

The abstract layer interface of the sensor architecture is the most standard, which achieves the separation of the abstract layer and the local framework.

Of course there are other types of abstract layer interfaces, which will not be discussed here.

This article is reproduced in: http://blog.csdn.net/qianjin0703/article/details/7568641

========================================================== ========================================================== ============================

Author: Ouyang Peng: Welcome to repost. sharing with others is the source of progress!

Reprinted Please retain the original address: http://blog.csdn.net/ouyang_peng

========================================================== ========================================================== ============================