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
This fixes showing the emergency dialer on devices without telephony.
Two fixes were required: 1. Move emergency dialer code to the view
that contains it (KeyguardSelectorView). 2. Always call onPause()
or onResume() in onScreenTurnedOff() and onScreenTurnedOn(), respectively.
Fixes bug 7117895
Change-Id: I96769fdda8478b6b60f46f7470bed2279ea2de72
This fixes a bug where we'd stop updating the status view in keyguard
because KeyguardStatusViewManager had no references.
It also fixes a bug where KeyguardUpdateMonitor wasn't removing objects
because objects were being compared with WeakReferences rather than the
content of the WeakReferences.
Bug:7095359
Change-Id: I2d9df6097b2270655ad3662bcf7a6757e0515363
This fixes a crash where LockPatternUtils hasn't been set yet and
keyguard attempts to get the device policy for widgets.
This change breaks the dependency by getting a handle to DPM directly.
Bug:7109723
Change-Id: Iecae91474358821ebd30456648377253864c35cf
We now fade between security screens when not coming from selection view.
In the case of SIM PIN/PUK screens, this means we show the user's security
screen without going back to the selector view.
This change also adds a fade animation for when we go between security screens
without going back to the selector view.
This also fixes a bug where we were invoking two checks for the SIM
state - one for ACTION_DOWN and another for ACTION_UP.
Change-Id: I260f9a2e0316cbf26ec7621f774bfdf9956ca488
- Refactor DragState to take Display instead of DisplayContent.
- Rename xxxAnimationLw methods in WindowManagerPolicy to xxxPostLayout
to reflect animation refactoring.
Change-Id: I502f2aa45a699ad395a249a12abf9843294623f0
Bug:7088530 Lockscreen falsely states "Wrong PIN"
Bug:7091531 Owner name no longer shown on slide to unlock screen, Nakasi
Bug:7091131 When entering a SIM PIN, focus is not put onto the pin entry box
Change-Id: I5c7e957083b25a3445804ea092d962163d187fa1
- Fix "too many attempts" dialogs
- Fix account unlock mechanism so the user can use email account as backup for pattern unlock
- Add mechanism to support future account recovery from non-pattern screen
- Tune animation timing for flipping security view.
- Move password field to the top of the security view
- Add padding and visual feedback to navigation area button
Fixes bugs 7088482, 7088631
Change-Id: I23099feae3b7446ec291d8f860601bfc12f9edd8
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
This change allows keyguard to launch the secure camera when the device
is in a secure mode. It also allows launching delayed actions after the
user has entered their security, such as that required for GoogleNow.
Change-Id: I54975001728ced3c339f86eafc3a38cea606082b
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 change refactors keyguard to be more modular and maintainable. More
specifically, it replaces the top-level view with just one device-dependent
view that contains two views: a widget area and a security area.
The widget area can be populated with custom widgets.
The security area contains the current security method as dictated by
the stored password quality.
This change contains both the old and the new keyguard with the old keyguard
still enabled. The new keyguard will be enabled in a subsequent change.
Change-Id: Id75286113771ca1407e9db182172b580f870b612
Let apps bindService() across user boundaries if they hold the
INTERACT_ACROSS_USERS_FULL permission.
Bug: 7012034
Change-Id: I2047d8318e1de47bfae7470d1dbc6fe5cfe44fdc
There are potentially very many Handlers owned by services
that should not be blocked by barriers introduced by UI traversals
occurring on the same thread (if that ever happens).
Add some convenience constructors to make it easy to switch
these Handlers over to being async.
Bug: 7057752
Change-Id: I64d9bffe81e7c52ada4cfad4e89d4340153f4688
bug: 6879638
- add new enum value BATTERY_PLUGGED_WIRELESS
- check for sys online file with contents "Wireless"
Change-Id: I22dc3c40f50573c98643e7b5cbcb237d0216530d
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
Use AtomicFile for usermanager files.
Added a MANAGE_USERS permission that apps (signature permission) can use
to create/query/modify/remove users.
Change-Id: I5cf232232d0539e7508df8ec9b216e29c2351cd9
Don't send a "cancel preloading" event to recents
from PhoneWindowManager if we're not using
long-press on home to invoke recents (ie phones
with soft nav keys)
