QA-impact: This fixes http streaming again which I broke about 2 days ago. The previously observed symptoms were stuttering playback of http streams (think YouTube) after a certain playback position.
Change-Id: I14050e3522ecd62c90d29310efdf508fdd2e87b5
related-to-bug: 3098873
Added support for calibrating touch size for devices that report
size as an area measurement rather than as a width.
Fixed some bugs.
Bug: 3096045
Change-Id: I30a12e73752883516ed054f8af407204bca45814
+ Keep the wake lock for 500ms. (Some measurements on N1 indicate 160~180ms
needed to bring up InCallScreen but since INVITE doesn't come in frequently
we can be more generous just to be safe.)
+ Move MyWakeupLock out of SipService so SipSessionGroup can use it without
awkward inter-dependency with SipService.
+ Add acquire(int timeout) to be used to create the "timed" wake lock.
http://b/issue?id=3081828
Change-Id: Iffd1d78d1a5cae9f795252ada75310917095204d
- Pass to surface flinger whether we want animations or not.
- Don't use the animation when the screen goes off because of the prox sensor.
- Turn the screen-on animation back off
- Also, now the animation setting controls whether or not we do the animation.
Bug: 3097475
Bug: 3098508
Change-Id: I205d5564d6668b33a8dc1c40d8cc06c4aad305cf
Media framework test permissions were not updated when commit
14beea487c065ca902bfd7089399eb71a805e302 added
MODIFY_AUDIO_SETTINGS permission check for global effects.
Change-Id: I2a97be74f33d62fbb749642b1e7a26ddf92378f2
3097475: Animation setting should control the screen on animation
3096779: CRT power-on animation can briefly show the top app instead of lockscreen
There is now a parameter that controls wether the ON and/or OFF animation are
performed. we also always clear the screen to black on power off, to make
sure it won't briefly appear on power on.
HOWEVER, 3096779 is not 100% fixed in the case where we're doing the animation
because there is a race, where SF doesn't wait (b/c it doesn't know) for the
framework to have redrawn the lockscreen.
Change-Id: Ie0f02c9225fcdf24b1e8907e268eb7da2c5b0a03
always redraw the screen entirely after the power-on animation, because:
- the animation may not run (ie: on the emu)
- the animation may not contain the video planes
- the interpolation may not be perfect and not land exactly on the last frame
Change-Id: I9ba40f537b1e94464f8a3ed6f81e7c2f552df51d
This is a race condition exposed after we turned off some STOPSHIP
logging and some other logging. We drop the ACl connection after 2 secs
of inactivity and hence the device didn't exist -> DBUS crash.
Bug: 3097224
Change-Id: I90adbbee2c5793924037685e484027ed5cd2e0d0
now that sf handles more of the screen on/off state, we don't want to abort
because/if the animation fails for some reason (which will be the case on the
emulator).
Change-Id: I239e0a39cf8aff3074647e82db92de4a0bf0e494
+ Add MyWakeLock to maintain a global wake lock for multiple components.
+ Use a Set to store components that want to hold the lock.
+ When the first component enters the set, we grab the global wake lock.
+ When the set becomes empty, we release the global lock.
+ In places like no account being opened to receive calls, we reset the
wake lock just to be safe from possible leakage.
+ Make MyExecutor aware of the wake lock. It will grab the wake lock on
behalf of the task so that tasks don't need to worry about the lock.
+ Connectivity receiver is modified to be executed in MyExecutor.
+ WakeupTimer handler is already protected by AlarmManager's wake lock but
all the timeout handlers that register themselves to the WakeupTimer are
to be executed in MyExecutor to be protected by the wake lock.
+ Remove unnecessary code in the Keepalive and registration processes. Since
both processes are executed in MyExecutor submitted by the WakeupTimer (as
they are timeout handlers registered to the WakeupTimer), they don't need
to add themselves to MyExecutor explicitly in their run() callbacks.
+ Make the keepalive process wait for at most 3 seconds instead of forever for
server response. It could cause the wake lock to be held longer than necessary
and is a potential cause for ANR.
http://b/issue?id=3081828
Related bug:
http://b/issue?id=3087153
Change-Id: Idee0ddb837e67daa0d5092c012bb242bd7c18431
Switch to using PBKDF2 for the key generation for OBBs. Any previously
generated OBBs will stop being read correctly. A small pbkdf2gen program
is available to allow generation of appropriate keys with the salts.
Bug: 3059950
Change-Id: If4305c989fd692fd1150eb270dbf751e09c37295