Bug #7275145
This change fixes ViewRoot and adds extra debug information. It does
not solve the problem entirely. Another CL will.
Change-Id: I7e604ba38aad7f421769783dcbd998d6905ab2d9
On some devices the information coming from the touchscreen is very
noisy or otherwise unreliable. Perform some processing on the data
we have to try to provide a smoother experience.
Bug 7267507
Change-Id: I863125f58577f522de05a1361b81c2e42975fd89
Added a new API to determine whether the display supports
protected buffers so that an application can choose a different
content stream or change how it decodes the content so
that it will be viewable on the display.
At present, wifi display does not fully support protected
buffers although this may be enhanced in the future.
Bug: 6986623
Change-Id: If53a53d72b0ec92753cc4b29f99fcb131e00449b
- do not ask for requestLayout() nor invalidate() in View.onMeasure() when
resolving RTL properties
Change-Id: I7961fcb4c046d96391a4e748350573534481ae2b
1. We use auto scroll when a view gets accessibility focus.
Pros: Having magnification and TalkBack enabled together (not a common use case)
will have the accessibility focused view on the screen (it is auto panned).
Cons: A blind user can get stuck in a very lock scroll view - not good.
2. We do not auto scroll when a view gets accessibility focus.
Pros: A blind user cannot get stuck in a long scroll view as he has to explicitly
scroll.
Cons: The magnified area will not pan to ensure the accessibility focused view
is visible.
Option one is the better trade off and this change removes the auto scrolling.
bug:7265773
Change-Id: I209b54ed18acad36c1f35b4c09b980e45ec9bbff
(padding is still hard)
- fix Toasts: basically the background drawable padding was not
taken into account
Change-Id: Iefd29782f50b6f6a56578cfeb2af119d381207f0
MeasureSpec.makeMeasureSpec has a bug where a negative or very large
size parameter will cause the resulting MeasureSpec value to
overflow. RelativeLayout partially relies on this when measuring
children with mode UNSPECIFIED; a default value of -1 in a local
variable ends up being passed to makeMeasureSpec, overflowing a mode
value to create a measurespec that is very large in size, with AT_MOST
as the mode. The correct behavior is for RelativeLayout to propagate
the UNSPECIFIED mode.
Unfortunately a number of custom view implementations in apps rely on
the buggy behavior as they do not implement their own onMeasure
method. This makes them fall back to View's default onMeasure
implementation, which accepts the spec's size unconditionally for
AT_MOST or EXACTLY modes, but falls back on
getSuggestedMinimum[Width|Height] for UNSPECIFIED. If the view had no
background drawable with dimensions and no minWidth field set, this
fix for RelativeLayout causes some views to measure with a size of 0
rather than a size of the 30-bit version of 0xFF...
Revert these fixes in the interests of compatibility. The next version
will conditionally use the new behavior if targetSdk > JB-MR1.
This also required reverting a fix for ImageView's adjustViewBounds
functionality, as it cannot be implemented reliably if this
RelativeLayout fix is not also in place.
Revert "Fix UNSPECIFIED measurement in RelativeLayout"
This reverts commit 132a742b94.
Revert "Fix adjustViewBounds handling for ImageView"
This reverts commit d5edc77217.
Added a new WindowManager.LayoutParams inputFeatures flag
to disable automatic user activity behavior when an input
event is sent to a window.
Added a new WindowManager.LayoutParams field userActivityTimeout.
Bug: 7165399
Change-Id: I204eafa37ef26aacc2c52a1ba1ecce1eebb0e0d9
(padding is hard)
- set correct values to mUserPaddingLeftInitial / mUserPaddingRightInitial
- reset padding to initial values depending on layout direction
Change-Id: I5cfb941b4874eafbfcfb5e2926f5a3c80b4931d3
When memory gets low on a device, activities flush everything they can.
Hardware-accelerated activites, such as Launcher, flush GL resources and destroy
the GL context. However, some resources were still hanging around, due to deferred
destruction policies (we don't delete layers until the DisplayLists they are in
are finalized, to ensure we don't deref deleted objects). This meant that we were
referring to obsolete GL data in these objects. in particular, it meant that we might
come around later, after a new GL context was created, and delete a texture object
that was incorrect. We use the layer's "texture id" to refer to the texture underlying the
layer. But if there's a new GL context, then this texture ID is no longer valid, and
we may be deleting the texture that a different object (layer, icon, whatever) is referring
to, because the driver may return that same ID under the new GL context.
The fix is to more aggressively delete things that we know will not be used again
when the GL context is destroyed. In particular, we delete all resources being used
by all DisplayLists at GL context destruction time.
Issue #7195815 Textures corruption on all devices, in many apps
Change-Id: I52d2d208173690dbb794a83402d38f14ea4c6c22
- do not need those variables. Use what we already have in View.
- reset padding to initial values before changing it.
Change-Id: Ib396b3dca6e98a94d83a538a9b594b5eb426c453
When computing the adjusted view bounds, don't constrain the
dimensions by the original estimate if the opposite dimension has a
fixed size. This can result in the view never getting properly
enlarged.
Also fix a long-standing bug in MeasureSpec.makeMeasureSpec where
oversized or negative values could result in broken packed values.
Bug 7240251
Change-Id: I359d108ff52b6f3b5c4bf393d2271d28999c0127
