Screen magnification - feature - framework.

This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.

Interaction model:

1. Triple tap toggles permanent screen magnification which is magnifying
   the area around the location of the triple tap. One can think of the
   location of the triple tap as the center of the magnified viewport.
   For example, a triple tap when not magnified would magnify the screen
   and leave it in a magnified state. A triple tapping when magnified would
   clear magnification and leave the screen in a not magnified state.

2. Triple tap and hold would magnify the screen if not magnified and enable
   viewport dragging mode until the finger goes up. One can think of this
   mode as a way to move the magnified viewport since the area around the
   moving finger will be magnified to fit the screen. For example, if the
   screen was not magnified and the user triple taps and holds the screen
   would magnify and the viewport will follow the user's finger. When the
   finger goes up the screen will clear zoom out. If the same user interaction
   is performed when the screen is magnified, the viewport movement will
   be the same but when the finger goes up the screen will stay magnified.
   In other words, the initial magnified state is sticky.

3. Pinching with any number of additional fingers when viewport dragging
   is enabled, i.e. the user triple tapped and holds, would adjust the
   magnification scale which will become the current default magnification
   scale. The next time the user magnifies the same magnification scale
   would be used.

4. When in a permanent magnified state the user can use two or more fingers
   to pan the viewport. Note that in this mode the content is panned as
   opposed to the viewport dragging mode in which the viewport is moved.

5. When in a permanent magnified state the user can use three or more
   fingers to change the magnification scale which will become the current
   default magnification scale. The next time the user magnifies the same
   magnification scale would be used.

6. The magnification scale will be persisted in settings and in the cloud.

Note: Since two fingers are used to pan the content in a permanently magnified
   state no other two finger gestures in touch exploration or applications
   will work unless the uses zooms out to normal state where all gestures
   works as expected. This is an intentional tradeoff to allow efficient
   panning since in a permanently magnified state this would be the dominant
   action to be performed.

Design:

1. The window manager exposes APIs for setting accessibility transformation
   which is a scale and offsets for X and Y axis. The window manager queries
   the window policy for which windows will not be magnified. For example,
   the IME windows and the navigation bar are not magnified including windows
   that are attached to them.

2. The accessibility features such a screen magnification and touch
   exploration are now impemented as a sequence of transformations on the
   event stream. The accessibility manager service may request each
   of these features or both. The behavior of the features is not changed
   based on the fact that another one is enabled.

3. The screen magnifier keeps a viewport of the content that is magnified
   which is surrounded by a glow in a magnified state. Interactions outside
   of the viewport are delegated directly to the application without
   interpretation. For example, a triple tap on the letter 'a' of the IME
   would type three letters instead of toggling magnified state. The viewport
   is updated on screen rotation and on window transitions. For example,
   when the IME pops up the viewport shrinks.

4. The glow around the viewport is implemented as a special type of window
   that does not take input focus, cannot be touched, is laid out in the
   screen coordiates with width and height matching these of the screen.
   When the magnified region changes the root view of the window draws the
   hightlight but the size of the window does not change - unless a rotation
   happens. All changes in the viewport size or showing or hiding it are
   animated.

5. The viewport is encapsulated in a class that knows how to show,
   hide, and resize the viewport - potentially animating that.
   This class uses the new animation framework for animations.

6. The magnification is handled by a magnification controller that
   keeps track of the current trnasformation to be applied to the screen
   content and the desired such. If these two are not the same it is
   responsibility of the magnification controller to reconcile them by
   potentially animating the transition from one to the other.

7. A dipslay content observer wathces for winodw transitions, screen
   rotations, and when a rectange on the screen has been reqeusted. This
   class is responsible for handling interesting state changes such
   as changing the viewport bounds on IME pop up or screen rotation,
   panning the content to make a requested rectangle visible on the
   screen, etc.

