Not complete, only for experimentation at this point.
This includes a reworking of how screen size configurations are matched,
so that if you are on a larger screen we can select configurations for
smaller screens if there aren't any exactly matching the current screen.
The screen size at which we switch to xlarge has been arbitrarily
chosen; the compatibility behavior has not yet been defined.
Change-Id: I1a33b3818eeb51a68fb72397568c39ab040a07f5
the reason for the above change is that waitForCondition() had become
large over time, mainly to handle error cases, using inlines to
evaluate the condition doesn't buys us much anymore while it increases
code size.
Change-Id: I2595d850832628954b900ab8bb1796c863447bc7
in the undoDequeue() case, 'tail' was recalculated from 'available' and 'head'
however there was a race between this and retireAndLock(), which could cause
'tail' to be recalculated wrongly.
the interesting thing though is that retireAndLock() shouldn't have any impact
on the value of 'tail', which is client-side only attribute.
we fix the race by saving the value of 'tail' before dequeue() and restore it
in the case of undoDequeue(), since we know it doesn't depend on retireAndLock().
Change-Id: I4bcc4d16b6bc4dd93717ee739c603040b18295a0
get rid of the "fake rtti" code, and use polymorphism instead.
also simplify how we log SF's state (using polymorphism)
Change-Id: I2bae7c98de4dd207a3e2b00083fa3fde7c467922
also increase the dirtyregion size from 1 to 6 rectangles.
Overall we now need 27KiB process instead of 4KiB
Change-Id: Iebda5565015158f49d9ca8dbcf55e6ad04855be3
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
Merge commit '26f6163557980062dbb203388b3d0794ee0d06f7' into kraken
* commit '26f6163557980062dbb203388b3d0794ee0d06f7':
fix [2599939] "cannot play video" after open/close a video player a dozen of times
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
Merge commit 'e7d5a2f9ae47d8ea8face3f1e451314ed36f4026' into kraken
* commit 'e7d5a2f9ae47d8ea8face3f1e451314ed36f4026':
fix [2594950] Flash: Zooming in on some content crashes the Nexus One and causes it to reboot (runtime restart)
We now limit the size of the surface to the maximum size supported by the GPU.
On Nexus One this will 2048 -- it could be different on other devices.
Surface creation fails if the limit is exceeded.
Change-Id: I9ecfc2e9c58c9e283782b61ebfc6b590f71df785
This changes fixes the issue for the direct output thread that was not
addressed by commit 71f37cd8a175ee00635cb91506d6810fd02b5b51.
Change-Id: I1bbe26be5f444415dd97270e49257650f5d2858f
Each process maintains an array of active SurfaceComposerClient
objects, so that they can be reused as new surfaces are parceled
across. When a SurfaceComposerClient is disposed, it will remove
itself from this list. However, because the list maintains a strong
reference on the object, a reference cycle is created, and the
client is never deleted.
This patch changes the list to maintain weak pointers on the clients
instead.
Change-Id: I93dc8155fe28b4e350366a3400cdf22a8c77cdd3
The problem is a bug in AudioFlinger::MixerThread::prepareTracks_l() that makes that even if the TrackHandle
is destroyed, the corresponding Track will remain active as long as frames are ready for mixing.
If the track uses shared memory (static mode) and the sound is looped, this track will play for ever.
The fix consists in removing the track from active list immediately if the track is terminated.
Change-Id: I4582aa1d981079ab79be442fb6185f5afaed5cf3
[Sorted|Keyed]Vector<TYPE> would leak their whole storage when resized
from the end and TYPE had trivial dtor and copy operators.
Change-Id: I8555bb1aa0863df72de27d67ae50e20706e90cf5
Vector::sort() is using _do_copy() incorrectly; _do_copy() calls the
copy constructor, not the assignment operator, so we need to destroy
the "destination" before copying the item.
Change-Id: Iaeeac808fa5341a7d219edeba4aa63d44f31473c
Condition must be initialized with SHARED for the old behavior, where
they can be used accross processes.
Updated the two places android that require SHARED conditions.
PRIVATE conditions (and mutexes) use more efficient syscalls.
Change-Id: I9a281a4b88206e92ac559c66554e886b9c62db3a
On binder incalls, the handler thread is given the caller's priority by the
driver, but not the caller's cgroup. We have explicit code that sets the
handler's cgroup to match the caller's, *except* that the system process
explicitly disables this behavior. This led to a siuation in which we were
running binder incalls to the system process at nice=10 but cgroup=fg.
That's fine as far as it goes, except that if a GC happened in the handler
thread, it would be promoted to foreground priority and cgroup both, to avoid
having the GC take forever. Then, when GC finished, the original priority
is reset, and the cgroup set *based on that priority*. This would push the
handler thread into nice=10 cgroup=bg_non_interactive -- which matches the
caller, but is supposed to be impossible in the system process.
The end result of this was that we could be running "lengthy" operations in
the system process in the background. Unfortunately, some of the operations
that wound up like this would hold important global system locks for up to
twenty seconds as a result, making the entire device unresponsive to input
for that period.
This CL fixes the binder incall setup to ensure that within the system process,
a binder incall is always begun from the normal foreground priority as well
as cgroup. In practice now the device still becomes laggy/sluggish when the
offending lock-holding time-consuming incall occurs, but since it still runs
as a foreground task it is able to proceed to completion within a short time
rather than taking 20 seconds.
Fixes bug #2403717
Change-Id: Id046aeabd0e80c48eef94accc37842835eab308d
- AudioPolicyManager: allow platform specific choice for opening a direct output.
Also fixed problems in direct output management.
- AudioFliinger: use shorter standby delay and track inactivity grace period for direct output
thread to free hardware resources as soon as possible.
- AudioSystem: do not use cached output selection in getOutput() when a direct output
can be selected.
Change-Id: If44b50d29237b8402ffd7a5ba1dc43c56f903e9b
if a buffer couldn't be allocated because of an OOM, SF could, in some case dereference
a null pointer.
Change-Id: I5321248c38a21e56d5278b6aada2694e64451378
the framebuffer implementation doesn't do anything special with this
but the surfaceflinger implementation makes sure the surface is not used
by two APIs simultaneously.
Change-Id: Id4ca8ef7093d68846abc2ac814327cc40a64b66b
This loosens our restriction on many manifest attributes requiring
literal string values, to allow various ones to use values from
resources. This is only allowed if the resource value does not change
from configuration changes, and the restriction is still in place
for attributes that are core to security (requesting permissions) or
market operation (used libraries and features etc).
Change-Id: I4da02f6a5196cb6a7dbcff9ac25403904c42c2c8
Part 1 of the fix: when the user doesn't elect to use the car dock
for music and media, the APM was not aware of the device being
docked.
This is fixed by dissociating the notification for the APM of
the docking to the dock from the sink state change of the A2DP
device.
Also missing was forcing the volumes to be reevaluated whenever
the device is docked or undocked, as volumes for docks may
differ, even when the same output device is being used.
Change-Id: If5314e27821a71adbd6df6fdf887c45208241d96
- fix a bug when hacking video buffers into gralloc buffers
where the buffer size was incorrect this was causing the
"direct-form-texture" mode to fail
- also when the above fails, make sure to revert to the
"mdp copy mode" before going to "slow mode"
- finally disable completely the "direct-from-texture" mode
for now. It cannot work because the allocated buffers can't
respect the GPU constraints (alignment and such). We'll
have to find a solution for that.
The problem is that AudioRecord never exits read() when a timeout occurs while trying
to get new PCM data from audio hardware input buffer: it just keeps waiting and retrying until stop() is called.
In the same time, opencore AndroidAudioInput::audin_thread_func() loop cannot be exited when stuck
in AudioRecord::read() because the iExitAudioThread flag can only be sampled when AudioRecord::read()
returns. We remain stuck with the audio input thread running.
The fix consists in modifying AudioRecord behavior in case of timeout when getting new PCM samples.
We now wait only one timeout period and try to restart audio record, in case the problem is due to a media_server
process crash. If this fails, we exit read() with a number of bytes read equals to 0 so that
AndroidAudioInput::audin_thread_func() loop can exit.
Also modified Audioflinger::RecordThread() loop so that we attempt to recover from HAL read errors.
In case of read error, the input stream is forced to standby so that next read attempt does a
reconfiguration and restart of the audio input device.
We've gotten lucky to date: the previous calculation of bitmask array
sizes, (maxval+1)/8 only works properly when 'maxval' is one less than
a multiple of 8. Fortunately, this has either been the case for us,
or there has been sufficient 'unused' space at the end of the defined
max value range that we haven't wound up overreading/overwriting the
allocated buffers.
Change-Id: I563a93a86644ab9f19489565e06c28e06bb53abc
Bug #2376231: Apps lose window focus (and back key causes ANR) if the
lock screen is dismissed while the phone is in landscape mode
This is another case where we weren't recomputing the focused window
after changing the visibility policy.
bug #2479958: Investigate source of "Resources don't contain package
for resource number 0x7f0a0000"
Um, okay, so it turns out there were bugs all over the place where
we would load an XML resource from a another application, but not
use the Resources for that application to retrieve its resources...!
I think the only reason any of this stuff was working at all was
because it typically only cared about retrieving the resource
identifiers of the items (it would look up the values later).
Bug #2401082: Passion ERE26 monkey crash - InputMethodManagerService
Add some null checks.
We now only consider a device to be a default keyboard if its name
has "-keypad". A hack, but whatever.
Also add some debug logging for the input state to help identify such
issues in the future.
And related:
- The aapt tool now sets a resource configurations sdk level to match any configs
that have been set (for example if you specify density your sdk level will be
at least 4).
- New option to modify the targetPackage attribute of instrumentation.
- Clean up of aapt options help.
- Fix of UI type values to leave 0 for "unspecified".
- Make the UI mode config APIs public.
It is spamming the log bigtime and can be promoted back to LOGW
or worse by whoever decides to actually investigate the bug.
Change-Id: I72d950155378f641ebdfbacabae774f5736a52bc
This is not a real fix for the issue but a change to make sure that the behavior is consistent regardless of
external condidions (WIFI ON or OFF, music started before call or not, A2DP device same as SCO device...).
As there is now way to guaranty good quality audio over both SCO and A2DP simultaneously, especially when WIFI is on, We will stick to this behavior:
When music is playing and we are docked to the desk dock and a call is answered with a BT SCO headset, A2DP output will be suspended.
If music is restarted during the call, it will appear muted to the user until the call is terminated.
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.
Merge commit '083a557c25e0032bc4900f335b6643d0badd09ce' into eclair-mr2
* commit '083a557c25e0032bc4900f335b6643d0badd09ce':
fix [2319255] crash in openGL : from the media recorder stress test.
Merge commit '76169da0e84b0fcf621aeac6141af3ee85bc7c1e' into eclair-mr2
* commit '76169da0e84b0fcf621aeac6141af3ee85bc7c1e':
fix [2315900] Monochrome camera preview screen after launching camera
Merge commit 'd8c752ef74bc6d8b412defe35caf1a19be15eb8b' into eclair-mr2
* commit 'd8c752ef74bc6d8b412defe35caf1a19be15eb8b':
improve video performance to minimize the tearing effect seen in 720p movies
Allows "aapt dump --values resource" to print out whether a string in a
ResStringPool is in UTF-8 or UTF-16 encoding.
Change-Id: I6478884a70a3b46fee862dece6cb33454fc34843
this was introduced by a recent change. when we try to figure out the size of
the yuv->rgb temporary buffer, the output resolution has not been computed yet
and an invalid buffer size is used. most of the time the allocation fails
and the system reverts to "standard" GL will uses onle the Y plane.
the allocation of the temporary buffer is moved to onDraw(), the first
time it is called, by that time, the window is positioned properly.
always rescale videos to their target size using copybit during yuv->rgb
conversion. this improves performance of the GPU pass and doesn't require
linear filtering to be enabled. Also always use 16-bits buffers.
the average processing time for 720p dropped from ~50ms to ~30ms
This is a very simply implementation: upon receiving an IPC, if the handling
thread is at a background priority (the driver will have taken care of
propagating this from the calling thread), then stick it in to the background
scheduling group. Plus an API to turn this off for the process, which is
used by the system process.
This also pulls some of the code for managing scheduling classes out of
the Process JNI wrappers and in to some convenience methods in thread.h.
Allows the use of UTF-8 for packing resources instead of the
default of UTF-16 for Java. When strings are extracted from the
ResStringPool, they are converted to UTF-16 and the result is
cached for subsequent calls.
When using aapt to package, add in the "-8" switch to pack the
resources using UTF-8. This will result in the value, key, and
type strings as well as the compiled XML string values taking
significantly less space in the final application package in
most scenarios.
Change-Id: I129483f8b3d3b1c5869dced05cb525e494a6c83a
The ToneGenerator failed to initialize because no more tracks were available in AudioFlinger mixer.
All tracks were used because the duplicating output was failing to free the tracks on audio hardware output mixer when exiting due to a misplaced test on output activity: output tracks where only freed if the duplicating output was active when exiting.
The fix consists in freeing the output tracks when the duplicating thread is destroyed without condition.
Merge commit '6d42d80653f2c41f3e72a878a1d9a6f9693b89f7' into eclair-mr2
* commit '6d42d80653f2c41f3e72a878a1d9a6f9693b89f7':
Fix issue 2304669: VoiceIME: starting and canceling voice IME yields persistent "error 8" state on future attempts and breaks voice search.
Fixed AudioFlinger::openInput() broken in change ddb78e7753be03937ad57ce7c3c842c52bdad65e
so that an invalid IO handle (0) is returned in case of failure.
Applied the same correction to openOutput().
Modified RecordThread start procedure so that a failure occuring during the first read from audio input stream is detected and causes
the record start to fail.
Modified RecordThread stop procedure to make sure that audio input stream fd is closed before we exit the stop function.
Fixed AudioRecord JAVA and JNI implementation to take status of native AudioRecord::start() into account
and not change mRecordingState to RECORDSTATE_RECORDING if start fails.
Merge commit '0019215fc395ef12c191049b1903eeabf70859cf' into eclair-mr2
* commit '0019215fc395ef12c191049b1903eeabf70859cf':
Revert "When using MDP, we needed to use a texture for diming."
Merge commit '121a31ac3901fcb81c808da2b4a9a7cf66c12b7c' into eclair-mr2
* commit '121a31ac3901fcb81c808da2b4a9a7cf66c12b7c':
fix [2291418] Camera preview cannot work in Emulator
The image buffer used by glTexImage2d() would be uninitialized when no copybit engine
can be found.
We now always initialize images, since the abscence of copybit is not necessarily fatal.
Merge commit '1ac56b602aa6a1ac54c608e5a8b76f44638db23b' into eclair-mr2
* commit '1ac56b602aa6a1ac54c608e5a8b76f44638db23b':
Fix issue 2292062: Audio freezes for three seconds when choosing ringtones with a headset connected and music playing.
There was bug in the logic that calculated the relative timeout, the start time was
reset each time an event was received, which caused the timeout to never occur if
an application was constantly redrawing.
Now we always check for a timeout when we come back from the waitEvent() and
process the "anti-freeze" if needed, regardless of whether an event was received.
The problem comes from a deadlock with AudioPolicyService mutex: When the second ringtone starts,
this mutex is locked by AudioPolicyService::startOutput() which in turn calls setParameters() to change the output device.
Audioflinger::ThreadBase::setParameters() signals the parameter change to the AudioFlinger mixer thread and waits for a condition
indicating that the parameter change has been processed.
At the same time, the mixer thread detects that the audio track corresponding to the first ring tone has been killed and calls its destructor.
This calls AudioPolicyService::releaseOutput() which tries to lock the AudioPolicyService mutex.
If this happens before the mixer thread can process the setParameters() command we are deadlocked.
The deadlock ends because setParameters() uses a timeout when waiting for the condition.
This regression was introduced by change 33736 fixing issue 2265163.
The fix consists in calling AudioPolicyService::releaseOutput() from Track::destroy() instead of from Track destructor: as detroy() is never called from the mixer thread loop (as opposed to the destructor) the deadlock described above cannot occur.
