an error. This makes 'playback complete' essentially equivalent to
being paused at the end, and treats it the same as being paused at
any other position.
In earlier versions of Android, "vibrate mode" (in which
only alarms and media produce sound, but notifications may
operate the vibe motor) was only accessible by adjusting the
ringer volume (via the device's volume rocker) down until
the "vibrate" icon appeared (between the lowest ring volume
and silent mode).
Many users prefer that "silent mode" always allow vibration.
Others prefer Android's historical behavior, in which silent
mode stops the vibes as well.
To accommodate these two distinct usage patterns, we now
allow the user to decide whether vibration is allowed in
"silent mode", a user interface abstraction that now spans
both AudioManager.RINGER_MODE_VIBRATE and
AudioManager.RINGER_MODE_SILENT.
To minimize API impact (and therefore maximize backward
compatibility), RINGER_MODE_VIBRATE and RINGER_MODE_SILENT
remain unchanged. What has changed is what happens when the
user activates silent mode, either via Settings,
GlobalActions (longpress on power), volume rocker, or the
keyguard tab. In essence, there is now only one "silent"
position in these controls, and whether RINGER_MODE_VIBRATE
or RINGER_MODE_SILENT is actually set on the AudioService is
determined by a new one-off setting
(System.VIBRATE_IN_SILENT). This new setting isn't meant to
be a long-term API, however: in the future we hope to
replace and extend this design with a much more
sophisticated set of systemwide feedback profiles. ETA TBD.
Related changes:
* I09ad7d69 (GlobalActions and keyguard)
* I22ba7bcf (Settings app)
Bug: 2457183
Change-Id: I14cf91b0910261ffdfd1bf302423f41ec747d057
- I decided to completely remove jpeg decoding related stuff from this change
I think that setting is better off if it is specified by the system properties.
We don't have to include MediaProfiles.h header in skia files
This change fixes a problem where an unwanted tone is generated by audio policy manager when a MT call is answered.
This is because of a policy that replaces high visibility system sounds (ringtones, alarms...) by a beep when in call.
There is a transitory phase while the call is being answered where the phone state is changed to IN_CALL but the
ringtone is still playing. The audio policy manager then mutes the end of the ringtone and starts playing a beep
in replacement because the ringtone is categorized as high visibility.
The fix consists in changing the ringtone stream type from high visibility to low visibility. This is not a problem as
the only actual use case where a ringtone would be generated while in call is if another call is received.
But in this case, the phone system does not generate a ringtone but a call waiting tone instead.
It is therefore not required to handle a ringtone as a high visibiltiy tone that must be somehow signaled to the user
while in call.
Make sure we don't have an empty string before checking if it's a
directory since this string is tainted.
Change-Id: I5eb310ced58c3c64a7af2d11b80326efe5adbcab
