Android sensor system (gsensor ).

The bug about gsensor has not been solved recently. Instead, the android gsensor process has been gone through. I haven't written a blog for a long time, so I can't be lazy. I still have to summarize what I learned so that later people don't have to spend much time on it. At the same time, let's discuss it together, I want to correct any mistakes, which is also an incentive for myself. To put it bluntly, this article mainly analyzes the driver from the upper-layer activity to the kernel, which has a long path, but I like to figure out the architecture.

Directory:

1. APIs at the application layer;

2. Processing in framwork;

Iii. JNI in C ++;

4. kernel gsensor-driver;

 

I. Application Layer APIs

 

Let's look at an example. This example is the simplest application of gsensor. It is only used to print three values of X, Y, and Z:

[Java]
View plaincopyprint?

1. Public ClassMainExtendsActivity {
2. Private FloatX, Y, Z;
3. Protected VoidOncreate (bundle savedinstancestate ){
4. Super. Oncreate (savedinstancestate );
5. Sensormanager msensormanager = (sensormanager) getsystemservice (sensor_service );
6. Sensor sensor = msensormanager. getdefasensensor (sensor. type_gravity );
7. Sensoreventlistener lsn =NewSensoreventlistener (){
9. Public VoidOnsensorchanged (sensorevent e ){
10. System. Out. println (E. value [0]);
11. System. Out. println (E. value [1]);
12. System. Out. println (E. value [2]);
13. }
14. Public VoidOnaccuracychanged (sensor s,IntAccuracy ){
15. }
16. };
17. Msensormanager. registerlistener (LSN, sensor, sensormanager. sensor_delay_game );
18. }

Public class main extends activity {<br/> private float x, y, z; <br/> protected void oncreate (bundle savedinstancestate) {<br/> super. oncreate (savedinstancestate); <br/> sensormanager msensormanager = (sensormanager) getsystemservice (sensor_service); <br/> Sensor sensor = msensormanager. getdefasensensor (sensor. type_gravity); <br/> sensoreventlistener lsn = new sensoreventlistener () {</P> <p> Public void onsensorchanged (sensorevent e) {<br/> system. out. println (E. value [0]); <br/> system. out. println (E. value [1]); <br/> system. out. println (E. value [2]); <br/>}< br/> Public void onaccuracychanged (sensor S, int accuracy) {<br/>}< br/> }; <br/> msensormanager. registerlistener (LSN, sensor, sensormanager. sensor_delay_game); <br/>}< br/>

In this Code, we will focus on these classes: sensormanager and sensorevent. Then we will go to the framework to see how these two classes are implemented and what operations they have done.

 

Ii. Processing in framework

Related Files:/frameworks/base/CORE/Java/Android/hardware/sensormanager. Java;

This sensormanager is mainly responsible for returning the sensor type and obtaining data from the underlying layer. Getsystemservice (string name) is the corresponding manager returned Based on the name. This mechanism is also important. There are related information on the Internet and we will not discuss it here; msensormanager. getdefasensensor (type) is used to obtain the sensor of the specified type. These types can be found in the API manual, including temperature sensors and Gravity Sensors. Registerlistener registers the listener to enable the correct interface function to be called back by managersensor. When registering the listener, we can specify the sensitivity of the sensor in four levels. The API Manual provides relevant information. Let's take a look at the sensormanager constructor:

1. Obtain the windowmanager instance and monitor the screen rotation status;

2. initialize the sensorlist sensor list. The sensors_module_init () and sensors_module_get_next_sensor () Local JNI methods are called;

3. Construct the sensorthread thread (the thread is not enabled here );

Only one sensormanager is maintained in the system. The application layer only registers a listening interface to the sensormanager, enables the corresponding sensor, and sets the sensor parameters; sensormanager is obtained by calling the getsystemservice method. This method checks whether the sensormanager already exists. If an instance exists, it is returned directly.

Next we will focus on analyzing the sensorthread thread. This thread is enabled in registerlistener, and sensorthread is an endless loop. He calls the native method sensors_data_poll to poll the sensor data sent from the lower layer. Each time a data is received, the onsensorchangedlocked method in the listener proxy is called. The onsensorchangedlocked method is encapsulated into a message and sent to the messagerhandler. The registered onsensorchanged method is called, that is, the method in the preceding application interface.

 

 

Iii. JNI in C ++

Related Files:/frameworks/base/CORE/JNI/android_hardware_sensormanager.cpp;

Sensors_module_init () module initialization --> hw_get_module () --> load (), in fact, is to load the library of sensor. So;

Sensor. So is implemented at the hardware layer related to the machine. The corresponding sensor. cpp should be implemented under hardware. This file is the bottom-layer file that deals with kernel. It mainly completes opening the device file and reading the data of the device node. For example, if our gsensor is an input/output subsystem, the corresponding Event file is opened to read the coordinate data reported by the driver.

 

4. drivers in the kernel

Our implementation is relatively simple, which is the input subsystem. You can use the interrupt mode or polling mode to read data sent from the device.

 

5. sensorservice (comparison of sensormanager)

In fact, there is another very important class that is not mentioned, that is, sensorservice; now it is necessary to summarize and analyze the entire sensor.

After the system is enabled, various system services are started in sequence. The source code is in systemserver. in Java, the system will create a new sensorservice, and sensorservice will call the JNI method _ sensors_control_init, corresponding to android_init () in com_android_server_sersorservice.cpp. This is mainly to initialize the sensordevice handle for future calls; the following is the JNI method registered by com_android_server_sersorservice.cpp:

[Java]
View plaincopyprint?

1. StaticJninativemethod gmethods [] = {
2. {"_ Sensors_control_init", "() I ",(Void*) Android_init },
3. {"_ Sensors_control_open", "() landroid/OS/bundle ;",(Void*) Android_open },
4. {"_ Sensors_control_close", "() I ",(Void*) Android_close },
5. {"_ Sensors_control_activate", "(IZ) Z ",(Void*) Android_activate },
6. {"_ Sensors_control_wake", "() I ",(Void*) Android_data_wake },
7. {"_ Sensors_control_set_delay", "(I) I ",(Void*) Android_set_delay },
8. };

Static jninativemethod gmethods [] = {<br/> {"_ sensors_control_init", "() I", (void *) android_init}, <br/> {"_ sensors_control_open ", "() landroid/OS/bundle;", (void *) android_open}, <br/> {"_ sensors_control_close", "() I", (void *) android_close}, <br/> {"_ sensors_control_activate", "(IZ) Z", (void *) android_activate}, <br/> {"_ sensors_control_wake ","() I ", (void *) android_data_wake}, <br/> {" _ sensors_control_set_delay "," (I) I ", (void *) android_set_delay}, <br/> };

From this we can see that the sensorservice class is mainly responsible for controlling the sensor device. These JNI functions will eventually call the implementation in our sensor. cpp. Compare the JNI registration in our sensormanager:

[Java]
View plaincopyprint?

1. StaticJninativemethod gmethods [] = {
2. {"Nativeclassinit", "() V ",(Void*) Nativeclassinit },
3. {"Sensors_module_init", "() I ",(Void*) Sensors_module_init },
4. {"Sensors_module_get_next_sensor", "(landroid/hardware/sensor; I) I ",
5. (Void*) Sensors_module_get_next_sensor },
6. {"Sensors_data_init", "() I ",(Void*) Sensors_data_init },
7. {"Sensors_data_uninit", "() I ",(Void*) Sensors_data_uninit },
8. {"Sensors_data_open", "([ljava/IO/filedescriptor; [I) I ",(Void*) Sensors_data_open },
9. {"Sensors_data_close", "() I ",(Void*) Sensors_data_close },
10. {"Sensors_data_poll", "([f [I [J) I ",(Void*) Sensors_data_poll },
11. };

Static jninativemethod gmethods [] = {<br/> {"nativeclassinit", "() V", (void *) nativeclassinit}, <br/> {"sensors_module_init ", "() I", (void *) sensors_module_init}, <br/> {"sensors_module_get_next_sensor", "(landroid/hardware/sensor; I) I ", <br/> (void *) sensors_module_get_next_sensor}, <br/> {"sensors_data_init", "() I", (void *) sensors_data_init }, <br/> {"sensors_data_uninit", "() I", (void *) sensors_data_uninit}, <br/> {"sensors_data_open", "([ljava/IO/filedescriptor; [I) I ", (void *) sensors_data_open}, <br/> {" sensors_data_close "," () I ", (void *) sensors_data_close }, <br/> {"sensors_data_poll", "([f [I [J) I", (void *) sensors_data_poll}, <br/> };

It is not hard to see that sensormanager is mainly responsible for data transmission;

OK. Here, the sensor is basically analyzed. Among them, windowmanager deals with sensor and implements screen conversion and other operations. We will not analyze them here. I am at a limited level. I have been in touch with Android for two months. please correct me if you have any mistakes or defects.