History log of /frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
4ec6cc51087f310acf6f933ae2b69f1520b78453 05-Mar-2013 Dianne Hackborn <hackbod@google.com> Fix build.

Change-Id: Iaa70b05a3cfd372518ec35aa8bcea2f9d78b8292
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
c4aad01cbbb69c916ef323693e1fd0560b0eccba 23-Feb-2013 Dianne Hackborn <hackbod@google.com> Formalize overscan metrics.

The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).

Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!

The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.

Also did some improvements to debug dumping in the window
manager.

Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
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.

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
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
39df578acddb739d7608e458533904bf5814c0da 27-Jul-2012 Craig Mautner <cmautner@google.com> Fix build.

Change-Id: I52bbebae38912a4fb71c96174b3d4d8eb6be10c1
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
a4b7f2f75e7803193429ec1179fb5e2eb1c6fbda 21-May-2012 Dianne Hackborn <hackbod@google.com> Use two fingers to work some magic...

Change-Id: Ibcb3dbd3d158c22da8277e544d81fb47eadccd49
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
4286d6d115385391b75db8e6c4e397008ef9b3db 14-May-2012 Dianne Hackborn <hackbod@google.com> Fix build.

Change-Id: I53263d509559c70100cd78ad49f225f0dafd8891
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
5c58de3a523a384c47b0b1e0f5dd9728a74cd9f7 29-Apr-2012 Dianne Hackborn <hackbod@google.com> Add system insets to windows.

This will be used to determine which parts of a window a completely
hidden by system UI elements (status bar, nav bar, system bar) so
that they can be clipped out from rendering.

Change-Id: I2c6c6ac67dbdfeed82d2c089ef806fb483165bd9
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
46d43ccfd8cef75b4315828073c094cf1efb05ff 03-Feb-2012 Xavier Ducrohet <xav@android.com> Make Layoutlib compile on Java 6.

Change-Id: Ic8f0e321c6c218de83664fc01f253a07fa80852c
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
6d05fd3c795088ac60f86382df5a66d631e8a0cb 19-Nov-2011 Dianne Hackborn <hackbod@google.com> Fix issue #5588689: Black camera preview after coming back from gmail

Make surface management between SurfaceView and the window manager
much more controlled, to ensure that SurfaceView always gets to report
the current surface is destroyed before the window manager actually
destroys it.

Also a small tweak to allow windows that have a wallpaper background
to still have a preview window. This makes launching home after it
has been killed feel much more responsive.

Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
9a230e01a1237749a8a19a5de8d46531b0c8ca6a 06-Oct-2011 Dianne Hackborn <hackbod@google.com> Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately

This cleans up how ui flags are managed between the client and window manager.
It still reports the global UI mode state to the callback, but we now only clear
certain flags when the system goes out of a state (currently this just means the
hide nav bar mode), and don't corrupt other flags in the application when the
global state changes.

Also introduces a sequence number between the app and window manager, to avoid
using bad old data coming from the app during these transitions.

Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
648251710162cdaf7371012a1cbb79b9bc5bc0e4 03-Mar-2011 Dianne Hackborn <hackbod@google.com> Fix issue #3485923: Gmail crash

Allow application to try to recover if a surface OOM error
happens on the client side.

Change-Id: I0308bd99647a35e4bcac448340b7fc6330a828f6
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
fbf097732137a32930d151f7ba6816a5b870c32a 16-Jan-2011 Jeff Brown <jeffbrown@google.com> Support non-rectangular input regions.

This enables the system bar to carve out a region through which
events will be sent to the IME behind it.

Bug: 3238092
Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
310a4d815b693e358d151b9aa2823c5022993f9b 13-Jan-2011 Xavier Ducrohet <xav@android.com> LAyoutLib: Fix build by adding missing IWindowSession implementation.

Change-Id: I0af178d149b782cac3ae0c36fa5fc03f4dc6118b
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
02d2b3ba9ba830a8147db2739613f7bbb2d0fcbf 11-Jan-2011 Christopher Tate <ctate@google.com> API CHANGE: startDrag() now takes "int flags" instead of "boolean localOnly"

There will be, in the future, a flag (View.DRAG_FLAG_GLOBAL) that means
for the drag to be cross-application. For now that flag constant is @hide
and furthermore the server-side implementation strips it, enforcing
local-only drags.

Change-Id: I8db840480ab90e18a5b8ecf29d62b4e6eafd405e
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
c2e9651bf386a1f7bf7fc706cf5424950570470c 10-Nov-2010 Xavier Ducrohet <xav@android.com> Layoutlib: New bridge implementation using the new API 5.

Since the new API prepare for stateful layoutlib, major
reorganization of the code.

New "android" sub-package for all extended android classes.
Also moved BridgeInflater in here so that all extended classes
are in this package. Only delegates and classes replacing
renamed classes are in their original android.* packages.
Also created full file for the empty implementations of
IWindow and IWindowSession.
New "impl" for the dirty work implementation.
Main package contains the basic implementation of the API.

Most of the code that was in Bridge is now in .impl.LayoutSceneImpl,
with the main init/inflate/render code split into the contrustrutor,
inflate() and render().

Change-Id: Ie15b15e5a1b2388cd6ef82e518345b1fc02ec981
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java