History log of /frameworks/base/core/java/android/os/RemoteCallbackList.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
1cf70bbf96930662cab0e699d70b62865766ff52 06-Aug-2012 Svetoslav Ganov <svetoslavganov@google.com> 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.


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

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.


Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
dace230043314d6fab1c5ced4b031eaccd814c25 14-Jul-2009 Dianne Hackborn <hackbod@google.com> resolved conflicts for merge of b06ea706 to master
b06ea706530e6d19eb2a1a9a7ae6c5dd77d80af0 13-Jul-2009 Dianne Hackborn <hackbod@google.com> Add reporting of activity movement for search manager.

This adds a new API with the activity manager to find out about movement between
activities. For my sanity, the old IActivityWatcher is now renamed to
IActivityController, and the new activity movement interface is named

This changes the search manager itself to use the new API to manage its state.
Note that there are still problems when going back to the search dialog after
it was hidden -- the suggestions window no longer appears until you explicitly
dismiss and re-show it.
7a1355950172b7a549820e9a2cd4a9b2099ec32f 06-May-2009 Dianne Hackborn <hackbod@google.com> merged 231cc608d06ffc31c24bf8aa8c8275bdd2636581
231cc608d06ffc31c24bf8aa8c8275bdd2636581 28-Apr-2009 Dianne Hackborn <hackbod@google.com> Rewrite SyncStorageEngine to use flat files and in-memory data structures.

The previous implementation used a database for storing all of its state, which could cause
a significant amount of IO activity as its tables were updated through the stages of a sync.
This new implementation replaces that in-memory data structures, with hand-written code
for writing them to persistent storage.

There are now 4 files associated with this class, holding various pieces of its state that
should be consistent. These are everything from a main XML file of account information that
must always be retained, to a binary file of per-day statistics that can be thrown away at
any time. Writes of these files as scheduled at various times based on their importance of
the frequency at which they change.

Because the database no longer exists, there needs to be a new explicit interface for
interacting with the sync manager database. This is provided by new APIs on IContentService,
with a hidden method on ContentResolver to retrieve the IContentService so that various
system entities can use it. Other changes in other projects are required to update to the
new API.

The goal here is to have as little an impact on the code and functionality outside of
SyncStorageEngine, though due to the necessary change in API it is still somewhat extensive.
7b0b1ed979aa665175bf3952c8902ce13c763ab8 19-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import //branches/master/...@140412
105925376f8d0f6b318c9938c7b83ef7fef094da 19-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake_rel/...@140373
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
54b6cfa9a9e5b861a9930af873580d6dc20f773c 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution