A bug in the invalidation logic meant that changes to a view
would not cause parents in the view hiearchy that were set to have
a layer (e.g., View.LAYER_TYPE_HARDWARE) to get invalidated properly.
So even though the child view was all set to recreate its display list
according to the property change, the layer in the tree above it would stay
as-is, meaning that the change would not show up on the screen.
Issue #5887530 DropTarget text does not change color with the icon
Change-Id: Ie6eac4f406d172cb437822d9fe76340ab2afaf1c
Bug 6378843
Corrects CL 183460, which would clip text with a width greater than
twice the TextView's width.
Internal horizontal translation is now handled in a similar way to
vertical scrolling.
Internal scrolling is indeed handled by the TextView, which translates
the canvas and sets the clipping bounds accordingly.
When drawing the internal DL, we tighten the horizontal bounds like we
did for the vertical bounds using top and bottom. As in Touch.java, we
use the getHorizontallyScrolling() method to know if we indeed have to
measure the actual text width. If there is no horizontal scrolling we
use the TextView's width as a safe upper estimate in order to avoid an
actual computation. Note that horizontal scrolling is typically only
used for long single-lined text, so that the measurement loop is quick.
As a result, the internal DLs represent the entire text, and there is no
need to invalidate them when an internal scrolling takes place. This
behavior replaces the draw-only-what-is-needed we had before, but is
more consistent with what we do for long texts inside of a ScrollView
with no noticeable performance change, even on very long text.
Change-Id: I47c24c0ae988547d4f1e9f87d136225c93a3056d
address can be null that returned from getAddressFromObjectPath.
If it is null case, donot continue call getRemoteDeviceProperties.
Otherwise it causes null pointer exception and crash the system.
Bug 6338780
Change-Id: Ib190342032ab2ad11c49f44fa6d4b2509a861514
The window manager policy made some incorrect assumptions about the
meaning of the Configuration.keyboard field. We need to be more
careful about distinguishing between built-in and external keyboards.
Most of this change is to move the determination of the parts of
the Configuration related to input devices into the WindowManagerService
leveraging new features of the InputManagerService to good effect.
Then we plumb through the flag that indicates whether a device
is internal or external so that we can be more particular about
how the lid switch effects changes to the Configuration.
Bug: 6424373
Change-Id: I36a1c22ade35e578955465a25940a33f227b9763
Bug 6404882.
When a cell has an unspecified row and a column that is specified as greater
than the specified number of columns, GridLayout fails to report or correct
the error and loops indefinitely searching for a valid row to place the cell.
There is a cyclic dependency between the validation of layout parameters
(and allocation of undefined cell indexes) and the maximum column/row counts.
A performance optimization in layout paramter allocation caused this dependency
to be handled in correctly. The problem is fixed in this CL for this bug and
the symmetric problem for rows.
Change-Id: I0392343bc8a721a0ca7163f58f233ba8046c22e2
