Important safety tip: talking to the storage manager and
mount service can be very, very slow.
Bug: 3138068
Change-Id: I652e8bb2075535b42c83a46df1d8ae8bf299dd0d
Fix premature release of recording frames when physical address or metadata is stored in input video buffers
- bug 3158459
Change-Id: If297189d2a87fc3abfda68c29ac75b490b30a902
Stop handling StorageEventListener callbacks on the main
thread, where calls back into StorageManager could take a
while (i.e., during a long fsck).
Bug: 3138068
Change-Id: Icf2a836b69ff60606edce7c5575ad64dc24698c6
The implementation was guarenteed to cause deadlock when a timeout was set.
Change-Id: I59444ea784eb9057c6c4c9e9123f558b3ef5eef6
Signed-off-by: Nick Pelly <npelly@google.com>
Two issues:
1. First, due to an inverted conditional in the input dispatcher, we were
reporting touches as long touches and vice-versa to the power manager.
2. Power manager user activity cheek event suppression also suppresses touch
events (but not long touch or up events). As a result, if cheek event
suppression was enabled, touches would not poke the user activity timer.
However due to the above logic inversion, this actually affected long
touches. Net result, if cheek suppression was enabled in the power manager
and you held your thumb on the screen long enough, the phone would
go to sleep!
Cheek event suppression is commonly turned on when making a phone call.
Interestingly, it does not seem to get turned off afterward...
This change fixes the logic inversion and exempts touches from the cheek
suppression. The reason we do the latter is because the old behavior
was actually harmful in other ways too: a touch down would be suppressed
but not a long touch or the touch up. This would cause bizarre behavior
if you touched the screen while it was dimmed. Instead of brightening
immediately, it would brighten either when you lifted your finger or
300ms later, whichever came first.
Bug: 3154895
Change-Id: Ied9ccec6718fbe86506322ff47a4e3eb58f81834
My previous change was api-compatible, but some of the incidental data
in the API file (like parameter names) changed. It looks like there
were probably a couple other similar changes too, that hadn't
previously been propagated to the API file; all I did to generate this
change was say "make update-api".
Change-Id: I427a9ceb51212fde515df007613b8687b7228ce7
Adding more detail to the output logging to help track down issues, fixing some
download completed notification counter flakiness and making reboot test more
robust, and reducing the number of concurrent downloads in testMultipleDownloads()
to 10. After talking with Vasu, this is probably more appropriate as it is
closer to typical usage scenarios, and as a side effect should trim some
time from the test runs. Large numbers of downloads will be left for stress
testing.
Change-Id: Ie337cfe9b8d27299d70553e39c60e241ff3afe66
