When attached to an HDMI touch screen, the input system needs
to know the size and rotation of the external display independent
of the internal display. The size was already being reported
separately but not the rotation. The inconsistency can cause problems
if the internal display's natural rotation is portrait but
the external display's natural rotation is landscape.
Change-Id: Id344f04c1ba032625f6265766be66f9ddaa2cc0b
This reverts commit 8a36e05443 which was causing
keyguard_screen_tab_unlock.xml to have a bad layout.
Change-Id: I50bdc6dbdf8d7b98ef77eae532860d375574213e
1. Virtual nodes should be made important since the implementer of
the tree represented by the nodes decides which node to report.
In the case with native widgets we decide in the framework but
in the case of the node provider, the implementer of the latter
makes the call. Hence, if a node in not important the provider
should not report it in the first place. The issue this patch
solves is to allow events from virtual nodes to be propagated
to the accessibility services.
bug:6432588
Change-Id: Ie01f84e9e0ef2280da934b98283962a5db38abc2
quick switch feature introduced in ICS does not work very well. Reported
logs indicate the Bluez stack cannot sustain the long time ON/hotoff state.
This change will always move the adapter to code but move it to hotoff
to be able to turn on quickly.
bug 5792792
Change-Id: I41c39d4bf11bb5eb3cd83279e8ec81e01774e008
Otherwise File.createTempFile() uses /sdcard which most apps don't
have write access to.
Bug: 6347289
Change-Id: Ibde191a63e4dbb9b03437406f8c999f192bcfa21
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
