summaryrefslogtreecommitdiffstats
path: root/tests/permission
diff options
context:
space:
mode:
authorJeff Brown <jeffbrown@google.com>2011-09-20 15:08:29 -0700
committerJeff Brown <jeffbrown@google.com>2011-09-21 19:26:15 -0700
commit01a98ddbdfbaf1f0d2bc602537e6e314364902a3 (patch)
treece904db3ee0772e0e2a35882a6cf86c7b9fcd84e /tests/permission
parent04ef5b8dd7262ee90b56df9c992f103695d0a21c (diff)
downloadframeworks_base-01a98ddbdfbaf1f0d2bc602537e6e314364902a3.zip
frameworks_base-01a98ddbdfbaf1f0d2bc602537e6e314364902a3.tar.gz
frameworks_base-01a98ddbdfbaf1f0d2bc602537e6e314364902a3.tar.bz2
Handle orientation changes more systematically.
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
Diffstat (limited to 'tests/permission')
-rw-r--r--tests/permission/src/com/android/framework/permission/tests/WindowManagerPermissionTests.java26
1 files changed, 24 insertions, 2 deletions
diff --git a/tests/permission/src/com/android/framework/permission/tests/WindowManagerPermissionTests.java b/tests/permission/src/com/android/framework/permission/tests/WindowManagerPermissionTests.java
index f015378..5df018e 100644
--- a/tests/permission/src/com/android/framework/permission/tests/WindowManagerPermissionTests.java
+++ b/tests/permission/src/com/android/framework/permission/tests/WindowManagerPermissionTests.java
@@ -412,9 +412,31 @@ public class WindowManagerPermissionTests extends TestCase {
@SmallTest
public void testSET_ORIENTATION() {
try {
- mWm.setRotation(0, true, 0);
+ mWm.updateRotation(true);
mWm.getSwitchState(0);
- fail("IWindowManager.setRotation did not throw SecurityException as"
+ fail("IWindowManager.updateRotation did not throw SecurityException as"
+ + " expected");
+ } catch (SecurityException e) {
+ // expected
+ } catch (RemoteException e) {
+ fail("Unexpected remote exception");
+ }
+
+ try {
+ mWm.freezeRotation();
+ mWm.getSwitchState(0);
+ fail("IWindowManager.freezeRotation did not throw SecurityException as"
+ + " expected");
+ } catch (SecurityException e) {
+ // expected
+ } catch (RemoteException e) {
+ fail("Unexpected remote exception");
+ }
+
+ try {
+ mWm.thawRotation();
+ mWm.getSwitchState(0);
+ fail("IWindowManager.thawRotation did not throw SecurityException as"
+ " expected");
} catch (SecurityException e) {
// expected