Make the rotation-lock QS tile available for display on phones.
Devices < sw600dp are only allowed to lock rotation to their
natural orientation (i.e. portrait on most phones), so tweak
the QS tile label to make this clear. e.g. "Locked to Portrait"
instead of "Rotation Locked" on portrait phones.
Simplify RotationLockController now that the sw600 check is no
longer hardcoded in RotationPolicy.
Remove redundant sw600dp check in SystemUI, everything driven
from the RotationPolicy helper, though SystemUI can still
choose not to display the tile at all with a resource config.
Clean up some of the docs in RotationPolicy to make clear the
subtle distinction between the two ways of locking rotation:
- From Accessibility (locks to natural orientation on all devices)
- From System UI (locks to natural < sw600dp, else current rotation)
Bug:11062710
Change-Id: I5caa4485c9501315da9fed964d6667d3012b43cb
Add gl functor to the prototype support to allow
webview team to begin playing with RT
Also create RemoteGLRenderer to avoid needing to make
breaking changes to GLRenderer. Currently the differences
are mainly around mFunctorsRunnable and how it queues itself up
Change-Id: I1ca39056189b68cd7b8dded4dd5889d331f6660a
1. Views not important for accessibility should not send events.
2. The base View implementation should not add it self to the
list of children for accessibility.
3. Null pointer exception in AccessibilityNodeInfoCache.
Change-Id: Ie5b373362269200ead13ffe632679bd42ee40309
This ensures that we use the same underlying zip
processing code as the runtimes.
bug: 10193060
(cherry picked from commit eb565dc527)
Change-Id: Iaaa26b02678278394619d0a41613d9ceeae3203c
Includes special handling for attributes that can affect the image's
drawing opacity and bounds, e.g. xfermode, alpha, and matrix transform.
BUG: 12120109
Change-Id: Ieeec11ff35af899c4e6fcf6364633c15ec94241e
Due to an API change in LocalSocket, Zygote must now
manually close the FileDescriptor it created when it
registered a LocalServerSocket. The LocalSocket.close()
routine will no longer do so.
Bug: 12114500
Change-Id: I8c9fb073924ac33d594bd3bd0eb11d3d1d402506
True 3d transformations are now supported by DisplayLists and the
renderer, initially with the translationZ property on view.
Renderer operations used directly by DisplayList (formerly,
clip/save/restore/saveLayer) are now more simply managed by allocating
them temporarily on the handler's allocator, which exists for a single
frame. This is much simpler than continuing to expand the pool of
pre-allocated DisplayListOps now that more operations are called
directly by DisplayList, especially with z ordered drawing.
Still TODO:
-APIs for camera positioning, shadows
-Make Z apis public, and expose through XML
-Make invalidation / input 3d aware
Change-Id: I95fe6fa03f9b6ddd34a7e0c6ec8dd9fe47c6c6eb
