Otherwise there would be no way to switch users if a user chooses None as lock screen.
Also adjust some layout params for Preference items to align the icons and text.
Change-Id: Ib11bb961edaef90de280bc7137d10b68765aea98
The API is quite simple. There are a few extra functions
on DisplayManager to scan, connect and disconnect from
wifi displays and get status, and a single protected
broadcast sent when the status changes.
Change-Id: Ic91dbab5ee818e790b27fa32e1a1e93788793be0
This change removes all but the default KeyguardSelectorView from KeyguardViewHost
to (1) reduce the overall memory footprint (2) reduce initial layout inflation
time and (3) avoid initializing the camera until needed by face unlock.
Fixes bug 7127666
Change-Id: Ibac1838dd7a490dcadbfab5bdfdd82734b69055a
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
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
This will make the default value of the automatic synchronization
in the SyncStorageEngine configurable with overlays for use by
vendors who want or have legal requirements to have the synchronization
off by default.
Change-Id: Iabdb355c4a1169fe8e254e91c43e162c5913d5e0
We've been setting this per-device for forever; it's time to
just change the platform default (was 00ff00).
Bug: 7094412
Change-Id: I5fbd126580cf06e59958bab32a333b21359d01a9
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
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
- 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
Send the Intent.ACTION_PACKAGE_VERIFIED to all verifiers when
verification is complete (either one verifier verified the package or a
timeout occurred). Details of what occurred is in a new extra,
PackageManager.EXTRA_VERIFICATION_RESULT.
Bug: 7048930
Change-Id: I4f9855a29b0eb6d77f469891402c69e2e8922945
System services holding this permission have external storage bound
one level higher, giving them access to all users' files.
Bug: 7003520
Change-Id: Ib2bcb8455740c713ebd01f71c9a2b89b4e642832
