This reverts commit 1a8b6c29aaa5a1591097daca0876808cc029cbda
Reason for revert: utf8_length handles a slightly different range than the checkjni code, so it's possible for a given string to pass the utf8_length check, but then fail the jni check.
Change-Id: I81e15c95edd8f89782d8ad9025e68502b9340f22
# By Henrik Engström
# Via Android Git Automerger (1) and others
* commit '0b515aece642283a25c6a4416f0aecdaf17bdb58':
Fix possible integer overflow in MtpStorage
# By Henrik Engström
# Via Gerrit Code Review (1) and Henrik Baard (1)
* commit '3cfca67b0f1e3f464274fa5d3b2e31e5288d8f38':
Fix possible integer overflow in MtpStorage
When converting the MB value MtpReserveSpace value to bytes there is a
possible integer overflow since 3 integer values are multiplied, even
though the result is stored in a long variable. This would be visible when
the value is more than 2 GB. This is solved by making the constants
longs instead of ints.
Change-Id: I799129f7076a6e331cece17b5c05aed210499648
* commit 'e71bb7722b26ba2ada948ce3dbd626f14aabeb68':
Refactoring the media recorder stress test. Added test cases for: - record & playback @ 1080p - record & playback @ 720p - record & playback @ 480p - record & playback @ custom Plus extending the record duration to a full minute.
* commit '3f72bf323f977b367ceaee5ace321098cb7b74f4':
Refactoring the media recorder stress test. Added test cases for: - record & playback @ 1080p - record & playback @ 720p - record & playback @ 480p - record & playback @ custom Plus extending the record duration to a full minute.
Added test cases for:
- record & playback @ 1080p
- record & playback @ 720p
- record & playback @ 480p
- record & playback @ custom
Plus extending the record duration to a full minute.
Change-Id: I294714811606c1ae57907d6ef6a7052044b6247c
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
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
* 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
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
There may be cases where queryNumberEffects fails leading
to the usage of the uninitialized numEffects.
Change-Id: If6d46987021ff6f0c9a2123d8714ff5fdf9ced45
If the specified ringtone file exists but cannot be played
the Ringtone will try to play the ringtone in a remote player.
But since the file is corrupt it will not be played in the
remote player either.
According to the documentation it should attempt to
fallback on another sound. This commit will do that.
Change-Id: I0216d61ca874eef0f168ad4d5bfb07491e01e654
This saves the caller from manually iterating through the
MediaCodecList for finding the right codec.
This adds new public API.
Change-Id: I8462f040573427542d86d1b957a5aef53dd55e8e
Currently, when the codec was opened by createDecoder/EncoderByType,
the caller does not know what codec actually was chosen, and
(for encoders) thus cannot know what color formats it supports.
This adds new public API.
Change-Id: Ie471f40f8104b37d27ced3dba5a54facc6504b1b
merge from master:
"AudioService: improve low end dock audio control
Low end docks have a menu to enable use of audio
for media: automatically enabling/disabling use of audio
when the dock is connected/disconnected is useless
and can be the source of audio glitches.
Bug 7463620."
Change-Id: I3b7e7ebe660bb3f0e4367d2a3ed63ee76f78fe58
merge from master:
"audio service: set dock use on mediaserver restart
Restore forced usage of dock audio for media according to
current setting when media server restarts."
Bug 7485250.
Change-Id: Ie67b80ede1ed92d223dd96de83c1beb985dfba06
Some Wifi display devices like to rename themselves after a
connection completes (or at other times). Make sure to update
the name of the display when we detect that it changed in
our scan results.
This problem is somewhat complicated by the fact that we remember
the display name persistently, so we need to update our list
of remembered displays too.
Improve the state machine to avoid redundant attempts to
disconnect or cancel connection.
Bug: 7478895
Change-Id: I35a9e2c6a8deadbe892dacd5e3b4a5a2b12d6cf0
