* changes:
Do not enable the rew/pause/ffwd buttons when the media being played does not support these functions. This extends the MediaPlayerControl interface with some new methods, and uses reflection to detect whether the old or new interface is used by an application.
support these functions.
This extends the MediaPlayerControl interface with some new methods, and uses
reflection to detect whether the old or new interface is used by an application.
To help track down http://b/2055197 this change adds back
exception logging when inflating initialLayout. On a hunch,
it also assigns the remote Context so generateLayoutParams()
can inflate correctly.
These are used for two purposes: a flag indicating the
default sync state for Groups to inherit, and a flag that
marks when Contacts that don't belong to any specific group
should be visible in UI.
This API is becoming seriously abused, so now it is deprecated and has
become a no-op.
As an alternative, there is now a new API that allows you to make a service
be in the foreground but requires providing a persistent notification to
go along with this state, allowing the user to know about and control it.
Merge commit 'c678a93a73c83e841032874bee9c202936da73c0' into eclair
* commit 'c678a93a73c83e841032874bee9c202936da73c0':
Fix issue #2056585: applications can put phone in inconsistent state wrt airplane mode
Merge commit 'cfa419b754332e12f8cd45244c2f3bee9d6a74bb' into eclair
* commit 'cfa419b754332e12f8cd45244c2f3bee9d6a74bb':
Correct comments for startSearch in Activity and SearchManager to explain
Merge commit 'd5884a9ba45e58294c09fd2747c87d761b9daee5' into eclair
* commit 'd5884a9ba45e58294c09fd2747c87d761b9daee5':
Unhide the broadcast intent that signals completion of the TTS language
The way View.post() is handled can cause potential leaks in ViewRoot. For instance,
if a View calls post(Runnable) just after being detached from the window (in an
onClickListener for instance,) it will enqueue a Runnable in ViewRoot.RunQueue.
Unfortunately the RunQueue is emptied only on the very first layout of the ViewRoot.
This change prevents the leak by rxecuting the enqueued Runnables on every layout request
The latter did not happen before and to keep views in a correct state I think it
is necessary to always ensure we run the Runnables sent via View.post().
http://b/issue?id=2053685. This is a tricky one. When Browser is restarted,
we may get first layout even before viewport tag is parsed. This is rare,
but it happens to Google Reader site. So we need to setup the viewport explicitly
if it happens after first layout. There is a pairing webkit change.
http://b/issue?id=2054131. When Google talk is loaded, it goes through an auth
redirect site which means first layout is called with standardLoad as false.
In this case, even the final site uses viewport tag to get mobile experience,
the intermediate one doesn't. To make sure most of the mobile sites, who
define their viewport width as device width, work correctly, we always update
the mRestoreState when we set viewport.
http://b/issue?id=2054121. When Browser is first started or restarted, the
mCurrentViewWidth is 0 as we don't know the WebView's width yet. As we can't
send VIEW_SIZE_CHANGED message directly, we reset WebView's mLastWidthSent
so that VIEW_SIZE_CHANGED will be sent from WebView when it's width is available.
This is pretty much the same thing as startSearch, except it also launches the
query. We enforce that this can only be done for the package of the app that is
associated with the search mananger (e.g you can't trigger a contacts search
from anywhere).
Split BluetoothDevice into BluetoothDevice and BluetoothAdapter.
BluetoothAdapter: Represents the local BT adapter. Operations on the local
adapter (start a scan, etc).
BluetoothDevice: Represents a remote BT device. Operations on remote devices
(pair, connect, etc).
IBluetoothDevice.aidl -> Bluetooth.aidl
BluetoothDeviceService.java -> BluetoothDeviceService.java
TODO:
Javadoc
BoringLayout assumes it doesn't have to do any work to calculate the
line height. In this case, though, there may actually be work to be
done, so have it fall back to StaticLayout to do the more thorough job.
Bug 2051050
