The noise is the residual ring tone that is still playing while the call is answered and the
audio route changed to headset or earpiece.
The fix consists in muting the ringing tone when changing mode from ringtone to in call
and delaying the route change until the audio buffers are emptied.
StringBlock instances containing UTF-8 strings use a cache to convert
into UTF-16, but using that cache and then using a JNI call to NewString
causes the UTF-8 string as well as two copies of the UTF-16 string to
be held in memory. Getting the UTF-8 string directly from the StringPool
eliminates one copy of the UTF-16 string being held in memory.
This is part 1. Part 2 will include ResXMLParser optimizations.
Change-Id: Ibd4509a485db746d59cd4b9501f544877139276c
Add a Flattenable interface to libutils which can be used to flatten
an object into bytestream + filedescriptor stream.
Parcel is modified to handle Flattenable. And GraphicBuffer implements
Flattenable.
Except for the overlay classes libui is now independent of libbinder.
Unicode.cpp used a packed data table for character data that essentially
duplicated ICU's functionality.
Change-Id: Ia68fe4ac94e89dc68d9a3f45f33f6e648a5500b7
Remove some utility functions for discovering character data
that ICU probably took over a while ago.
Change-Id: I97abe4de2f51eb2bf48679941258bc501184c3dc
This feature is currently controled by a system property.
"ro.sf.hwrotation" can be set to either 90 or 270. It'll cause
SF to rotate the screen by 90 and 270 degres respectively.
That is, if the driver reports 800x480 for instance, and
ro.sf.hwrotation is set to 90, applications will "see" a
480x800 display and will run in portrait.
This is implemented by introducing an extra "display"
transformation in the GraphicPlane.
We now always first try to use the EGLImageKHR directly before
making a copy with copybit. The copy may be needed when
EGLImage doesn't support the requested format, which is
currently the case with YUV.
At some point the implementation became complicated because of
SurfaceFlinger's special needs, since we are now relying on gralloc
we can go back to much simpler MemoryDealer.
Removed HeapInterface and AllocatorInterface, since those don't need
to be paramterized anymore. Merged SimpleMemory and Allocation.
Made SimplisticAllocator non virtual.
Removed MemoryDealer flags (READ_ONLY, PAGE_ALIGNED)
Removed a lot of unneeded code.
Added getRenderPosition() API to IAudioFlinger to retreive number of audio frames
written by AudioFlinger to audio HAL and by DSP to DAC.
Added getRenderPosition() API to AudioHardwareInterface to retreive number of audio frames
written by DSP to DAC.
Exposed AudioTrack::getPosition() to AudioSink() to make it available to media player.
Removed excessive log in AudioHardwareGeneric.
Merge commit '425324e97bba75cd69bb6c81de6248529540e6fe'
* commit '425324e97bba75cd69bb6c81de6248529540e6fe':
Fix failure to open AVRCP input device due to EPERM.
Modified AudioService.getActiveStreamType() so that STREAM_VOICE_CALL is selected when a track using this stream
type is playing.
Chanded isMusicActive() for a more generic isStreamActive(stream) method in AudioSystem, IAudioFlinger and AudioFlinger.
Sleep for 100us and try to open the input device again if it fails, with a
maximum of 10 attempts.
We need the retry logic because setting permissions on a new input device is
racy. The init process watches for new input device (via uevent) and sets the
permission on them in devices.c:make_device(). However at the same time
EventHub.cpp watches for new input devices from the system_server process, and
immediately tries to open them. I can't see a simple way to avoid this race
condition.
As best as I can tell this race condition has always exisited.
There must have been some timing change that happened recently that causes us
to hit this race condition much more often. See repro notes in referenced bug.
Bug: 2375632
make sure to fallback properly to software when copybit operation fails.
with this change, the preview image will at least be displayed in b&w
(since GL doesn't support the yuv format). This would also fix
2363506, but that one is now handled more cleanly.
First implementations of audio policy manager in Eclair branch have shown that most code is common to all platforms.
Creating AudioPolicyManagerBase base class will improve code maintainability and readability.
Audio policy manager code for platforms using generic audio previously in AudioPolicyManagerGeneric is replaced by AudioPolicyManagerBase.
Audio policy manager test code previously in AudioPolicyManagerGeneric is moved to AudioPolicyManagerBase.
Also added a wake lock for delayed commands in AudioPolicyService.
Modified AudioFlinger duplicating output thread so that audio tracks are not mixed until both outputs (A2DP and hardware) have exited standby mode. This avoids to have one output far ahead of the other and audio frames dropped because the compensation mechanism cannot keep up.
Also calculate the maximum wait time in OutputTrack::write() based the on smallest frame count of all output threads instead of the frame count of the thread the OutputTrack is connected to. This avoids starving the thread with the smallest frame count by waiting too long on the other thread.
Since the frame count was reduced on hardware output to reduce latency the difference between A2DP and hardware outputs frame counts had become problematic.
Also increased the number of overflow buffers to cope with bigger timing differences among outputs.
Merge commit 'f9b0e826689cca5ecbd40aa49f3ea7f7c73ad2a2' into eclair-mr2
* commit 'f9b0e826689cca5ecbd40aa49f3ea7f7c73ad2a2':
fix [2269582] [TOP-10][Passion_1506][APT:Camera]Sometimes camera preview screen is truncated after launching and back to home screen by home key repeatedly
When a surface is removed from the screen while it holds a "freeze lock", the
release of that lock happens in the destructor as a "safety net". However, it
doesn't trigger an update at that point.
Make sure that "freeze locks" are released from the transaction at the point
a surface is removed from the screen (if it's not on screen, it shouldn't
prevent the screen to redraw, and therefore cannot hold a freeze lock).
The refresh corresponding to that transaction will pick it up as soon as possible.
