1. The implementation was not taking into account the transformation
matrices if the views.
2. The rectangle that was passed as an argument to
ViewParent.requestChildRectangleOnScreen was modified by
some implementations - now care is taken to prevent it.
3. The scroll of child was used when a rectangle of its coordinate
system was mapped to one in the parent system. However, the
scroll shows how much a parent has scrolled its descendants, so
the scroll of the parent has to be used not the child.
bug:7139556
Change-Id: I5b09eb7f105047e95282f74308968d5465831c84
The window manager now has a facility to provide a full-screen
animation, which the activity manager uses every time a user
switch happens.
The current animation is just a simple dumb slide until we get
a design from UX.
Also some cleanup: moved the portrait task animations to the
default config so we always have an animation for them, and finally
got the java symbol stuff out of public.xml.
Change-Id: I726f77422b2ef5f2d98f961f8da003e045f0ebe8
Trackball and generic motion events now pass through the IME in case
it would like to handle them before passing them on to the view
hierarchy.
While I was at it, I also...
...fixed the documentation on InputMethodService.onKeyUp()
...added documentation to InputMethodService.onTrackballEvent()
...added trackball and generic motion events to the "input" command
...fixed input consistency verification involving ACTION_OUTSIDE
Bug: 7050005
Change-Id: I40ab68df4a9542af6df25de6ec2ec500e4c02902
Previously, to draw a layered view with a changed Paint object for the
drawLayer operation, you'd have to invalidate the parent view, to get the
native DisplayList to pick up the new Paint properties. This change adds
API and functionality so that the developer can call setLayerPaint(), which
does the proper invalidation (lightweight, doesn't cause redrawing the view).
Issue #6923810 Make it easy to efficiently animate a layer's Paint
Change-Id: I7fea79788d50f6d9c86dd5e5b2a4490cb95142bb
1. Getting the value of the content description via the method since
there is nothing preventing developers to override the method to
return a desired value (they should not do that but it is feasible).
bug:7079008
Change-Id: Iaf5848e9b065454ebfefccf685415fbf034ae475
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
Bug #7117785
Draawables created from the ConstantState cache found in Resources must be
mutated before they can be safely modified by apps. Failure to do so results
in all drawables sharing the same constant state to be affected by the
modification.
In the case of the bugreport above, the status bar code plays tricks with
a background drawable and modifies its color to implement a fade in/out
effect. This drawable comes from a cached resource (color 0x0) and the
modifications made by the status bar apply to other clients of this drawable,
most notably the recents panel.
This change fixes several things:
- Simplifies colors caching by removing the assetCookie from the key. This
should result in better reuse of cached drawables
- Makes View.setBackgroundColor() honor the mutate() contract
- Ensure StateListDrawable properly mutates its children before modifying
them
- Optimize Bitmap/ColorDrawable to mark them mutated when they are not
created from an existing ConstantSate. The same optimization should be
applied to other drawables in the future
Change-Id: I54adb5d5b914c7d8930bf9b46f7e3f9dcbf4bcab
When the BaseIWindow.resized method got switched from taking (int x,
int y, ...) to taking (Rect, ...) the SurfaceView.MyWindow override
never got updated.
Fixes bug 6992324.
Change-Id: Id0b9625559ae0100336f4573f09d313138c8a6e7
Large software layers won't draw if they're larger than the size of the drawing
cache, in which case this log will be triggered.
bug:7078391
Change-Id: Ib42a060b8e3b3642417df9243a086aa15b2989b1
- Refactor DragState to take Display instead of DisplayContent.
- Rename xxxAnimationLw methods in WindowManagerPolicy to xxxPostLayout
to reflect animation refactoring.
Change-Id: I502f2aa45a699ad395a249a12abf9843294623f0
Added more complete support for logical displays with
support for mirroring, rotation and scaling.
Improved the overlay display adapter's touch interactions.
A big change here is that the display manager no longer relies
on a single-threaded model to maintain its synchronization
invariants. Unfortunately we had to change this so as to play
nice with the fact that the window manager wants to own
the surface flinger transaction around display and surface
manipulations. As a result, the display manager has to be able
to update displays from the context of any thread.
It would be nice to make this process more cooperative.
There are already several components competing to perform
surface flinger transactions including the window manager,
display manager, electron beam, overlay display window,
and mouse pointer. They are not manipulating the same surfaces
but they can collide with one another when they make global
changes to the displays.
Change-Id: I04f448594241f2004f6f3d1a81ccd12c566bf296
This patch introduces the ability to create a Context that
is bound to a Display. The context gets its configuration and
metrics from that display and is able to provide a WindowManager
that is bound to the display.
To make it easier to use, we also add a new kind of Dialog
called a Presentation. Presentation takes care of setting
up the context as needed and watches for significant changes
in the display configuration. If the display is removed,
then the presentation simply dismisses itself.
Change-Id: Idc54b4ec84b1ff91505cfb78910cf8cd09696d7d
Calling detachViewFromParent() without calling remove or attach in the
same drawing frame could, in some situations, cause a crash in the native
DisplayList code. detach/attach are intended to be very lightweight and do
not manage the native DisplayList content the same way that add/remove do.
Nor do they cause an invalidate() or requestLayout(), which would cause the
native structures to get recreated appropriately.
This fix makes this process more robust in two ways:
- DisplayLists should not get finalized (therefore destroying their native
structures) when there are still parent DisplayLists referring to them
(each DisplayList keeps references to its child DisplayLists). This will
prevent the native crash associated with unmatched detach*() calls.
- The docs for detach/attach have been enhanced to make it easier for
developers to understand how to use these methods more correctly and
successfully.
Issue #7064818 detachViewFromParent() should be more robust
Change-Id: I53befc04d5d58c225060f397725566d470488c9b
The Drive application was calling PopupWindow.dismiss from within
onMeasure. This caused dispatchDetachedFromWindow to be called
from within performTraversals. Since dispatchDetachedFromWindow
destroys much of what performTraversals uses this was a disaster
waiting to happen.
This fix adds a check for seeing if die(immediate=true) is being
called from within performTraversals. If it is then die doesn't
execute doDie immediately, but instead treats it as a call to
die(immediate=false).
Fixes bug 6836841.
Change-Id: I833289e12c19fd33c17a715b2ed2adcf8388573a
Remove workaround for obsolete touchscreen hardware. Provide a better
focal point for scroll events.
Change-Id: I879acb4cfd23bd3762d0332e4df2203d913ae869
Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.
Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.
Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.
Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.
At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.
Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.
Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.
Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
This solves the problems around active pointer tracking when the
caller may skip events in the MotionEvent stream and replaces the
old implementation with a much simpler algorithm.
Change-Id: I6b15a2e215cab7b9559db800fcc57374702357fc
