| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This partially reverts commit e47e8520fa48bd014287eda94ea39927de73d6bc.
(the other part of that change was already removed as part of a different
change)
Change-Id: Ica7c196ab1f74f96237e64d07580832f0d50022f
|
|\ |
|
| |
| |
| |
| | |
Change-Id: Ib2b727146f6cba91b131e66d218251f5a3206fac
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a IRemoteControlClient dies, that client is set to null
in the stack of remote control entries (mRCStack). This is done
by calling registerRemoteControlClient() with a null client.
The bug is that registerRemoteControlClient(), after storing
the new client, uses it to let it know what the current
remote control display is. When that display is non null, the
client is sent the current display. So when a client died
when there was a display, the client reference was accessed
in the part of the method where we haven't yet checked whether
it is null or not.
The fix consists in moving the setting of the display on the
client (method plugRemoteControlDisplay) only after having
checked that the client is non-null.
Change-Id: Ic74d6cba9e3a3a16e78cd80a1ae5901abfeb3905
|
|
|
|
|
|
|
| |
We need to hold a wakelock while playing the keyguard lock sound,
so that it actually completes before the CPU goes to sleep.
Change-Id: I144c345383afeb911ea461b2eb17b31183b6d092
|
|\
| |
| |
| |
| |
| |
| | |
change time" into ics-factoryrom
* commit '9c43016b52afa855156aac2dc81a2bbe1e4ab436':
Bug 5045498 Keep track of RemoteControlClient play state change time
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Store the time at which a RemoteControlClient changes it playback
state, and send that time to the IRemoteControlDisplay.
This change will enable displays to implement strategies such as
timeouts (e.g. to not display transport controls for clients which have
been paused or stopped for a certain amount of time).
Change-Id: I902882500565743d455d56f6000efaf612cbe0a9
|
|\ \ |
|
| | |
| | |
| | |
| | | |
Change-Id: I3c2a803618bfdaf4915f2487669952d5e3b4dd32
|
|\ \ \
| |_|/
|/| | |
|
| | |
| | |
| | |
| | | |
Change-Id: I27376285a551e648eb0ea010dfdf6b8ed873cdd8
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Icebbafb68d8164370f98a2c36699845d10ef081b
related-to-bug: 5145483
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Update the implementation of the RemoteControlClient / Display
feature rely on PendingIntent as provided in the construction
of the RemoteControlClient instance.
The ComponentName that describes the target of the media button
events is set as the target of the Intent from which
a PendingIntent is constructed.
This ComponentName is still saved in the stack for persisting
the last media button event receiver.
This CL also updates the lockscreen IRemoteControlDisplay
implementation to use the PendingIntent supplied by the
application when sending transport control events. A (good)
side effect of doing this is that intent will be directly
targeted at the application.
Restoration of the media button event receiver
after reboot is not fully functional yet.
Change-Id: I2be82f2839e9dee1de02512437b3fb41cc386cde
|
| |
| |
| |
| |
| |
| |
| |
| | |
When applying the new bitmap from the editor to the client,
recycle the old bitmap, and set the reference to the editor
bitmap to null.
Change-Id: I7d79e4b8410e5035fa51b20be4b1ada391c84c28
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Do not identify the SCO connection client by the binder interface
passed when starting the connection as this binder changes if the
AudioManager proxy changes. Use the client PID instead.
This solves an issue with gTalk starting a SCO connection from one
AudioManager proxy and then changing audio mode from another thus
terminating the previously started SCO connection.
Change-Id: Ia3067fecc551fc15df3bf75ce0c43d181859e4f0
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
API change so RemoteControlClient is given a PendingIntent in
its constructor, which will be used for receiving media button
events from remote controls.
Leave the old constructors (but hidden) to not break
current functionality until the AudioManager and AudioService
implementations have been updated.
Change-Id: Ifa12c8036c948931adc386a827dce2936788e1cd
|
|/ /
| |
| |
| |
| |
| |
| | |
The Metadata class doesn't actually seem to be used with anything
in the SDK, and the API probably needs some work, so hide it.
Change-Id: Ifecf49130b90cbb4c588ad8104f1e7957978f789
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The RemoteControlClient API enables media application to have
information such as album art, current song, playback state
be displayed on "remote control displays", as well as be
controlled by "remote controls".
The new API consists in:
- a new class, RemoteControlClient
- new methods in AudioManager to register a RemoteControlClient
- a new class, RemoteControlClient.MetadataEditor to edit and
apply the information associated with a RemoteControlClient,
and which will be displayed on a "remote control display"
Change-Id: I5616085e4ad58ce0bbc1a5953b0a5a28d32f8703
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The problem is that any app can change the audio mode and override
a mode previously set by another app. If two apps (gTalk and Phone) compete
for audio mode ownership, there is no mechanism to maintain coherency
in the actual audio mode selected.
Added a mechanism in AudioService to manage an audio mode request stack.
Any app requesting a mode different from NORMAL enters at the top of the stack
and the requested mode is applied. When an app sets mode back to NORMAL, it exits
the stack and the new mode corresponding to the request at the top of the
stack (if any) is applied.
Change-Id: I68d1755d0922f680df4a19bfc5ab924f5a5d8ccd
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | | |
Change-Id: I97b51dadf129172d5b154e9dfd66da254e4559d7
|
|/ /
| |
| |
| | |
Change-Id: I8b711bd3c6b12f2e3e92144c0dadac72261bf914
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change removes the MediaPlayer#setTexture method. It has been
replaced with MediaPlayer#setSurface.
Change-Id: Iaecbbac7629d7092883f270694c5c67391f4ed6c
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | | |
Change-Id: I96bf9a7d0e2ce78fd19cce7bccbd4ac318748709
|
| |/
|/|
| |
| |
| |
| | |
Replace null device address string by empty sting.
Change-Id: I285c35f3345334e6d2190493b1a8a5aca1a361a4
|
|/
|
|
|
|
| |
Bug #1870981
Change-Id: Ia3ad166390c4d60cea19c3783895b078a2c4c15f
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a case where the RCD would display transport control
for a RemoteControlClient that didn't have audio focus.
This was happening because registering an RCD was directly calling
the updateRemoteControlDisplay method, without first calling
the checkUpdateRemoteControlDisplay method which verifies the
conditions before updating the display. One of those conditions
is that the audio focus stack shouldn't be empty.
To verify this fix, several functions were also rename to clearly
indicate the lock order and verify we properly synchronize on
the right objects. In doing so, a missing synchronization on
audio focus was found.
Change-Id: If1baaac224ea676aeb83ac0aefcc53f87461c32e
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is part of a multi project submit.
This is the Java and Jni changes.
Change-Id: I8851f5d865e657b7846bcded38e752f388f95895
|
|\ \ \
| |_|/
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, silent mode was entered if volume was already at 0 and
volume down key was pressed once.
The new volume management policy specifies that silent mode is entered when
volume is at last audible step and volume down key is pressed once.
Change-Id: Id3e75a99c522d8afe276868010b6e73495d23fde
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A precondition for updateRemoteControlDisplay_syncRcs() is that
mRCStack is not null. This condition was not verified when
registering a RemoteControlDisplay.
Change-Id: I0b152410e57c590114b387e9ab83f0c4d15d060d
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Update to the RemoteControlClient.Editor API:
- new method for setting metadata of type long
- methods for setting metadata throw an exception if using
the wrong key with the wrong method.
Note that this change will cause the Music2 application to
throw an exception when it tries to set the duration as a string.
Change-Id: I17cff86467851a0aff313c07653e752ae6b6180f
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an IRemoteControlDisplay registers, cause the
RemoteControlClient to send all its information to the newly
registered display.
The previous code was only sending a request for update: this
request didn't here cause the client to send the data because
a new client generation had not been synchronized among clients
and displays.
This CL uses the same code path to force an update as when audio
focus changes, or a new client registers, by calling the same
method that is called in those cases,
updateRemoteControlDisplay_syncRcs(flags).
Also in this CL: more method renames to indicate methods that
are called synchronized on mRCStack.
Change-Id: I54102f45ba1cd4812d958ecd883bec7bc45ae88f
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* changes:
MediaDump: use the MediaPlayer#setSurface method
HTML5VideoView: switch to MediaPlayer#setSurface
MediaPlayer: unhide the setSurface method
Surface: unhide the SurfaceTexture ctor
|
| |/
| |
| |
| | |
Change-Id: I2fb695ab918d1099ad7cc51bfd436712a0b640d9
|
|/
|
|
|
|
|
| |
Video Editor engine wrongly set the profile in place of level.
So level was always 1 (default value for Profile)
Change-Id: I202f866d32e81869d9692174d59d9d777a772282
|
|
|
|
|
|
|
| |
When an IRemoteControlDisplay registers, it must receive information
from the current client.
Change-Id: Id845e7a87ac74c2db2c59e0281b28a45f8d20528
|
|
|
|
|
|
|
|
| |
Cannot trust references to IRemoteControlDisplay to remain the
same when removing a RemoteControlDisplay, compare the
result of .asBinder() instead.
Change-Id: Ib2e82aa24bd4b12804bccff94a6a0090ff83bea8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RemoteControlClient / Display feature only supports one
display. If multiple displays are registered, this CL implements
the following policy:
- cannot unregister a display that is not the current one,
- registering a display when another is already registered
causes the old one to be unregistered.
This fixes a death handler leak where the previous display was
simply overwritten, without unlinking to its death.
Change-Id: I63f8a38093796e0960761936d7fc58d47b7589b3
|
|
|
|
|
|
|
|
| |
If a RemoteControlClient has a null artwork, do no attempt to
rescale the bitmap, it's ok to send a null bitmap to the
IRemoteControlDisplay.
Change-Id: I8332ccfcf18107ea0b41d4e7fa232d7f68798efc
|