Nice to not load 4MB bitmaps in the system process.
Also, hey, with how we are now scrolling the surface instead of
the bitmap, there is no reason to keep that 4MB bitmap loaded in
to memory. So don't.
Unfortunately it looks like for some reason the VM is still
holding on to the bitmap. I'll need to figure out why. Later.
Change-Id: Ib3503756144502fc5c8d5e294248c2417c4fe8c8
the original connect/disconnect hooks are deprecated
and replace by api_connect/api_disconnect. the original
hooks are no no-ops.
api_connect/api_disconnect is now only called from the
android framework.
Bug: 5057915
Change-Id: I8ca64cd1acd6cabf915bf54689ec2e5f6dfa495a
Also properly signal a "hard" discontinuity, i.e. a possible format change
when a discontinuity is signalled explicitly as part of the playlist.
Change-Id: Ic347d3d11d39b0411c3726a7c723bcf13092b8bc
related-to-bug: 5103155, 5103013
When a ListView has itemsCanFocus set, and scrolling moves the currently
focused item off the display, its focus is cleared. This is checked by
calling getDistanceToView().
However, it's possible that the view will have been recycled. If so, it
will have been detached from the parent by calling
ViewGroup.detachViewFromParent. Since this doesn't clear the view's
focus, we'll still try to call getDistanceFromView(), causing an
IllegalArgumentException since the view is not a descendant of the
ListView anymore.
Check whether the view is still a descendant before calling
getDistanceToView(). If it's not, we also need to clear the focus.
Bug: 4556022
Change-Id: Iebee56032223b70d714e2ec3bb7a19093ab5f81c
When the suggestions are displayed, the shortest one will be at the top of the list, as they are the most relevant one.
Bug: 5006130
Change-Id: Id3ac3accce5198a6a58a0c3028ee5f77957ceac6
Bug: 5064702
Introduced the concept of an InputListener to further decouple
the InputReader from the InputDispatcher. The InputListener
exposes just the minimum interface that the InputReader needs
to communicate with the outside world. The InputReader
passes arguments to the InputListener by reference, which makes
it easy to queue them up.
Consolidated all of the InputReader locks into one simple global
Mutex. The reason this wasn't done before was due to potential
re-entrance in outbound calls to the InputDispatcher. To fix this,
the InputReader now queues up all of the events it wants to send
using a QueuedInputListener, then flushes them outside of the
critical section after all of the event processing is finished.
Removing all of the InputMapper locks greatly simplifies the
implementation.
Added tests for new stylus features such as buttons, tool types,
and hovering.
Added some helpers to BitSet32 to handle common code patterns
like finding the first marked bit and clearing it.
Fixed a bug in VelocityTracker where the wrong pointer trace
could get cleared when handling ACTION_POINTER_DOWN. Oops.
Changed PointerCoords so it no longer stores useless zero
axis values. Removed editAxisValue because it is not very
useful when all zero value axes are absent and therefore
cannot be edited in place.
Added dispatch of stylus hover events.
Added support for distance and tool types.
Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
Fixes problems introduced with bulk insert support
Bug: 5092877
Change-Id: If3c0c9054d5effe0a1d7a75e85635b41ba1591f5
Signed-off-by: Mike Lockwood <lockwood@android.com>
This change makes SurfaceFlinger's SurfaceTexture objects default to
async mode whenever a camera or video decoder connects. This behavior
can be disabled by #defining NEVER_DEFAULT_TO_ASYNC_MODE.
Change-Id: I8965951d1775915da180e4af298dd7af3afafecc
This change relaxes an error check in SurfaceTexture::setBufferCount to
allow clients to explicitly set a buffer count of 2. The clients that
will do this are camera and video decode. Previously it was thought
that for those clients we would always use async mode, which requires a
minimum of 3 buffers. However, we now believe that for some devices it
may make sense to use synchronous mode (with 2 buffers) to reduce memory
usage.
Bug: 5088418
Change-Id: I620a0ef75075745be9d6c8219e0246aaf33ba950
This change makes the Layer::onRemoved method call
SurfaceTextures::abandon on the layer's SurfaceTexture. This will cause
all client-initiated operations on the SurfaceTexture to fail. In
particular, this will result in an error on the client side, rather than
a deadlock when removing a layer that used a SurfaceTexture in
synchronous mode.
Change-Id: I14014d00369f29560a21b606831edee432bb8867
Bug: 5020874
