OSDN Git Service

Add ability to set periodic alarms
authorZach Johnson <zachoverflow@google.com>
Wed, 11 Mar 2015 08:55:27 +0000 (01:55 -0700)
committerAndre Eisenbach <eisenbach@google.com>
Mon, 16 Mar 2015 23:51:48 +0000 (16:51 -0700)
commit71864f490d4dc31857df0b31924cd62a337e9f1a
tree7ff3676bca24b790a2b59bcb0f77fe8b6b1ca31b
parentd44d6401d2c0e0309f0d28a1412c295ea9fa6d7e
Add ability to set periodic alarms

Adds alarm_set_periodic so the alarm code can have more
contextual information when rescheduling alarms.

Problem: A2DP would stream for a few seconds and then
stop working.

Cause: The Java garbage collector. Bluedroid reaches out
to javaland to acquire and release the wake lock. Alarm was
always reaching out to get the wake lock when it scheduled a
short timeout. If GC kicked in during that call out to make
sure we have the wake lock, it could take more than 100ms to
get back us. That would screw over the alarm implementation
particularly for small 20ms timers.

So now if the wake lock was already acquired, we don't try to
reacquire it.

Cool. But we still have thrashing. Why? Because the alarm code
doesn't know the alarm is actually being used in a periodic way.

Here's what used to happen:

alarm expires
alarm is removed
reschedule
alarm callback is called
alarm callback sets the alarm again
alarm is added
reschedule

The problem is the first reschedule will get rid of the wake lock
if the next alarm is too far out or doesn't exist, meaning the next
reschedule needs to get the wake lock again.

With the extra periodicity information we can eliminate the
unnecessary intermediate reschedule, meaning no thrashing on the
wake lock. yay!
btif/src/btif_media_task.c
osi/include/alarm.h
osi/src/alarm.c