Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
Some supurious calls to these functions when tests are still
running are observed. Add more logging to see what's the
caller.
Change-Id: I9254c3639bcb8619be39bfbc6981fae5bf5e7efa
Back is hidden by DISABLE_BACK; Home, Recents, and Menu are
hidden by DISABLE_NAVIGATION.
Bug: 5261576
Bug: 5284740 (confusion about visible inactive icons)
Change-Id: I410c133b737cc11d61bac0318dc24458353ee7b3
* commit 'ab90899264407669725a24eb941de9278e82c70f':
Integrate ImageProcessing test into test framework http://b/issue?id=5274365 Change-Id: I7949b4114dcab17d895d04755df5df2bd5a576a3
- force TextView to LOCALE text heuristic when in "password" mode
- remove TEXT_LAYOUT_DIRECTION_UNKNOWN_DO_NOT_USE
- LocaleUtils.getLayoutDirectionFromLocale() returns "LTR" is locale is NULL or ROOT
Change-Id: I182c46aaf2d73c8b18967fffa230bfabec91ed06
If returns true, the SurfaceTexture will be released by TextureView.
If returns false, the client needs to release the SurfaceTexture.
Change-Id: I946f71e337ad4170c168854ac27e028b82489c8c
