- support for global "disable" setting
- renamed settings provider keys to remove "DREAM"
Bug: 5591015
Change-Id: I31f31b3ca6001fec1e0032a49cdf0d10df7b0ec7
This bug is the result of onPause()/onResume() not being called properly
when we have both lock and unlock screens present, which is true for the SIM
and PUK unlock cases.
The fix is to invoke onPause() and onResume() on both of them if they exist.
Verified the rest of the code correctly handles having both.
Also, when the user cancels, we now clear the fields.
Change-Id: If7fbd31df7eab9e3d60656d50d2392607a4bf471
This fixes a bug where we would inadvertently show the pattern
screen after PUK-unlocking the device. Could potentially happen
after SIM unlock as well, but that path appears to be fast enough that
it's rarely seen.
The cause was not getting the SIM state change before deciding to show
the Unlock screen.
We now immediately invoke the callback if SIM/PUK unlock succeeds without
waiting for the round-trip from the radio layer.
Change-Id: I02dcb456da415b82f30f8e3abc43f788f3931b33
The window manager now monitors the plug state; the screen
saver will never be automatically started if the device is
running off battery.
Change-Id: Ib1064d9cdd540238957df3ba7020303b0f6943c2
When a device is attached to a desk dock, the
CATEGORY_DESK_DOCK intent will no longer be fired.
As a side effect, the "dock home" behavior (which captures
the home key for the dock app as long as the device is
docked) is now disabled for desk docks.
Car docks are unchanged.
Bug: 5591015
Change-Id: I7884f655913c31cf53b88cb2e2b371987be27f64
Currently set to DeskClock's screensaver, but since it's a
(private) string in f/b/c/r/r/values/config.xml any product
could overlay this.
Bug: 5611008
Change-Id: I7a4623c9c667a6cff8ed80ad600a8a4460bfafb7
Applies to docks, lid switch, HDMI and rotation lock.
We always choose a mode that is compatible with the application's
request, so if in a landscape dock, we might override a request
for seascape but we leave requests for portrait alone.
Bug: 5620454
Change-Id: Ib0c4f60f7f9e3aeafaba9c717233a950fccb8af2
This fixes a problem where the alarm status was forced to scroll on phones
when the date string got too long. We now abbreviate the day on lock screen.
Change-Id: I99990f1568282c65fb6ed4e78d20bb31b3487a8e
Some countries require phones to show "Emergency calls only" when
roaming on a device with no Sim. This changes causes the phone
to now display the PLMN string on devices that are voice-capable when
the sim is missing. This depends on the PLMN containing the text
"Emergency calls only" when the radio has connectivity to any carrier.
Otherwise, the PLMN is expected be null or empty which will cause the
device to just show "No SIM card."
Change-Id: I7c1d4624ae67074e2ca40161845ca8bb36031c42
This updated tablet layouts to support showing album art and transport
control views in PIN, pattern and password screens of lock screen.
It also allows the addition of a background protect asset and
the ability to show the system wallpaper on layouts that define a
transport_bg_protect view.
Also updated layout to use new ICS-style buttons on lock screen and
fixed bug with "forgot pattern" button where we were showing the
emergency call icon.
To avoid problems with leading ones in the mono-space clock font,
we now right-justify status text on tablet and remove the AM/PM
indicator.
Status font size adjusted by UX.
Added background protection drop shadow to transport control.
Fixed portrait mode to be right-justified when transport is showing.
Change-Id: I790292fc39f4588f87adc9d9241706817ae6baab
Drive the menu button off of the currently focused window. That is, after all,
the one that is going to receive the menu key event.
Change-Id: I61cac1e274602e5ea53402ab15bd63a9cd89e9cd
...should not be restarted when rotating screen on xoom
This was a side-effect of a previous fix to compute the screen layout
config class based on the actual space available to the application, not
the raw display size. On a device like Xoom, the system bar causes us
to switch between LONG and NOTLONG depending on whether the system bar
is on the short or long side of the screen.
To fix this, we now compute the screen layout class the same way
"smallest width" is computed: looking at all of the possible rotations
and using the smallest of them all. In addition to preventing the device
from toggling between long and notlong on a Xoom-like screen, this will
also avoid other possible undersireable behavior like changing screen
layout size when rotating.
This does mean that Xoom is no longer considered a long screen even when
in landscape, because it is not a long screen in portrait.
Change-Id: I85f90a16294ef5a7de94d5b9231abbc6f914fe90
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
