wunter8
commented
4 months ago 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_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.