first, the problem phenomenon
Cover the p-sensor first, then dial the phone, 90% of the case the screen does not automatically turn off the backlight display. Close settings-"display-" brightness-"Auto, and then do the above operation 100% to turn off the backlight display normally.
platform:mt6732
Android version: 4.4KK
Buildtype:user
System software version: Swa1h+um
System RAM:1GB
Reference machine Behavior: Reference machine 1 Normal, reference machine 2 normal
Second, the MTK platform Android sensor process framework
The entire process framework is divided into 6 main parts:
1 , Applications
This is mainly referred to as the Dialer/phoneapp, they are the user directly operating interface, they use the p-sensor to light screen and the operation of the screen (by requesting to Powermanagerservice Proximity_screen_off_wake_ Lock implementation).
2, Frameworks (JAVA)
Mainly consists of two parts:
First, Powermanager/powermanagerservice, its role is to provide proximity_screen_off_wake_lock, and interact with Sensormanager/systemsensormanager.
Second, Sensormanager/systemsensormanager, its role is to provide Java Layer Control sensor interface, and through the JNI and native Sensormanager communication.
3, Frameworks (JNI)
This is mainly referred to as Sensormanager JNI, whose main function is to provide the interface to Sensormanager/systemsensormanager and Natvielibs sensormanager communication.
4, Frameworks (libs/nativeservice)
Mainly consists of two parts:
First, Sensormanager/sensoreventqueue, which belongs to Nativelibs, the main role is to provide the interface for Sensormanager JNI, Request Sensorservice to create sensoreventqueue (Binder-based IPC) to complete sensorevent transfer from Sensorservice to Sensormanager JNI.
Second, Sensorservice/sensordevice, which belongs to the Nativeservice, the main role is to provide the upper layer interface Createsensoreventconnection, and sensor of the HAL layer to interact with, Control sensor and get sensorevent.
5,hal
This is mainly referred to as nusensors and Hwmsen, whose main function is to provide interfaces for Sensorservice, interacting with the driver layer of the sensor to control sensor and obtain sensorevent.
6,driver
Here are two main parts:
First, Hwmsen_dev/standardinputdevice, this part is in the concrete sensordriver above and abstract layer, its main function is to concentrate on different types of sensor, including Lightsensor, Proximitysensor and so on.
Second, Proximity/light (stk3x1x-new), this part refers to the specific sensordriver, its main function is to interact with the specific sensor, including control, data acquisition and reporting. One thing to note here is that there are two types of sensor: One is interrupt sensor, the other is polling sensor, the difference is that interrupt sensor is directly hooked up to a specific interrupt, Once the sensor has data, the interrupt processing is triggered (our proximitysensor belongs to interrupt sensor), polling sensor is the passive provider of data, abstracted Hwmsen_ Dev will pick up its data at a certain frequency (our lightsensor belongs to polling sensor).
Three, the problem analysis1. Preliminary analysis
According to the problem in the case of shielding p-sensor the surface of the phone can not be extinguished, we first consider the P-sensor hardware has not produced data and reported to driver, in order to confirm this we first in the driver of P-sensor added log:
Then perform the operation, and the log is typed as follows:
The above log value 0x0, representing P-sensor Close, 0x1 represents p-sensor away, so the hardware has been p-sensor data on the report of Sensordriver, Sensordriver again the data on the driver abstraction layer Hwmsen_dev/standardinputdevice, next we will see driver abstraction layer will p-sensor the data correctly escalated to the HAL. The key code in Nusensor.cpp is as follows:
The above code is the HAL that polls all the sensor and gets the event, including the P-sensor, and here is a very critical DATA type, Sensor_type_meta_data, which will specify what it does, It also shows that the implementation code for polling here is implemented by reading the Standardinputdevice node ("/dev/input/event%d", num).
After all the sensor has been polled, if there is still room to continue to poll in the sensor's DATA_FD, continue to obtain the event to populate the fetch, and then return to the upper Sensorservice. Using the same method to add log to the code stream to get the data state of the runtime, it is found that the P-sensor data is also correctly obtained, and this is not discussed here.
Then continue to analyze the data flow in the Sensorservice to see if it is correctly escalated to Sensormanager/sensoreventqueue, Sensorservice's key code is as follows:
First, from the code we see Sensorservice inherited from thread, so it is a thread and has a closed loop of threadloop, constantly reading data from the HAL of sensor, by adding log information, It is found that the data p-sensor in later code is still correctly acquired.
Second, after reading the data, it will send sensorevent to all the clients currently connected to Sensorservice, and the data in the above code, plus the log printed before the P-sensor, still exists.
Then, is specific to send to the client before the processing code, we continue to add log, found that before processing p-sensor data are present, the specific code is as follows:
Finally, it is the code that eventually sends the processed data to the client, we add log before sending, and finally we find that the P-sensor data in the printed log is no longer present , the code is as follows:
2, continue to analyze
According to the above analysis we found that before being sendevents processed, the data of p-sensor still exist, after processing before sending p-sensor data has been filtered out, we can initially set the key to the problem in the process.
By reading and analyzing the code of its processing, a key condition is found that if the sensor data wants to be sent eventually, it must satisfy the conditions of msensorinfo[index].mfirstflushpending = = False. This condition satisfies the premise that the current sensoreventconnection must first receive the Sensor_type_meta_data, the msensorinfo[index].mfirstflushpending is set to False, Then the specific sensor data received will be sent out eventually.
Based on the log that was added during the initial analysis, we found that the sensor_type_meta_data was present in the data stream of the sensor, but it was after the specific sensor data, which led to the specific sensor data being ignored ( refers to the p-sensor near the data ).
By analyzing the code, we found that Sensor_type_meta_data was the first flush event that was issued after the sensor was enable, and the key code for enable should precede the specific sensor data as follows:
First batch, then setfirstflushpending to true and flush, and in ALTO4.5TMO these operations will lay the groundwork for batchsensor to produce sensor_type_meta_data.
Will eventually go to activate, the sensor will be really enable,enable after the sensor would immediately interrupt and report data, where the P-sensor data is generated from Hwmsen (Nusensor sensorlist, Hwmsen is in the first place, which means that it will be processed first when polling data.
It is necessary to explain why Soul4na and yaris3.5at&t do not have this problem because they do not support batch, so they will return error after the batch is executed. This code branch is not executed to setfirstflushpending to true and flush, and mfirstflushpending defaults to False, with the following specific code:
The specific code for obtaining Sensor_type_meta_data from Batchsensor is as follows:
From log we find that when the HAL returns data to Sensorservice, Sensor_type_meta_data has been placed in the specific SENSOR data, In other words, when Sensorservice executes poll to obtain the sensor data, it obtains the specific sensor data, and then obtains the Sensor_type_meta_data.
3. in- depth analysis
With the above problem, it is not normal to obtain the sensor data, and then get to the sensor_type_meta_data. Comparing the normal log after turning off auto to adjust the backlight, we find a key phenomenon, that is, when the auto-adjust backlight is turned on, light sensor is already working, and 90% of the cases can block the sensorservice being dispatched by the system. That is, the execution of the poll thread will not be dispatched, the intuitive phenomenon is to see the log in the Enable execution will dispatch Sensorservice poll thread to get the event, in this case the problem is required, another 10% The situation is that in the process of enable implementation of batch just finished, to meet the generation of sensor_type_meta_data when the scheduling occurs first, so that the Sensorservice poll thread is first acquired sensor_type_ Meta_data, this situation does not have this problem, the screen can go off normally.
Based on this key phenomenon, we have further analyzed the Enable code, and then combined with light sensor on and off, we found that there is a condition difference in the execution process in driver:
a , Ten 0% can extinguish the screen normally Situation:
Turn off auto to adjust the backlight, that is, when light sensor is off, the value of obj->dc->polling_running in the Hwmsen_get_interrupt_data function is 0, So p-sensor report data will not go hwmsen_work_func, the specific code is as follows:
When the enable IOCTL has not been executed and no other active sensor is in use, the value of obj->dc->polling_running will be executed for 0,enable's IOCTL and will be obj->dc-> The value of the polling_running is set to 1, while the polling timer is turned on to polling sensor data at a certain frequency.
two , - % can't the case of off screen and Ten % can extinguish the screen Situation:
Turn on auto to adjust the backlight, which is the case where light sensor is open, the value of obj->dc->polling_running in the Hwmsen_get_interrupt_data function is 1, P-sensor report data will go Hwmsen_work_func, the specific code is as follows:
In Hwmsen_work_func, the driver of all sensor loops are traversed, and interrupt sensor and polling sensor are differentiated, and then their data is retrieved and escalated.
1. % cannot be extinguished. situation
Since P-sensor is interrupt sensor, these calls are handled in the Interrupt service program, and because the interrupt service is normally not interrupted and preempted, the CPU is stuck until the interrupt server program finishes processing and returns. If after executing batch and flush in enable, the system does not dispatch and dispatch to Sensorservice and gets to Sensor_type_meta_data first, Then it will be triggered by the Activate IOCTL p-sensor data interruption, and the p-sensor data is reported first, resulting in Sensorservice is blocked by this escalation process, ultimately affecting the sensorservice to obtain the normal flow of data.
2, Ten % can be the case of extinction
After executing the batch and flush in enable, the system is dispatched and dispatched to Sensorservice and gets to Sensor_type_meta_data first, then the ACTIVATE IOCTL triggers the P-sensor data interrupt. The p-sensor data is then escalated without affecting the normal flow of sensorservice to get the data.
4. root cause
In the absence of guaranteed system scheduling, we find that the root cause of the problem is that the P-sensor Interrupt service program is executed when light sensor is open (the value of obj->dc->polling_running is 1) and not in the upper and lower segments. Instead, all of the processing is placed in the Interrupt service program, which affects the normal execution of sensorservice and the normal sequence of data flow.
Iv. Solutions
From the above analysis, we can know that the cause of the final problem is the interrupt service program when light sensor is opened (obj->dc->polling_running A value of 1) is not performed in the next segment .
By analyzing the current code logic, structure, and testing in detail, we present the following changes and solutions that affect as little as possible:
1. In the abstract driver of sensor (HWMSEN_DEV), the function called by the Interrupt Service program of interrupt sensor (that is p-sensor): Hwmsen_get_interrupt_ The next half of the interrupt code in data is removed, only the upper half of the interrupt is processed, the critical data and state are saved, and the following code is removed:
The operation of the lower half of the interrupt is performed in a fixed-frequency timer, because the original logic of the code is to turn on the timer at enable sensor, to complete the work of interrupt sensor, with the following code:
v. Conclusions and follow-up actions
The problem of the interrupt service program in Sensor abstraction driver (Hwmsen_dev) is present in both the yaris3.5at&t and the Soul4na without the upper and lower segments, but because there is batchsensor sensor_type_ Meta_data the effects of all that did not arise with this problem. Therefore on the future MTK platform we have to check whether there is this problem, in order to avoid early, Qualcomm platform will also be concerned.
#analyzed by Vincent.song from SWD2 Framework team.
#[email protected]
#201501071718
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Analysis of the problem of ANDROID4.4KK the p-sensor to make a phone call cannot be destroyed automatically