8. To implement viewport updates the window manger was updated with APIs
   to watch for window transitions and when a rectangle has been requested
   on the screen. These APIs are protected by a signature level permission.
   Also a parcelable and poolable window info class has been added with
   APIs for getting the window info given the window token. This enables
   getting some useful information about a window. There APIs are also
   signature protected.

bug:6795382

Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00

1 files changed, 90 insertions, 0 deletions

diff --git a/services/java/com/android/server/accessibility/EventStreamTransformation.java b/services/java/com/android/server/accessibility/EventStreamTransformation.java
new file mode 100644
index 0000000..b715570
--- /dev/null
+++ b/services/java/com/android/server/accessibility/EventStreamTransformation.java
@@ -0,0 +1,90 @@
+/*
+ ** Copyright 2012, The Android Open Source Project
+ **
+ ** Licensed under the Apache License, Version 2.0 (the "License");
+ ** you may not use this file except in compliance with the License.
+ ** You may obtain a copy of the License at
+ **
+ **     http://www.apache.org/licenses/LICENSE-2.0
+ **
+ ** Unless required by applicable law or agreed to in writing, software
+ ** distributed under the License is distributed on an "AS IS" BASIS,
+ ** WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ ** See the License for the specific language governing permissions and
+ ** limitations under the License.
+ */
+
+package com.android.server.accessibility;
+
+import android.view.KeyEvent;
+import android.view.MotionEvent;
+import android.view.accessibility.AccessibilityEvent;
+
+/**
+ * Interface for classes that can handle and potentially transform a stream of
+ * motion and accessibility events. Instances implementing this interface are
+ * ordered in a sequence to implement a transformation chain. An instance may
+ * consume, modify, and generate events. It is responsible to deliver the
+ * output events to the next transformation in the sequence set via
+ * {@link #setNext(EventStreamTransformation)}.
+ *
+ * Note that since instances implementing this interface are transformations
+ * of the event stream, an instance should work against the event stream
+ * potentially modified by previous ones. Hence, the order of transformations
+ * is important.
+ *
+ * It is a responsibility of each handler that decides to react to an event
+ * sequence and prevent any subsequent ones from performing an action to send
+ * the appropriate cancel event given it has delegated a part of the events
+ * that belong to the current gesture. This will ensure that subsequent
+ * transformations will not be left in an inconsistent state and the applications
+ * see a consistent event stream.
+ *
+ * For example, to cancel a {@link KeyEvent} the handler has to emit an event
+ * with action {@link KeyEvent#ACTION_UP} with the additional flag
+ * {@link KeyEvent#FLAG_CANCELED}. To cancel a {@link MotionEvent} the handler
+ * has to send an event with action {@link MotionEvent#ACTION_CANCEL}.
+ *
+ * It is a responsibility of each handler that received a cancel event to clear its
+ * internal state and to propagate the event to the next one to enable subsequent
+ * transformations to clear their internal state.
+ *
+ * It is a responsibility for each transformation to start handling events only
+ * after an event that designates the start of a well-formed event sequence.
+ * For example, if it received a down motion event followed by a cancel motion
+ * event, it should not handle subsequent move and up events until it gets a down.
+ */
+interface EventStreamTransformation {
+
+    /**
+     * Receives a motion event.
+     *
+     * @param event The motion event.
+     * @param policyFlags Policy flags for the event.
+     */
+    public void onMotionEvent(MotionEvent event, int policyFlags);
+
+    /**
+     * Receives an accessibility event.
+     *
+     * @param event The accessibility event.
+     */
+    public void onAccessibilityEvent(AccessibilityEvent event);
+
+    /**
+     * Sets the next transformation.
+     *
+     * @param next The next transformation.
+     */
+    public void setNext(EventStreamTransformation next);
+
+    /**
+     * Clears the internal state of this transformation.
+     */
+    public void clear();
+
+    /**
+     * Destroys this transformation.
+     */
+    public void onDestroy();
+}