wip: Allow wakelock to timeout naturally#73
Open
aerusso wants to merge 1 commit into
Open
Conversation
Contributor
|
Seems like a simple code change, but I have no idea what the implications of always waiting for the wakelock to timeout are instead of releasing it ourselves. I'm not sure if it'll have unintended consequences. And we don't have a great (or any?) Android tests to confirm things are still working as intended |
When an intent is sent off after a notification event is received, the receiver may not obtain their own wakelock. In that event, despite the near-instant delivery of a push notification, the event receiver may yet still need to wait for the phone to wake again in order to actually act on the notification. In this patch, we employ the existing NOTIFICATION_RECEIVED_WAKELOCK_TIMEOUT_MILLIS value that controls the length of time the wakelock is held before expiring. Normally, this would never occur, instead the lock is released at the end of our processing of the event. However, when we release it, the receiving applications lose their ability to act before the device is accidentally woken for some other reason. Instead, we set this timeout to a more reasonable value of 3 seconds, and do NOT release it ourselves. This means that the receiving applications have around 3 seconds to act before the wakelock expires. This is less than ideal: the receiving applications should know whether or not their response deserves a wakelock, and they should themselves get and hold it until they are satisfied. However, this works around buggy AOSP versions and applications that do not implement this more ideal behavior. Signed-off-by: Antonio Russo <aerusso@aerusso.net>
aerusso
force-pushed
the
mrs/keep-wakelock-for-receivers
branch
from
October 7, 2024 02:45
e74565a to
30ce685
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When an intent is sent off after a notification event is received, the receiver may not obtain their own wakelock. In that event, despite the near-instant delivery of a push notification, the event receiver may yet still need to wait for the phone to wake again in order to actually act on the notification.
In this patch, we employ the existing
NOTIFICATION_RECEIVED_WAKELOCK_TIMEOUT_MILLISvalue that controls the length of time the wakelock is held before expiring. Normally, this would never occur, instead the lock is released at the end of our processing of the event. However, when we release it, the receiving applications lose their ability to act before the device is accidentally woken for some other reason. Instead, we set this timeout to a more reasonable value of 3 seconds, and do NOT release it ourselves. This means that the receiving applications have around 3 seconds to act before the wakelock expires.This is less than ideal: the receiving applications should know whether or not their response deserves a wakelock, and they should themselves get and hold it until they are satisfied. However, this works around buggy AOSP versions and applications that do not implement this more ideal behavior.