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
* commit '3c45765a2a15c685aa28b74f626c6c10c909c133': (21 commits)
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Send Trackball clicks instead of Enter Key for taps
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Fix auto-merger error in I74c0644c6938d28c20c42d88d995ffb56a71d703
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Converts hover touch events to trackball events
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
...
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
Warn in the event of possibly bogus event streams and don't try to
clear empty history.
Bug 7241640
Bug 7243006
Change-Id: I037cf1334cab790ef5998ca5f8f6b323ed5f4459
* commit 'ac7348a3228177a0e08b8be2fec88e23b82c6043':
Fix bug #7249363 Icons in the Camera UI (to switch camera types and on the focus ring) are missing
