-> This change ensures that on first draw, the widget is the appropriate size if the
security challenge is covering it.
-> This change is in preparation for some new policy surrounding widget sizing --
with this new policy, a given widget may need to be small even if the page is
not being covered by the challenge. Hence, we propogate this small size to
all the pages, whether or not they are covered. The pages will eventually
use this.
-> Ensure that paging hints are shown correctly (with the new sticky widget
logic the page can be switched, and we weren't always seeing the appropriate
hints).
-> Also ensuring that the page is set correctly on first draw -- generally
this change should make it so everything is right on the first draw.
Change-Id: I7e03be9b027aed0ebb0fada05652b4226fd23897
This makes it so that the view is hidden immediately when
a call to stop is made. This also changes the call in onPause to
only stop and not go to the backup because we still want Face Unlock
to show as the view is being dragged down.
Change-Id: I66d8fc24e82dc3a0155f7d59d8ced932cb584660
Integrate from proto app
* New assets
* Layout changes
* Dragging behavior change for sliding challenge
* Realign camera for new padding
Change-Id: Ia177c60f59f1fc74000d95fc39b048321acf1246
-> Frame resizes dynamically as the security slides
-> Widget shrinks immediately as the handle begins being brought up
-> Widget grows only upon security settling in the down position
-> Cleaned up a lot of state interaction between the security slider
and the widget pager / pages
-> Loosened long press slop (was using Euclidean distance by accident
instead of x crossed or y crossed logic)
Change-Id: Ic52b62e577c539327b0a65c9277300fc626cf190
- the handle size is now entirely independent of asset size
- the handle doesn't have to have a handle graphic
- the handle top/bottom sizing can each change based on
whether the challenge is visible
- now, the handle becomes very small when the challenge is
visible, and does not intrude into the challenge rect
itself (so you really need to drag downward through the
top edge of the challenge to activate the handle and close
the challenge)
- when the challenge is closed, the handle may be clicked to
open
Bug: 7428215
Change-Id: I4ca7b4d5d475337295a6a7492a831abbba288ac5
Proto-Id: Ibc8997ece27ca1e0fa4deb651bb11860f95d7b23
-> updated assets
-> Always showing outlines as per new mock
-> Enabling layers on content during fades (still need to sort out layers for frames)
-> Added carousel overscroll as per discussion with danship
-> Fading side pages in carousel
-> other small polish
Change-Id: If88686768c621a65b175a74c07cb55a69321fd97
Addressing some comments:
- Sticky widget is now saved in a user-scoped setting.
- Removed multi-user widget from computation (obsolete).
- Removed status widget from computation (just use right-most).
- Removed duplicate isMusicPlaying logic.
(frameworks/base)
Change-Id: I8ef8f826677d78ac24da52adf2d99d47c8d965ac
Integrate from proto app
When calling code deliberately hides the slider, block drags of the
slider that may begin shortly after. This prevents the case where edge
dragging a widget can accidentally catch the slider instead.
Change-Id: I7e8e1ad4afbea0abeeb08161ddeb938c858fc4a5
Integrate from proto app
* Positioning at the lower end
* Transparency animations
* Show security frame when dragging until it fully settles
Change-Id: Ic5e5b0bbaa50a123c3492b63c15df3ffba37832d
This change also moves to an absolute-distance model of
tracking the panel instead of a delta model; this allows us
to make the decision about the handle size in only one place
(when first detecting the gesture) instead of requiring us
to mix it into the arithmetic everywhere.
Also fixes the drag-too-slowly-and-the-panel-doesn't-move
problem.
Change-Id: I9bdbadd968134ad5ad67eaef9539536fb5cfe1a1
Proto-Id: I0c2f484da89f063995384c263aa9f5f03339ed7c
- Fix crash in CameraWidgetFrame after rotating to landscape
- Fix pages drift to the left bug
- Address Jim's comments on c/245706
- Disable camera widget if landscape
Bug: 7419070
Bug: 7417798
Bug: 7418781
Change-Id: I5c730c7c1baf3c1872367b6392e6786578765298
Since the code is now very careful about loading layouts, we
sometimes get into a situation where the security view isn't shown.
This CL ensures the security method is shown at least once
when the view is inflated.
Change-Id: If80a46adb868d92194610eccaf9d8d6c2a2c5b3d
- remove redundant signals that were causing keyguard to be rebuilt unnecessarily.
- add a check to ensure we only handle configuration changes if the view is actually showing
- only reconstruct view if screen is turning off or if the configuration changes.
Change-Id: Ia9c7830e370feed6af36cc139d4cd3c5ca0be4fd
This maps activity on the SlidingChallenge to the security
challenge view. Currently it calls onPause() on the SecurityView
if the view is on the move or is hidden.
Change-Id: Ide5f2200e45d8996fa91af06ac2059c3d125ea6f
Integrate changes from prototype app
* Add callbacks for bouncer state changes
* Dismiss the bouncer if focus leaves the challenge area
* Increase edge swipe region, treat this as a slop for
SlidingChallengeLayout's drag handle. (This allows edge swipes in
the drag handle area to still page widgets instead.)
Change-Id: I732de1a8d999a34c7cc8aa8ed99e24b597f3444c
This means the visual glitch is possible again, but reduced since
the layout transitions are disabled.
It's more important to bring back nav buttons for incoming calls
(for the secure, screen off case).
Bug: 7411356
Change-Id: I83005a77930ec7f70a613b3396f85ab1a5fdd96c
Also pull the Klondike telephone exchange letter strings out
into arrays.xml so we can override it for specific locales.
Change-Id: Idf79ff8bfd53e5a8277271cc85ac7a1784ae3b64
The IME wasn't coming up in password mode because the base class always
returned 'false' for needsInput().
Change-Id: Ia5bf508b3e08fa6980e83103322711857af74680
