- Part of fix 5491362 (RelTeamHotIssue)
- Because the fix closes the camera early, this change is needed so
the black area isn't still hanging around while the camera fades
to the backup lock.
Change-Id: Iab7c264adab0fb05979fe2732048ccf2237e64c5
This fixes a crash where we weren't hiding the view when there's
no registered media player. It now hides the view when AudioManager
tells it to clear the data.
It also avoids a possible race condition where a request can
come in from AudioManager before the callback is set.
Change-Id: I3360e775c75396e1eee11413d317df5b39ceb487
- Fix ordering problem in sync manager that would cause its wake
locks to slightly appear in the system process when they should
be fully accounted against the app.
- Allow the system process to have more wake lock names in its
battery stats.
- In the bug report output, print totals of the wake locks for each
process, to make it easier to parse what is being printed for things
like the system process with a huge number of individual wake locks.
Change-Id: I3cf39330f22f3c51c11e65e4124150d73a7da2dd
This works around a file descriptor leak in Skia. It also improves
view creation time by avoiding re-loading the font every time a
DigitalClock is created.
Change-Id: I5c46445da36b1e6ba06c8ca340e436835d281180
Previously, the code was not unregistering the callback when we unlocked
the device, which kept a reference to LockPatternKeyguardView indirectly
by a reference to mFaceLockCallback.
It now correcly removes the callback when we unlock the device.
Change-Id: Ie592d007a1dfc2416b9e8956aba2c34e3d0120ee
- after 15 failed face unlock attempts, go to backup until the backup method is successful
- if the backup method times out (because too many unsuccessful unlocking attempts),
face unlock will not be launched until the backup method is used sucessfully
- fixes 5365919
Change-Id: I9aef7a4f1abcceefc5d6f1c0458ae5cbe8a902df
This changes TransportControlView to be "sticky" on lockscreen. Basically, once it
appears on lockscreen, it stays there until unlocked and then locked again in paused state.
Tested basic design goals (using Music2):
- play then lock -> shows
- pause then lock -> not shown
- toggle pause to play while locked and not shown -> shows
- pause after played once while locked -> stays until we unlock and lock again while paused
- remote control play while paused & sleeping -> resume lockscreen -> shows
Also tested:
- configuration changes (orientation) to ensure widget continues to show after it once appears
- remote events while lock screen on -> keeps lockscreen on.
- remote events while sleeping -> doesn't wake.
Change-Id: I23418c5f7dfd1457c0844d2683772e8a3ed0abd1
When a RemoteControlClient reports an error for its playstate,
make the play/pause button display the warning platform icon.
Note that a specific image description is not available for this
state at this time, but the one being used (the same as for the
play icon) is valid as it correctly describes the action the
button performs.
Change-Id: I59aadab3fe5bcc09a2f7be0b9e4cffb0c500e865
This fixes a regression caused by a resource change to the vibrate
pattern. It used to contain an array of delays and values. Now it has
another mode with just one value with an associated change to the vibrate
API.
Instead of using a custom vibration pattern, it now just follows the system
vibrate pattern for HapticFeedbackConstants.VIRTUAL_KEY, which is shared by the
home key, among other things.
Change-Id: Ib58493a96a42383955ae59f8ac3865bb46a86a31
Fix a bug where action bar menus were using the wrong context to
inflate stock views. This was causing them to use the action bar's
themed widget context instead of the current theme's specific action
bar items.
Note that action views in the menu will still be inflated using the
themed widget context. This can produce some weird side effects if
the action views use theme attributes relating to these action bar
item attributes.
Change-Id: Ied3614d1fedb10a0f5366bbe7b90cd5f2f1ff969
The pattern lock fires accessibility eventa to announce start,
update, and end of a pattern. The pattern lock reacts to hover
events if touch exploration is enabled.
bug:5318807
Change-Id: I5a10c76338ca029f63f278c7e7d0aaba2386f73c
Replace TrafficStats calls by reading values from xt_qtaguid kernel
module. To keep BatteryStatsImpl changes lightweight, cache recently
parsed stats. Tracks mobile ifaces from ConnectivityService.
Refactor xt_qtaguid parsing into factory outside of NMS. Add stats
grouping based on UID, and total based on limiting filters like iface
prefix and UID.
Bug: 4902271
Change-Id: I533f116c434b77f93355bf95b839e7478528505b
The PhoneWindowManager is now responsible for hiding and showing
the nav bar.
For hiding, it just moves it off the screen (easy way to get a
nice slide animation on and off). At the same time, we use a
new WM facility to put up a fake input window to capture all
touch events.
When a touch event is received, we force the system UI to clear
the navigation hiding bit so it will be shown again.
This removes a bunch of code from the system UI for hiding and
showing the nav bar. Also removes the code calling from userActivity()
to the system UI, which was bad. (Also no longer using userActivity()
fixes bugs around re-showing the nav bar due to key presses and
other wrong things.)
Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
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
This flag will be used to show a tutorial screen first time it is used.
The flag is set to true once facelock has been set (via the savePassword or
savePattern when in fallback mode)
Change-Id: I43e3f876810fd32d3d5a5a285201e8054c4b3098
If Face Unlock is currently enabled when the device policy manager is installed
it now forces the user to choose a new acceptable lock type
Change-Id: I725e923240538df3f706251670bf497857d2a25f
This allows face recognition to be enabled through Settings.Secure,
so we can test on selected devices.
Change-Id: I7f832cafd6a98f4289d618bc8924cd467706b778
Renamed isBiometricEnabled to isBiometricWeakInstalled. This function
now checks if the system property is set, the facelock package is
installed, and if the phone has a front facing camera. It no longer
checks if facelock is currently set as the unlock method.
Added isBiometricWeakInstalled checks to all cases where facelock is used
in LockPatternKeyguardView
Change-Id: Ia86a7ad6118101c6aab90ffb2ee9c42bf2548149
Multiple focusable windows cause undesired behavior around selection
modes. TextView isn't sure how to behave when it loses window focus
with regard to selection handles and action modes need to be focusable
for WebView find on page since it uses an EditText as a custom view.
For now:
* Use a layered window decor for overlay action mode when there is no
action bar requested. This eliminates an extra window and avoids the
issue described for full-screen UIs.
* Disable WebView's find-on-page mode when the action mode's UI will
not be focusable. This only affects WebViews in floating windows.
Also remove the "Text Selection" title for WebView's selection mode at
UX's request, as it is inconsistent with TextView's selection mode and
the string does not fit on phones in portrait even on wide
devices. This now uses the same mechanism used in TextView to decide
whether to use title text.
Change-Id: I80caeecea9b47728cf26bb0a388153ca0bdeafe1
"image/jpg" is not a valid mimetype while "image/jpeg" is.
So change it to "image/jpeg" to increase the compatibillity with other
Apps in android. (e.g., Gallery)
bug: 5342561
Change-Id: Ia37433e35482492b7226c87a670bef3399ac4bb6
This is done when the backup lock is complete or canceled.
If successful, the permanent gallery is replaced with the new one.
If canceled, the temporary gallery is deleted
Also deletes the main gallery if the lock type is changed from facial recognition
Change-Id: Id1ce804dec6b71b6410af53c050ad265c4cad5b0
Action bars in dialogs are largely an undocumented "feature" but they
do work - with the exception of this since it previously relied on the
host being an Activity. Make it work.
Change-Id: I52ae24c3bfdd9766e4c0f035183e7f148a4e0162
Prior to this fix if the screen was off and a call was received, the
onScreenTurnedOn() callback would bring up the FaceLock service,
which would cover the phone interface. It now requires the call state
to be CALL_STATE_IDLE to start FaceLock. When the phone interface
closes, the user is left at the backup lock screen. Bringing FaceLock
up after a call ends does not seem like the correct thing to do.
While working near the FaceLock callback code, the sleepDevice()
callback was removed because it is no longer used (Fix 5327896).
Some cleanup was also done with regards to KeyguardViewManager.
FaceLock calls were being made from the KeyguardViewManager in
onScreenTurnedOn() and onScreenTurnedOff() via an interface to
LockPatternKeyguardView. This level of indirection was removed
because it can just be handled inside of the corresponding calls
in LockPatternKeyguardView. Likewise the FaceLock functionality
inside of hide() in KeyguardViewManager is now in
onDetachedFromWindow() in LockPatternKeyguardView. Overall this
is much cleaner, especially considering interfacing through
KeyguardViewBase was a bit of a hack.
Patch Set 2:
- Now using KeyguardUpdateMonitor to get phone state
- Removed unnecessary wrapper functions for hiding / viewing
FaceLock area
- These were really only there because at one point I was calling
them from KeyguardViewManager and the naming was confusing
- Removed if(DEBUG) from a couple of log messages that are actually
warnings that shouldn't show up and I want to know if they happen
even if I don't have DEBUG set to true
Change-Id: Id7befc47dd421156ff6cdb3aaf62fc76fe9cfad2
Previously it was possible to get an inconsistent state because there
were two paths that updated the lock screen sim state. This reworks
the data flow to ensure the same path is always used to update the state.
KeyguardUpdateMonitor now correctly updates the entire state of the callee
whenever a new callback is registered.
In addition, KeyguardUpdateMonitor now caches the phone state in order
to avoid a round-trip binder call in updateEmergencyCallButtonState().
This avoids a condition that could make lockscreen unresponsive while
updating the emergency call button state.
KeyguardStatusViewManager also ensures the TransportControlView is
hidden when created to ensure we don't inappropriately update the carrier
line while waiting for the first callbacks to update the status lines.
Change-Id: I6b3975b703a7d90bac8d0fe29fbc0f1d9c5e0e7d
