This change defines a macro NUM_FRAME_BUFFERS to set
the desired number of framebuffers to be used by the UI,
instead of hard-coding 2 framebuffers.
Aditional logic has been added to handle the initialization
and destruction of NUM_FRAME_BUFFERS buffers.
Change-Id: I3a4bfec3e0f453432f2ffebf084c00f574d3be46
Signed-off-by: Rodrigo Obregon <robregon@ti.com>
system_server can potentially monitor uevent devices that are
of no use to it. For instance, an accelerometer implementation
as uevents. This would cause the process to be busy when
unnecessary. If a device cannot be classified, don't monitor it.
Change-Id: I489cc453bdce7cb376102cba67a9ea470e13292d
moved surfaceflinger, audioflinger, cameraservice
all native services should now reside in this location.
Change-Id: Icd7336f7289db35df9c8c1857a5122bb8a6f1c86
Sometimes the wrong fd was accessed when the device was addressed
by device id.
The earlier implementation assumed that two arrays were in sync
but one of them was compacted when devices were removed. Instead
of that dependency the device now keeps track of it's file descriptor.
Change-Id: I2b8a793d76b89ab464ae830482b309fe86031671
the window manger puts SurfaceViews up before they have been
rendered into, because of that surfaceflinger doesn't have
anything ready to draw for that surface when an udpate occurs
and responds by filling the surface with black.
With this fix, we only fill those areas of the framebuffer
that would otherwise be undefined (no content at all).
in the Flash case, the "flash" window is not drawn at all
until it has some content, instead the underlaying browser
window is shown.
Change-Id: Ifb610f7f8c27b88edf83e09adc4803fc295c15a1
Fix some small static-initialization-order issues (and a static-
initializers-missing issue) that result from doing so. The static
libraries don't actually get used for anything real at the moment --
they're used for perf tests of bug 2660235.
Bug: 2660235
Change-Id: Iee2f38f79cc93b395e8d0a5a144ed92461f5ada0
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
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
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.
