Theme.Holo.Light.DarkActionBar gets black text
Make sure that menus generated for use in action bars get themed correctly.
Change-Id: I14ba676d296c785514425d40d89e62dc4ff1da1a
Be more explicit about initialization -- power manager never sends
screen update when first initializing, phone window manager retreives
current screen state and applies that itself when initializing.
Change-Id: I8294ed36d700e186c1637754df8c8183721c15dd
1. Make Pin and Puk focusable EditText.
2. Add hint text for pin and puk.
3. Update focusEntry logic.
bug:5243771
Change-Id: I65bd52510bbbf0ebd7830ecac7e31159ae750c6c
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
ActionProviders (or action views) unfortunately had no way to report
that they had opened a sub-UI that would affect menu visibility
listeners used to hide action bars when not in use. This caused the
Gallery UI to hide its action bar when the share popup was open.
Add hidden API (to be made public later) to ActionProvider that can be
used to inform the menu system that a sub UI has opened or
closed. Account for this in menu visibility callbacks. Fix
ShareActionProvider to use this when its popup windows open and close.
Fix a regression where submenus were not properly reporting visibility
changes.
Change-Id: Ia6f45fb463ad106105c40d01f141c2e5c8b96f78
Notify the register the current sim state right away in
registerSimStateCallback.Otherwise the register won't
receive any state until sim state gets changed again.
That will introduce a racing condition. If the sim state
changes to PUK_LOCKED after registering the callback, the
PUK unlock screen shows up. If the sim state changes to
PUK_LOCKED before registering, the PUK unlock screen won't
show.
bug:5243771
Change-Id: I27de1329a30adba68952cf086d2130c4cef54270
We need to hold a wakelock while playing the keyguard lock sound,
so that it actually completes before the CPU goes to sleep.
Change-Id: I144c345383afeb911ea461b2eb17b31183b6d092
The key thing was to fix isVisibleOrBehindKeyguardLw() so that it
wouldn't count a window as not visible if it was just currently
in the process of drawing due to an orientation change.
Also improve logic in deciding when to turn screen on to better ensure
the screen is in a stable state, in particular treating screen off
as a frozen screen and not allowing it to turn on until the
update of the screen due to any config change is done.
Change-Id: If82199f3773270b2d07f9c7de9da2dad8c7b28d7
Change the standalone action mode window for overlay mode to be of
TYPE_APPLICATION. (This also fixes a bug where overflow menus would
not work properly on these types of action mode bars.)
Set exitFadeDuration on btn_cab_done_holo_* drawables.
Remove no-window-focus override selector states for selectable item
backgrounds to allow proper touch feedback on windows that do not have
focus but that the user can interact with.
Change-Id: Ib504866238708150d21e6183ff7b695869c05d3e
Rework how we decide when it is okay to turn on the screen by having
the policy call back to the power manager when it knows the lock screen
has been drawn.
Change-Id: Ie8f3f72111dcf7f168723e6dce24e0343b4afe5d
- FaceLock area now specified in layout files instead of trying to
grab an existing view, which was only practical if pattern was
backup method
- Now fills area it is supposed to and works with pin as well as
pattern backup
- Backup method is no longer exposed behind FaceLock just before it
starts or just after it tells the lockscreen to unlock
- Added synchronized blocks so FaceLock cannot be told to stopUI by
two different threads at the same time
Change-Id: I3bfad6b44dbe0e3c2ea3c87d2978451c22a7484c
