* changes:
docs: update the Bluetooth guide with links to the sample app, scrub the sibling files, and revise the Bluetooth package summary to point to the BT dev guide.
Bluez sends SINK_STATE_CHANGE before onAgentAuthorize, so
we may be already in CONNECTING state. This will happen with
some A2DP kits which don't like us connecting and thus we will
never be able to connect to them.
Bug:2335345
Dr No: Hiroshi
Make sure the application is always given the most recent configuration
when launcher. Use the current configuration, instead of whatever happens
to be set by the app, for reporting what it was launched with.
Change-Id: I2ffe306f56cc9092b640546dd0a28d2c29b9c0b3
For the docks, we can set if a device is preferred or not
before pairing process. This was getting overridden when we pair.
This problem doesn't happen with normal headsets.
Dr No: Eastham
Bug: 2318290
With this change, isBluetoothDock API can be used anytime and is not in tied
to dock state. The Dock State is a sticky intent so users
can query for the dock state.
Dr No: Eastham
Bug: 2133530
If a broadcast arrives at a process but the receiver has been unregistered in
the interval between dispatch and its arrival on the receiving process's side,
we were simply dropping the broadcast entirely, leading to spurious ANRs and
potentially issues involving future broadcasts being timed out incorrectly. Fix
this by making sure to correctly 'finish' a broadcast even when the recipient
app no longer has any receiver that matches the broadcast's profile.
Change-Id: If990cab021a26668052cb536753f6c308d80a5b4
Cached views would, in some situations, not update if they contained an
animating child. This was caused by clearing the dirty cache flag too
early in View.buildDrawingCache().
Approved by Dr. No mcleron.
Change-Id: I8c5f2fc3e6605657e0da625d60d50b55bb133666
Part of a fix for bug b/2300622 (Proximity sensor always blows up the lock screen while in call)
Change-Id: I9ef888638b19540a78a34507d52ff522f505102f
Signed-off-by: Mike Lockwood <lockwood@android.com>
1. PRIORITY_OFF is when user unchecks A2DP connection profile box.
2. By default, when you bond, it will be PRIORITY_ON.
3. When the profile gets connected, the priority gets set to
PRIORITY_AUTO_CONNECT. This means that we will connect
automatically to this profile.
4. When the user disconnects, we downgrade the priority to PRIORITY_ON,
which means we won't reconnect automatically.
a) We need to make a similar change to Handsfree profile.
b) We need to rework the profile management design and code which
will fix the 6 second timer that we have for A2DP reconnection.
Add AUTO_CONNECT priority for Headset profile.
Also, don't set priority to ON while disconnecting.
This logic has been pushed up to the Settings app.
Dr No: Eastham
Bug: 2133530
This doesn't really fix the problem being brought up here, but fixes a
related issue I found while investigating it -- if you tap a text view
enough to cause it to try to scroll, this will cause the touch to become
a scroll instead of a click, even if there is nothing to scroll. So
often quick taps to bring up the IME would be canceled because they
became a non-scroll.
Unfortuntately after syncing the latest build, I was having a lot of
trouble reproducing the original problem. I think I need to punt it to
MR2 at this point.
Change-Id: If1f0bf33de1b4d71c9f677cdad07639b7a3fb772
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
* 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.
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
The detach of the wallpaper engine was coming in after the containing
service was destroyed. This was possible because these are different
IPC interfaces so will not be serialized. The fix is to keep track
of all of the active engines in the serice, and detach any remaining
ones when the service is destroyed.
Change-Id: I8810786a777dd4f7b15cfbd2e0da25866a4f3ec5
