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
- Drastically cut down the number of times we supply the AudioSink with data
by estimating the time until the sink would run out of data and then scheduling
a refill in advance of that.
- Use a dedicated looper for video decoders since they are currently taking
too long to return from OMX_FillThisBuffer (bug 5325201)
- Revise thread priorities for the OMX dispatcher and software codecs, instead
of running them at ANDROID_PRIORITY_AUDIO, they now only run at
ANDROID_PRIORITY_FOREGROUND
- Since threads created by pthread_create inherit all of the parent threads
attributes including thread priority, briefly reset thread priority to
ANDROID_PRIORITY_FOREGROUND before instantiating OMX components and then
restore it.
Change-Id: If9332a3a20dad5485333d68c11de0d2d5d3fffc3
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
Fixed problem in AudioTrack::restoreTrack_l() causing a permanent
failure if the IAudioTrack interface to AudioFlinger could not be
restored at the first attempt.
Change-Id: I039d4fe2dca8d3baf71f1a6c51119f27a67b6611
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
Assume for now that all chunks are the same size, i.e. have the same number of
samples.
Change-Id: Ib8a7dfeb16cc3e5be199ff9d98b68dd0b9c23eb8
related-to-bug: 5279872
So that we don't accidentally identify a .avi file containing an mp3 track as
an mp3 file.
Change-Id: I73495b80cbb5bc1007bf810f2db453c9f175171b
related-to-bug: 5288189
MTS tests have hardcoded video framerates.
MTS can query the video framerate supported by device via
Camcorder profiles and use.
Change-Id: I61666df6af58eaba46f7366521cc114184cb4ac5
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
The list of directories to skip are configurable via setprop.
The main motivation is that some test data folder takes long time
to scan, and media scanner may compete for CPU time against perf
tests therefore skewing the results.
Bug: 5263115
Change-Id: I568213e2a4babf6033021c1d336ef0347c0e3315
Because we request 400x240 thumbnails. 100 thumbnails needs 38M,
which is too much. Change it to 70 now.
Also handle the case if the thumbnail callback throws exception.
Change-Id: Iac4ee72f308b7c7a6ae860983197601cf89bee8f
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
Do not force wake up the AudioTrack thread every 10ms if no timed
events (loop, markers..) have to be processed.
This will help reduce power consumption.
Change-Id: Icb425b13800690008dd07c27ffac84739e3dbba3
The queuebuffer could return early due to timestamp issues. Need to set
the geometry even in that case.
Change-Id: I04d7cd1df3996d640c269285398c0042923ba920
