ACTION_CAMERA_BUTTON is for camera hardware button. Change the
intent to INTENT_ACTION_STILL_IMAGE_CAMERA.
bug:5572158
Change-Id: I49ffbf50ecd4458065ee1c2d1fdab8d9e696a1a8
Some carriers cannot process emergency calls when the IMSI is not available,
which happens when the SIM is locked. This allows the behavior to be overwritten
in an overlay. When the config variable is set to 'false', the emergency
button no longer appears on the SIM or PUK unlock screens.
Change-Id: I3127bfd5e7ebfabea997fbe048cc474e48b7a81c
Sometimes the lockscreen view is recreated even though it has already
been created (and therefore Face Unlock is already running). One
example of this is when the lockscreen momentarily displays in
landscape mode and then corrects itself into portrait mode.
When lockscreen recreates itself, it removes the view and then later
re-adds the view. During that time the window token is null and may
be passed to Face Unlock when it tries to restart. The reason this
doesn't happen *every* time the view is recreated is because the
onServiceConnected() callback starts Face Unlock, and usually it
runs after the view is re-added, but sometimes it runs before the view
is re-added, resulting in this bug.
An earlier fix put null-token checking inside of the Face Unlock
service, which prevented crashing but Face Unlock was still unable
to run. This fix makes the null token case not happen so Face Unlock
can run every time. It accomplishes this by simply not restarting
Face Unlock until the view has been re-added.
This fix also replaces checking two flags everywhere to see if
Face Unlock is being used and instead uses a single function call.
Change-Id: Ib46f25f2a58ab2e70470337861c25ee81a858873
Fixes these issues:
- add IME button to switch IMEs on password screen on tablet
- centers '0' on PIN screen for phones and tablets
- tablets now use the same ICS background key asset as phones
- make PIN layout consistent between phones and tablet
- center the I-beam when any button is showing in the password entry field
Change-Id: I4da0173f9b2efeab46617c5a41a8132895b63a97
Previously the code ignored SIM state when lockscreen was set to "None."
It now properly accounts for the SIM state when deciding to show.
Change-Id: I272348c1a21b57ac146910850ea3db3adef0227c
In order to completely mute the ringer (no vibrate), introduce an extra
state beyond mute, which mutes the vibrator as well, if it was enabled.
Bug: 5530217
Change-Id: Ib1f299ee6bbca56c1aa7e1100662591362d08307
This fixes a problem where we'd sometimes show a '|' in front of
the spn string or after the plmn string.
Change-Id: I6a3a398b0ddf89fcc8862b275dea0e925873b56a
This is a fix for a bug where we'd show "connect charger" when the device was
connected but not charging due to the battery being in an unchargeable state
(too hot, cold, etc).
It now maintains a full copy of the battery state and uses the plugged status
to determine if the device is plugged in.
Change-Id: I60fa4e4566a45663b130f0ff4863bcc595ae3c4a
- This issue was marked as RelTeamHotIssue
- When Face Unlock is enabled, the black area is shown when going into
the emergency dialer to prevent the backup lock from showing.
However, it was doing this even if Face Unlock has already gone to
the backup method.
- Since the same code is used for returning to a call as is used for
starting the emergency dialer, it was doing the same thing when
resuming a call.
- Just had to add a simple check to only display the black area if
Face Unlock is still running.
- Note that this did *not* cause a problem when Face Unlock was not
the unlock method.
Change-Id: Icc4deebcb47ceda035ea29c7d976342d3a8a60a7
qemu.hw.mainkeys indicates if the device has h/w main (home/back) keys.
If it has main keys, then the navigation bar is *not* displayed.
Change-Id: Idb36a1f787360363a009463f0c016a423594a5b9
- 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
KeyguardViewBase maintains the transparent background for all lock screen
views. The background was being overwritten by the change to make lock
screen opaque when music was being shown.
Change-Id: Id1ab415f68746b20c9229fa58fef9ec8be354f01
It is no longer sufficient to check the value of
internal.R.bool.config_showNavigationBar to determine if a
navigation bar (separate from the status bar) is shown on a
device, because the emulator needs to be able to override
this value (now possible by setting qemu.hw.mainkeys to "1"
or "0", for navbar or no navbar, respectively).
This logic is now contained in PhoneWindowManager, and any
clients wishing to know whether the system has a software
nav bar should consult the new hasNavigationBar() method.
Bug: 5404945
Change-Id: I119d32a8c84b88b2ef46f63244e7f11dc5de0359
This fixes three issues;
- Make the background black while the transport is showing.
- Show scrim sandwiched between artwork and overlapping UI.
- Remove gaps in sides of background assets.
Change-Id: I563fc680c4c042d8b25ec37332aeab528cf838ca
If you turn the device from portrait to landscape mode and immediately
invoke the lockscreen, it will come up in landscape mode and switch to
the desired portrait mode within a couple of seconds. Previously,
Face Unlock would come up in landscape mode, but its position would
not change once lockscreen corrected itself, causing Face Unlock to be
partly off the screen.
This has been fixed by checking if we are already bound to Face Unlock
when the layout is created. If this is true, then the layout is being
created due to a change in orientation, and we stop Face Unlock, and
restart it at the new position.
This commit also adds a fix where we now use INVISIBLE for the Face
Unlock area when it is not showing instead of using GONE. The
dimensions of the Face Unlock area is 0-by-0 when set to GONE, and we
want to avoid the possibility for the Face Unlock service being
assigned a zero area. I'm not sure if this was ever causing problems,
but it certainly is not the intended behavior.
Also cleaned up some comments and logging.
Change-Id: I68deb49cb26dafb5c238167d0c23f0eed2cfb75a
- Removing the second ticker text
- Adding a new animation to the status bar
- Adding a large icon to the notification
Change-Id: I8778178519fc72ffc299e8d624069b684475191d
This fixes a bug where we were no longer showing the countdown dialog
every 5 attempts or "forgot pattern" button when the user has a fallback
password enabled on the pattern unlock screen.
It now correctly shows the dialog whenever the user hits a multiple of
5 bad attempts on any of the pin/pattern/password screens.
Change-Id: I4eb47b4149958a93572d256a4a70f9d67bc1eb38
This fixes a bug where the clock wasn't being shown in the statusbar while
the music widget is showing.
Change-Id: Ic1c52c4ab7fa1490fe14ddafaf2c494bcf51866d
...from ever becoming visible
Now there is a 1 second delay from when the user dismisses the nav bar
until when it can be re-hidden.
Also move the code for capturing touch events while nav bar is hidden
out to be used even when there is no nav bar, so this API behaves
consistently across devices whether or not they have some element of
the UI that is being hidden. On devices with a nav bar, this will
all work the same as prime (the flag is set, the app gets the callback
about the flag being set, when the user touches that touch is captured
so the app doesn't see it put does clear the flag and tell the app
about this).
Change-Id: Icb5ea0ddaf614aa3f12d2140796217f128761dee
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
This fixes a memory leak caused by not unregistering the info callback
held when LockPatternKeyguardView gets destroyed.
Change-Id: I8c008b6f8a5e8471bd0e1fd3939aa75175923ce5
- 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
I introduced a bug cl https://android-git.corp.google.com/g/#/c/141926
that caused black box to hide lock pattern even when not using Face
Unlock.
Fixed by adding the corresponding check to make sure Face Unlock is
being used.
Change-Id: I9c429c99d7db4d1ab831080f23a1e10123dbfe3e
When the screen turns on because of an incoming phone call or
when the emergency dialer is selected, FaceUnlock is deactivated
until the phone call is completed and the screen is turned off.
This also checks for non-phone overlays.
If the lockscreen becomes unfocused while the screen is on,
we assume that the reason is an overlay and prevent FaceUnlock
from starting. The normal clock app is not considered an overlay by
this approach, and thus it works as intended (back button
brings up FaceUnlock).
Also reverts: https://android-git.corp.google.com/g/#/c/139885/2
to make FaceUnlock appear when music is playing again
Change-Id: Id715878556667d2b7e35c30a28d91be6a4eee575
Now poking the wakelock when Face Unlock goes to the fallback method.
Previously, the backup lock would stay up for a varying amount of
time depending on how long Face Unlock took before fallback. The
backup is now consistently displayed for 5 seconds.
Also added comments to some older code.
Change-Id: I9f6bdd2d3015e7eb9cb90143737a3cdc87189993
