MH2 | Implement ScopeWakelock ctor and dtor
Put the ScopedWakelock class into its own header and its implementation
into its own cpp. Implement the refcounting of the wakelocks. However,
do not incorporate the wakelock handling into post events in halproxy
yet.
Bug: 136511617
Test: No new tests yet. Will add more in a later patchset once more
fleshed out and integrated with postEvents.
Change-Id: I0815c6a6659ec5933b799294956595b11e7bf1b3
diff --git a/sensors/2.0/multihal/include/SubHal.h b/sensors/2.0/multihal/include/SubHal.h
index 6181e0b..e7eedaa 100644
--- a/sensors/2.0/multihal/include/SubHal.h
+++ b/sensors/2.0/multihal/include/SubHal.h
@@ -16,6 +16,8 @@
#pragma once
+#include "ScopedWakelock.h"
+
#include <android/hardware/sensors/1.0/types.h>
#include <android/hardware/sensors/2.0/ISensors.h>
@@ -36,45 +38,6 @@
using ::android::hardware::sensors::V1_0::SensorInfo;
/**
- * Wrapper around wake lock acquisition functions (acquire/release_wake_lock) that provides a
- * RAII-style mechanism for keeping a wake lock held for the duration of a scoped block.
- * When a ScopedWakelock is created, it increments the reference count stored in the HalProxy
- * for the sub-HALs specific wake lock, acquiring the wake lock if necessary. When the object goes
- * out of scope, the ref count is decremented, potentially releasing the wake lock if no other
- * references to the wake lock exist.
- *
- * This class is allocated through the createScopedWakelock callback inside the IHalProxyCallback
- * provided to sub-HALs during initialization and should be used for all wake lock acquisition
- * inside of the sub-HAL to ensure wake locks are not held indefinitely.
- *
- * The most prevalent use case for this class will be for posting events to the framework through
- * the postEvents HalProxy callback. The expectation is that sub-HALs will create this
- * ScopedWakelock through the createScopedWakelock upon receiving a sensor events. The lock boolean
- * provided to createScopedWakelock will be set the according to whether the sensor events are
- * from wakeup sensors. Then, the sub-HAL will perform any processing necessary before invoking the
- * postEvents callback passing in the previously created ScopedWakelock. At this point, ownership
- * of the object will be passed to the HalProxy that will then be responsible for ensuring any
- * wake locks continue to be held, if necessary.
- */
-class ScopedWakelock {
- public:
- ScopedWakelock(ScopedWakelock&&) = default;
- ScopedWakelock& operator=(ScopedWakelock&&) = default;
- virtual ~ScopedWakelock() { mLocked = false; };
-
- bool isLocked() const { return mLocked; }
-
- protected:
- bool mLocked;
-
- private:
- friend class HalProxyCallback;
- ScopedWakelock();
- ScopedWakelock(const ScopedWakelock&) = delete;
- ScopedWakelock& operator=(const ScopedWakelock&) = delete;
-};
-
-/**
* Interface that contains several callbacks into the HalProxy class to communicate dynamic sensor
* changes and sensor events to the framework and acquire wake locks. The HalProxy will ensure
* callbacks occurring at the same time from multiple sub-HALs are synchronized in a safe, efficient