targetSdk < ICS
Compatibility support for existing apps. Apps in the wild that
properly target <=GB phones and HC tablets should be able to expect
that their small-screen UI will continue to work as intended on ICS
devices. Make sure that we show the soft menu button in the nav bar if
the current device was not officially supported in Honeycomb, the app
does not target ICS or newer, and the window does not have an action
bar.
Change-Id: I069c30841d3827a60ef8040831fde6f4c051d0ee
Bug: 5202824
It's possible for removeDeadProvider to be called after the provider
has already been removed from the provider map due to a race between
binderDied and removing the provider.
Deleted removeDeadProviderLocked; it was dead code.
Change-Id: Iecdc68703225e7ac171746e63f1b3141c6f2ce4c
Set bluetooth discoverable off at power on time if the discoverable timeout
is no forever
bug 5068151
Change-Id: I413e8de5f49030b741a8b84a566065d112ee60be
prevent icon from moving when drilling into hierarchy
Fix up the layout of home/up/titles in the action bar such that showing/hiding
the "up" indicator never changes the position of the icon, logo, or title.
Change-Id: Ic2117babe3a54619a4b787d5374295955a58fb34
across different applications.
Alter font sizing and metrics of standard list item layouts to match
UI spec. This fixes metrics issues in dialogs, menus, and more.
Change-Id: I1e4f6266ac5e0d23e5272d69b5a102e3364ca7aa
This gets the current connection state of the profile with respect
to the local Bluetooth adapter.
Change-Id: I7cff6c9201d29a8b45413cff7384b7483f21bd5c
There was a bug in the invalidation code that prevented some
animations fropm starting. An INVISIBLE view would mark some dirty
flags then propagate the invaliation up the parent hierarchy. This would
cause a redraw of the hierarchy, but would not include the invisible
view (invisible children do not get drawn). Thus the flags wouldn't get cleared.
Later, an animation to fade the view in (making it VISIBLE on start) would
be started on the view. But the invalidation triggered by that animation would
not propagate because the invisible view would see that it was already
invalidated, and wouldn't send the message along. No invalidation means no drawing,
so the animation wouldn't start because the invalidation didn't make it's way up to the
top and the child's parent did not redraw.
The fix is to noop the invalidate() call for GONE/INVISIBLE views which do not
have animations set on them. Making these views VISIBLE later will trigger
an invalidation, as will starting an animation on them, so the behavior should
not change except for the buggy situation.
Change-Id: I7a26a4bc7823f08fef56e52648e77ca256df6858
This introduces a new facility for code during the boot process
to display messages to the user through a progress dialog. This
is only for use when performing longer-than-usual post-upgrade
operations such as running dexopt on applications or upgrading
databases.
Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
1. The password lock screen is accessible and with this
change the PIN lock screen is accessibile as well.
This is enough to cover the enterprise use case of
imposed lock of the deivce. we will hide the options
for pattern since it is hard for use by a blind person.
We may reconsider this for subsequent releases.
bug:4978246
Change-Id: I069f8ebe1ff7ea1591cab42ea580f00f3d31b2e6
