This currently only applies to the component OMX.TI.AAC.decode, it is the only one to support coalescing in the first place.
In certain edge cases (encoded audio track contains silence), each buffer would turn out to be an amazing 6(!!!) bytes, we'd spend lots and lots of time streaming network data to fill the codec's buffers of size 6144 bytes with .. silence.
Change-Id: I9f449f310fc64ca384bd02e4a783e33cf5b46fcc
related-to-bug: 2609049
QA-Impact: streamed (http) playback of aac audio content on Droid.
In case of A2DP write errors, there is an overflow in the calculation
of the sleep duration to simulate the timing of a successful write.
Change-Id: Ic4e570aebf07fac69735aab1bbc2fc73512ee795
the is_music, is_ringtone, etc columns. This ensures that custom
ringtones will still be shown in the ringtone picker after a rescan.
Bug 2594125
Change-Id: I56761240d6f6e699514169d80a445317ba0de9e2
The problem occurs if the device is powered down in silent mode. When the device restarts,
AudioService reads current ringer mode from saved settings but does not call setRingerModeInt()
to perform actions required when ringer mode changes.
The volumes of streams affected by ringer mode are actually at 0 because they are also read from settings
but their mute state is not applied correclty. When we later exit from silent mode, the streams
other than STREAM_RING that are affected by ringer mode are not restored as they are not considered
muted. This applies to STREAM_SYSTEM but also to STREAM_NOTIFICATION if its volume is controlled independently
from STREAM_RING.
The fix consists in calling setRingerModeInt() when AudioService starts.
Change-Id: Ica75b9874938dda1bc1b634c3e97db4a650d295c
There was a regression introduced by change 4c637b9e34f4c8db69a64ad21a4e2bcfa7485b5f
fixing issue 2578813. As the A2DP device disconnection is notified to the audio policy manager
after a delay, there is a period during which the A2DP device is actually not connected but the
A2DP output is considered present by audio framework. If a playback is started during this period,
The A2DP output requests the activation of the A2DP sink which in turn triggers a reconnection
of the A2DP sink.
The fix consists in suspending the A2DP output immediately when receiving the A2DP disconnection
intent so that any activity on A2DP output is ignored until the output is actually closed by the
audio policy manager.
Change-Id: I16eaace45e12bfc970f50836b46a73b756b493f0
get rid off the MAP_ONCE flag is MemoryHeapBase (as well as it's functionality),
this feature should not be used anymore.
the software renderer was incorrectly using the default ctor which set MAP_ONCE,
causing the leak. the software renderer itself is incorrectly used while coming
back from sleep.
Change-Id: I123621f8d140550b864f352bbcd8a5729db12b57
Cleanup of duplicate code
Caching Ntp data so we don't hit the network as often
Clearing out of MRU data when we switch to a new sim
Sending notification after we reset byte counts
bug:2605277
bug:2605272
bug:2597530
bug:2576057
Change-Id: I3df526bae6374f6ae56fed67b0defad2b4fabefd
The value returned is purely a function of what's passed in, all
following final members.
BUG=2606839
Change-Id: I506fb9b1f3be965576c2b3317a30ff1f990ccda3
Previously, this status icon reflected just the incoming
call behavior:
- gone for audible (with or without vibrate),
- wiggling phone for vibrate,
- silent (speaker + X) for no audible ring or vibrate.
Now that silent mode has changed (see VIBRATE_IN_SILENT),
you can easily get into a state where this icon is
confusing by setting the incoming call ringer to *never*
vibrate but setting the overall device silent state to allow
vibration (VIBRATE_IN_SILENT=true). In this case, rocking
the volume all the way down would show a wiggling phone
(because the device is in vibrate-only mode) but the status
bar would show speaker+X (because the incoming call would
neither ring nor vibrate).
Now these two icons are consistent. This means, however,
that if this special condition is set by the user (device
vibrates in silent mode, but incoming calls should never
vibrate) and the device is in silent mode, the status bar
will show a wiggling phone even though incoming calls will
not vibrate the device. This puts the ringer on a more even
footing with other apps on the device, which may elect not
to vibrate even if VIBRATE_IN_SILENT=true overall.
Bug: 2598014
Change-Id: Ib942f68738d77ab0d9b9da4fac718ae5957c133c
We believe these errors happen when the window
manager has told surface flinger to close the
native window.
If this error happens while we are creating the
EGL surface we exit the render loop (and
therefore exit the render thread.)
If the error happens while swapping the surface
we ignore it.
In either situation, we expect that the
application is about to be shut down by the
window manager, so it should not be necessary
to try and recover from the error.
Use elapsed time not wall time for alarms so users can't play with the
system time to get around things.
Also using NTP servers to pull in an authoritative time - if we the build
is configured with an NTP server we will not advance to the next cycle
without it, but we also will not trottle - rather not throttle users
on an error.
Note that the poll alarm is just relative to the last poll time and real
time doesn't matter.
Defining the time-fetching API's as returning time in the system wallclock
range (correcting if we are using NTP time internally).
bug:2597530
Change-Id: I1c0ac0923314c2f8a04edd0b36c4845352eae99a
In lightSensorChangedLocked we ignore the light sensor if the battery is low.
But in applyButtonState() and applyKeyboardState() we were still using the previous
mLightSensorScreenBrightness value, which resulted in a race condition that could
leave the button lights on after the screen turns off.
Now we ignore the light sensor value and button brightness override if the battery
is low so the low battery behavior is consistent.
Change-Id: I4943f8904299883211a95596ee207df69d1eaea2
BUG: 2570962
Signed-off-by: Mike Lockwood <lockwood@android.com>
The NotificationPlayer sets an OnCompletionListener on the
MediaPlayer it's using to play the notification.
NotificationPlayer relies on the completion event to abandon
audio focus.
The player was started before the listener was set. The theory
about the bug is that the player finished playing before the listener
was called. Therefore the audio focus was never abandonned, and
the music didn't resume.
Change-Id: Ic3baf359ea24de0d832a655dc47e745b25bc3dec
