Remove the right-to-left cascade effect from action mode menu
items. Animation time is now fixed at 300ms for scaling in menu items.
Change-Id: I8eef2ed9f93c2af804663dd5e6b3f4915ed45cb1
This adjust various paths through InputMethodManager so that the flow
in switching focus from one application to another is cleaner, resulting
in less work being done, resulting in it being able to happen quicker.
Some of the changes here avoid doing stuff when not needed, such as when
we are told to unbind but are not currently the active input. A big part
is also a change to the flow when a window receives input. Previously
this would first do a checkFocus() which would tell the input method to
switch focus to whatever view has focus in the window, followed by the
windowGainedFocus() call telling it the window had gained focus. This
would result in extra work because the input method service would first
handle the focus switch, seeing the IME is currently displayed, so the IME
would remain up and reset its focus to the new view. The app would
immediately then tell it about the window, causing the service to find out
the IME should be hidden and telling the IME, but the IME couldn't hide
itself until it had first take care of switching its input.
There is the definite potential of this breaking IME showing/hiding in
cases depending on the order things may be relying on them to happen. I
haven't seen any problems with a brief trip through the UI.
Change-Id: I8494cbd6e19e2ab6db03f2463d9906680dda058b
Since CDMA doesn't use APN settings there was no place to say what a cdma
device's DUN connection would support, so by default normal device
originating traffic would be blocked on a tethering single-connection device.
With this change you can (via overlay) say that it supports everything
so mms and on-device browsing/email will still work even when on a dun connection.
The reason to allow both: some carriers will charge per byte for dun access
and so they don't want lots of non-tethering traffic used (costs the user alot)
but other carriers just use a dun connection to limit access to tethering, but
once there give unlimited data, so it makes sense to support everything there.
bug:5972599
Change-Id: I78fd7f3ac63c51a0560b659ed5ec219b10a93f8d
This patch is adding a capability so that OEM can override USB mode
in case the device is boot up with OEM specific mode. (i.e. modem
debug, factory test etc.)
Bug:5964042
Change-Id: Ic8e23d302563ce71eedb74ce94cca8c65838a4f7
fully documenting the device default themes and fixing many more,
including adding API level information for older themes to avoid confusion.
Oh and fix an unclosed <em> tag causing a format bug.
Change-Id: Ia4b33559bd5ad2cbae8b53966999cf7f5038b125
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
This fix does not include the change to ignore app tokens that are
hidden. This causes problems in some dialogs that stay hidden until
their app is ready to display, but need to perform a series of relayouts
during that time to get to the right size. Dropping this part of
the change still (mostly?) seems to allow us to avoid the bad states.
Change-Id: Ic052cb1499d3287f47e9ffeac5cd2470ee5a308c
Also relaxed the settle time constraints a little bit.
With this change, a rotation proposal will always be
advertised within 500ms even if the device is still shaking
around.
Bug: 5496491
Change-Id: I0bf562f4c19c0be45c016254f2f881d265f8e266
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
incorrectly specified.
This affected search bars and alert dialogs spawned from activities
using Theme.DeviceDefault.Light as a base.
Change-Id: I219d38d486498db5b4b283560256afd7d6051535
The documentation is now consistent with the current UI guidelines
for handling notifications, and includes complete sample code showing
the correct way to do this.
Change-Id: I68f0afc62c2af164c3205535e62093679e2a256a
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
Also don't consider windows a candidate for layout if their app token
is hidden. This fixes a transient state where we are preparing to
unhide the window but have not done so yet.
Change-Id: Ife5299ffa003c1df1a4f787b7a2809cbf614ec16
Currently, when airplane mode was on and BT was on, turning BT off
moved BT to hotoff state. This fix moves BT all the way to Poweroff
state to have better power performance.
bug 5854282
Change-Id: I7ba41797a46a81ddb3a576453f2a8303b5eed525
Bug: 4586251
Cherry picking from master for ics-mr1.
Current ssl cert logic makes callbacks to webkit from the
UI thread. This is not right. Move the callbacks to proper thread.
Change-Id: I59affba47eca01b74e2bc33d88ef83a5850d6ce9
Fix 5783857: Device Policy Manager doesn't allow Face Unlock
This makes it so that if face unlock is enabled and then a device policy
manager that requires something more secure than face unlock is installed,
the user will be forced to choose a new acceptable lock type.
This was previously fixed for the case where the device had been reset, or
the shell was restarted after setting face unlock, but not for the case where the
device remained on between setting face unlock and setting up a device policy
manager.
Also changed the function ordering of saveLockPattern() so that the overloaded
wrapper function is next to the main function.
Change-Id: Ibed8c4ab137ebbc07fb143faef6f047bc6dc4474
This adds a feature to delay locking the device when the power button
is pressed. This fixes a use case where the user wants to turn off
the display (e.g. to save power) but doesn't want to lock the device.
For the case of a secure device (user has a pin/password/pattern),
this will lock the device immediately or not based on the setting.
For the non-secure case, this always "locks" the device to provide easy
access to the camera while preventing unwanted input.
Change-Id: Ie328485c3f7559e26896d761cbf0e69d3f4df4e2
For non-localized strings like the keywords in SQL statements, we shouldn't use
locale-specific case transformations.
(Cherry pick of 03f8f84c345e7c861a6de889d434b9d82cf04c8d.)
Bug: 4284951
Change-Id: If5b7154f70a7db22837d071d1c57e929729b7d35
- cherry-picking framework CLs from master into ics-mr1 that are
needed for FU to work on tablets
- needed for OEM partners even FU isn't going on xoom
Squashed commit of the following:
commit 3258f2528f558efdaf34ae15c5425f2d879848fe
Author: Brian Colonna <bcolonna@google.com>
Date: Tue Dec 13 15:49:48 2011 -0500
Added Face Unlock to tablet lockscreen layouts
The Face Unlock Area was not part of the tablet layouts, so prior to
this change, Face Unlock would not show up on tablets when selected as
the unlock method. The backup unlock method would show up instead.
The goal here is for the pattern and PIN unlock layouts (in both
portrait and landscape mode) to look the same as before this change.
This was a little harder than it was with the phone layouts for two
reasons:
1) For the phones it was ok for Face Unlock to be sized such that it
just covers the backup method. For the tablets we want Face Unlock
to cover far more real estate.
2) The phones were based on a grid layout, whereas the tablet is a
linear layout.
Note that the diff makes the modifications look way more extensive
than they actually are. Basically, in most cases I am putting a
relative layout around some existing portion of the layout and
putting the Face Unlock Area area inside of the new relative layout.
Change-Id: I478becddf2a9ee9fe7b6d653e604fa3ad89b822f
commit 821cfe85cf2b3daf074d9749dbf6e0a5663af0de
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 19 15:51:10 2011 -0500
Unbinding from FU when going to backup
Lockscreen was stopping Face Unlock when going to the backup lock, but
not unbinding from the Face Unlock service until the device was
unlocked.
This caused a bug on the tablets where Face Unlock would reappear when
switching between portait and landscape orientations, even after the
backup lock was exposed. On an orientation change, Face Unlock is
restarted if the service is bound to during the orientation change.
Since it was bound to when it should not have been, Face Unlock was
restarting when it should not have been.
The wakelock is also now being poked on an orientation change because
on the tablet you can keep Face Unlock alive by switching the
orientation back and forth, but eventually the screen would go dark
with Face Unlock running.
Also, a conditional was moved in activateFaceLockIfAble() so the whole
section isn't executed if Face Unlock is not in use. Part of it was
being executed with only the inner-most part having the check. This
did not cause any issues that I am aware of.
Change-Id: Ib452b8ced28a507bf9272dbf5d3477a8abd1ba90
commit fa90bb76ac6b311d12b55d23df4ac44cec62c7b3
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 12 18:02:23 2011 -0500
Changed how Face Unlock coordinates are specified
Was using View.getLeft() and View.getTop() to specify the upper-left
corner of the Face Unlock area. That gives coordinates relative the
view, which was fine for the phones. For the tablet it needs
coordinates relative to the window (which still works for the phones).
Also fixed a 'bug' where h and w were swapped. However, it wasn't
causing a problem because it was swapped in two places.
Change-Id: I86c1f68439f1dcef826cfe6b8fb56c9a4a6b8dc3
Change-Id: I962c0486be85949e002b0a2701286a6a39251f36
This adds Resources.getDrawableForDensity() and
Resources.getValueForDensity(). These are needed for applications
to correctly retrieve larger icons such as in launcher when
running on a tablet. We had already exposed the APIs to tell the
application which density to use for app icons on the current
device, but didn't unhide these APIs that allowed you to
actually retrieve them.
This is safe to do without introducing a new API level (as long
as we do it soon) because we know these APIs already exist in
Android 4.0, and there is no reason for anyone to be removing
them when building a device.
Change-Id: I5138e5dc908197b66a98d20af73c5374cb5d41d3
