Fix deadlock on SensorService
If mLock is held by SensorService::threadLoop(), and a new call
from SensorEventConnection comes in to e.g. enable/disable a sensor,
this thread must wait for the mLock to be released. However, if this
thread holds mConnectionLock in SensorEventConnection, and SensorService
invokes SensorEventConnection.sendEvent, the system will come into a
deadlock because both threads are waiting for each other.
To avoid this situation unlock SensotEventConnection's mConnectionLock
while going out of scope.
Also create separate mutexes for modifying mSensorInfo and
mSensorInfoBackup for better separation.
Bug: 153188258
Test: 1) Run sensor logger and enable sensor, put app in background.
2) Open a_sns_test and start streaming sensor samples
3) Open app again and verify no system ANR, sensor samples
continue to be received on app.
Change-Id: If137f39918a8b1148dcc00f1b1d82b4454bb5c7b
diff --git a/services/sensorservice/SensorEventConnection.h b/services/sensorservice/SensorEventConnection.h
index 3ba5c07..80e7431 100644
--- a/services/sensorservice/SensorEventConnection.h
+++ b/services/sensorservice/SensorEventConnection.h
@@ -146,7 +146,13 @@
sp<SensorService> const mService;
sp<BitTube> mChannel;
uid_t mUid;
- mutable std::recursive_mutex mConnectionLock;
+
+ // A lock that should be used when modifying mSensorInfo
+ mutable std::mutex mConnectionLock;
+
+ // A lock that should be used when modifying mSensorInfoBackup
+ mutable std::recursive_mutex mBackupLock;
+
// Number of events from wake up sensors which are still pending and haven't been delivered to
// the corresponding application. It is incremented by one unit for each write to the socket.
uint32_t mWakeLockRefCount;