There is a delay between registering the two profiles,
and handsfree profile is a superset of the headset profile.
So some devices do an SDP and get the headset profile record
before we have registered the handsfree profile.
a) We can reject all incoming connections till all profiles are
registered, but then this would mean we connect later in some cases.
Registering profiles in this order seems fine to me.
Note: There is a also the need to fix forking sdptool to register
profiles, which would obliviate the need to wait 500 msecs between
profile registrations.
Bug: 2293792
Dr No: Eastham
This fixes another case where the screen would turn on when the keyguard is open but hidden by another activity.
Change-Id: I2b7c8a329036401709e96ded4f4c138041192a71
Signed-off-by: Mike Lockwood <lockwood@android.com>
This is needed since its no longer copied to /data/dontpanic by init.
Change-Id: I5217da73ec470653824b7fb9a31e093e263a8dc9
Signed-off-by: Dima Zavin <dima@android.com>
* changes:
Rename WebChromeClient.addMessageToConsole to WebChromeClient.onConsoleMessage. Do not merge.
Update JavaDoc for CacheManger.CacheResult, WebChromeClient.getDefaultVideoPoster and WebChromeClient.getVideoLoadingProgressView. Do not merge.
Improves documentation for GeolocationPermissions class. Do not merge.
In this case, as opposed to what was happening in 1977685, the focused view wasn't the one that was
directly removed, it was a child of the removed view.
...Binary XML file line #37: Error inflating class <unknown> after adding a secondary account
The problem was that we weren't dealing well with the situation where we start a transition
from activity A to B, then transition back to A before B is shown (it finishes before being
shown), then transition from A to C. At this point we had some state showing that we
were in the process of showing A from it being hidden (due to the middle transition from
B to A), which would cause the layout pass to ensure its window is hidden before the
transition starts.
The solution is to detect the case where we are showing a token and it is already actually
shown, and in this case not do all of the token setup for it to wait for its windows to
be displayed before it is shown. This isn't needed, the windows are already displayed
or the token is already set up to wait for them to be displayed.
Change-Id: I16925b91e1e2449dd65ade162a5758173c6e2695
Also sets an explicit type for GeolocationPermissions.getOrigins.
This is a partial fix for bug http://b/issue?id=2271636
This has already been submitted to eclair-mr2.
Change-Id: I0c77eca94eb56d16c2a9a29a72eb221e4a7a52a6
This patch modifies the native binder interface to the metadata
retriever to pass the caller's thread group across the binder
interface. On the server side, the thread scheduler group is
set to the caller's scheduler group temporarily and restored
after the request has completed. This patch also reverts a
previous patch where the priority of the thread was forced to
a low priority foreground thread.
This should give apps more control over the priority of their
metadata retrieval, particularly allow background process to
run without hogging the CPU.
