The mediascanner member mIsDrm was never set
according to the drmframework canHandle call.
This subsequently caused that the isdrm column
in mediastore was never set, and was defaulted
to false for all files.
mIsDrm is now set according to drmframework
canHandle result for each files that is scanned.
Change-Id: Id557d921c4e3e3dfc35da56b69471f4bd6b3c8bf
Fixes the following problems with safe headphone volume warning message:
- Do not display the warning dialog when screen is off.
- Use the same 3 second timeout as for the volume slider to dismiss the dialog.
- Do not dismiss the warning dialog when touching outside of the slider window
but inside the warning window.
- Disable the volume slider when the warning message is displayed.
- When setting volume directly (touching the volume slider), and the warning
is displayed, save the requested volume and apply it if acknowledged by the user.
- Do not display the warning message when restoring safe volume after 20h of
cumulative listenening
Bug 7658641.
Change-Id: Ib3d1315193a433dad918aa5df78fa071062b2394
getMinBufferSize():
Simplify native_get_min_buff_size error checks and handle more errors.
setPlaybackHeadPosition():
Disallow for streaming mode [underlying AudioTrack C++ requires this].
Disallow setPlaybackHeadPosition before write().
Remove unnecessary synchronization around native_set_position().
setLoopPoints():
As setLoopPoints() is effectively a variant of setPlaybackHeadPosition(), do the same error checks.
write():
Don't set "write completed" state if write() parameters are invalid or native write fails.
It was setting "write completed" flag too early, and ignoring native write return value.
Detect integer overflow.
reloadStaticData():
Disallow reloadStaticData() before write().
Change-Id: Iec36fc0ea67095e18a2c238b148dad5545c102c1
Modified AudioService to add the possibility to mute/unmute music
with volume keys while playing over fixed volume devices (HDMI, digital dock).
VOL- forces volume to 0 and VOL+ forces volume to maximum.
Bug 7377764.
Change-Id: Ibaf805d76c30e3c0e395547cd3ce0087dbfb9f30
Allow for 160*120 thumbnails which is what cameras commonly
generates. The constants for the micro thumbnail were set to other
values, resulting in recalculations of the thumbnais, which
takes time.
This change only affects the maximum size of the temporary image,
when choosing whether to use the EXIF thumbnail or decoding and
downsampling the full image. Without this change, it will choose
an x16 downsampling of the full image over an x2 downsampling of
the EXIF thumbnail, after the change it will prefer the EXIF
thumbnail.
Cf the DCF specifications at http://www.exif.org/dcf.PDF,
"3.3.6. DCF basic thumbnail data structure, (C) Pixel count"
Tested by running DDMS and measuring the time required to create
a thumbnail. This was 220-280 ms prior to change, < 20 ms after.
Change-Id: I59c753493f947e920bad3fde5eeed5d49d509863
Before directly inserting an item that is the default ringtone, alarm or
notification, flush the MediaInserter, since a parent of the inserted item
might not have been flushed yet.
b/7650557
Change-Id: Icdd25bd9cac8b43a75e63318b936246562744c59
* commit '800c8ab68d695f1b6c5332c80a32316cdca69954':
MediaCodec: Allow getting the codec info directly
MediaCodec: Allow getting the chosen component name
* commit '2644494a9841c1f842d790b60911699f09eb63d1':
MediaCodec: Allow getting the codec info directly
MediaCodec: Allow getting the chosen component name
AudioService relies on a valid mmc in order to enforce the headset
volume limitation or not. There is a timeout to enforce the limitation
if no mcc is configured after boot.
Until this timeout is reached or a valid SIM is detected the headset
volume is not limited.
This change makes that the last known volume limitation state (enforced or
not) is persisted so that next time we boot, last known state is applied until
a new mcc is configured if any. In most cases, the mcc does not change from one
boot to the next and we do the right thing. If teh mcc does change, the correct
policy will be enforced when the mcc is detected or after the timeout.
Also fix a bug where the volume panel was not displayed if the limitation mechanism
is triggered at the first press on VOL+ key.
Bug 7455275.
Change-Id: Id0f2996d893d38c6a14f4f9e4a0e9e3be17ef127
There's no need to prohibit these APIs before the first write()
which sets up the PCM data to be played.
Change-Id: Iffbb799e7a588250dbb90a4a4575cfef143a8966
This emphasizes that it doesn't change after construction,
and will prevent accidental modification in the future.
Change-Id: I18a2cecda79bd936967de26cdaaa7b731559545d
Fixed race where mEventHandlerDelegate was accessed multiple times with
an assumption that all values read were the same.
If setPlaybackPositionUpdateListener was called with a null listener,
it did not update the delegate.
Inner classes can access final local variables of the enclosing method.
Use this to remove fields mPositionListener, mPositionListenerLock, mListener.
Change-Id: Ibf5cae61a1a9d21b745b90d4b74f9be14b66e37b
MediaRouter's policy so far has been around a single selected route,
but when route types are entirely orthogonal this should not be the
case. However we still don't want to get into a situation where we
have multiple, very different routes selected for different types at
the same time, we still want to have more of an element of
predictability.
Behavior of getSelectedRoute is now:
* If the selected route matches at least one type with the requested
type flags, it is still considered selected for that request.
* If the caller specifically requested the selected user route and the
currently selected route is not a user route, return null.
* If the requested type flags do not match any types with the selected
route, return the default system route.
Note that this is "any" behavior instead of "all" - this matches
existing usage of the method. We may consider adding an "all" variant
later on.
Bug 7588042
Change-Id: I3a79d8153ca6b882fd3ef6b9b1de8f538873dec2
Change 1f9196a8e5de9b004e61afabc70b18caf7cf9c7e introduced
an issue when trying to ignore audio focus entries in the
stack that don't use the music stream, or are for transient
audio focus gain, for remote control display updates.
The bug was that the audio focus stack traversal was not
starting from the top, as it should. It was using
the iterator order, which, in the case of a stack, starts
with the bottom-most entry.
The fix consists in traversing the stack from the top, i.e.
from the last element of the vector used to hold the stack
entries.
Bug 7311023
Change-Id: I0c1900dbf98599a621a420ab55531a3eee838fe5
