The problem occurs if the delay between the headset removal and insertion is less than one second.
In this case, as the headset disconnection intent is broadcast with a 1 second delay to allow music to pause
before updating the route, the connection intent is broadcast before and is ignored, leaving the system
in a state where the headset is considered disconnected.
The fix consists in inserting a delay before broadcasting the connection intent if a disconnection
intent is pending broadcast.
- ContactHeaderWidget has cascading async queries, which weren't cancelled if a new query for a different phone number is started.
If the new query fails to find a corresponding contact, the old async queries from the previous number could end up setting the
contact name and photo to the wrong contact.
I tested this by calling
ContactHeaderWidget.bindFromPhoneNumber(number1);
ContactHeaderWidget.bindFromPhoneNumber(number2);
where number1 has a corresponding contact in the databse, and number2 doesn't. At the end of these 2 calls, the ContactHeaderWidget
would display the contact info for number1.
- also found a bug in AsyncQueryHandler.cancelOperation(), which doesn't reliably cancel the previous query. In ContactHeaderWidget's
case, we really depend on the cancelling to work. So work around this bug by resetting mAsyncQueryHandler when we need to do a
new lookup/query. When the old query result is passed back in the callback, discard the result if the QueryHandler is not the same
as mAsyncQueryHandler.
Change-Id: Ice79e77f787af03400e080cbd58162a91838181f
for the width/height on each touch down as orientation
can change.
This should fix the problem where we can't pinch on the
top right corner when device is in landscape mode.
Just scale the canvas instead of changing the real
scale factor during pinch.
Added over limit zoom feedback for pinch in the WebView.
Fix http://b/issue?id=2383539
Sleep for 100us and try to open the input device again if it fails, with a
maximum of 10 attempts.
We need the retry logic because setting permissions on a new input device is
racy. The init process watches for new input device (via uevent) and sets the
permission on them in devices.c:make_device(). However at the same time
EventHub.cpp watches for new input devices from the system_server process, and
immediately tries to open them. I can't see a simple way to avoid this race
condition.
As best as I can tell this race condition has always exisited.
There must have been some timing change that happened recently that causes us
to hit this race condition much more often. See repro notes in referenced bug.
Bug: 2375632
This shouldn't be required, but there seems to be something odd going on
in wifi and it doesn't hurt to try other available options. Makes a
connection failure case work like a disconnected case.
bug: 2378462
FCC raised the issue of not allowing users to configure
channel counts beyond 11. This change enforces the channel
count based on MCC values.
Bug: 2378844
Backported from master change Ib9285359.
We've had a couple bug reports showing the effects of a left-live feature request.
We need a bit more bugreport-time logging.
bug: 2323226
bug: 2377507
change-id: I296b2887101c260aea678bf6db91144535cbad7e
