The connectivity includes the network condition, which is a
magic number that indicates how useful the connection is
(driven by ability to connect to GTalk, and manifested with
a differently-colored signal icon).
Previously we were only updating the icons of the network
type currently in use. Now we tickle all the icons any time
the connectivity changes, to avoid the two icons getting out
of sync (example: on mobile, connection is bad, connect to
wifi, conncetion is good; wifi icon appears and turns blue
but mobile RSSI remains gray).
Bug: 5369405
Change-Id: I78b62084b819c83f83aacc146feeb323c1199dc0
Settings were restore in alphabetical order and capturing dependency
among them required keys to be chosen in such a way that after sorting
they apprear in dependency order. Now settings are exported and restored
in the order they are declared in the arrays of settings to backup.
Hence, the order in this array will capture the dependency order.
bug:5343351
Change-Id: I93a40bcdd194943cd6f85aa18f1557d546e38274
User activity is supposed to immediately revert
HIDE_NAVIGATION, but we were just showing the navigation bar
directly. By routing through the service we'll generate
callbacks for everyone.
At long last, SYSTEM_UI_FLAG_HIDE_NAVIGATION will work like
lights out (now called SYSTEM_UI_FLAG_LOW_PROFILE) which
worked well enough in Honeycomb.
Bug: 5052456
Change-Id: I677f1295e1208c1aec48a4a9c8a6850916688388
-No more blue, black works throughout all screens
-removed blue line from drop down handle because it was very problematic when a user has several notifications in their scrollview combined with the removal of fadingEdge vertical
-title_bar_shadow has an increased height
Change-Id: I8a291039b9c47c32ce289787612b050fd95e1fc4
PhoneWindowManager now takes full responsibility for deciding where the
navigation bar goes. This gets rid of a bunch of race conditions with
determining layout while the nav bar is moving itself at the same time
the window manager is computing a new configuration.
Note that this breaks the "nav bar on left" option. The current nav
bar code could also be cleaned up some more to completely drive its
behavior based on onSizeChanged() happening during relayout.
Change-Id: I1651d74c3464ba0d588aab3049e099c78420146a
We weren't properly applying the disabled flags from one
orientation to the other. This crops up when the lockscreen
changes the flags and forces a reorientation at the same
time; the other orientation can become stale.
Bug: 5312123
Change-Id: I7cbb7bbf69e6d86cb47450bcdfa692a1f766cd5e
Since the confirmation uses the same Activity but different layouts
for the backup vs restore cases, we have to do the title in code.
Along the way, fix the restore layout's padding [the backup layout
was already right].
Fixes bug 5164470
Change-Id: I4d636f666d97fc377e9cf36abf08d1625a05577f
Bug: 5299191
Bug: 5300282
Only send keys when mCode != 0.
Simplified the logic for repeating / non-repeating keys.
Key down / up are always correlated with touch down / up, the
only thing that's special is that we detect long press for
repeating keys and not for others.
Ensure that up or cancel is always sent for every key
that is generated. Previously it was possible for keys to get
stuck down if touch moved out of the button's active area.
Removed the funky HOME long press timer. We don't need it
since we can rely on the long-press flag instead. Since the
system UI is in direct control of key repeating and long-press
behavior for the keys it inject, this eliminates the need for
special hacks to circumvent the timer.
Ensure that the same haptic feedback is provided for all keys,
including the recent apps key. Previously this only worked
because the code was injecting a bogus key with code 0.
Don't generate repeated haptic feedback for virtual keys
even when those keys are injected. This doesn't happen
for virtual keys synthesized by the InputReader because it
never injects repeats itself (the InputDispatcher synthesizes
them), but it is an issue for the KeyButtonView.
Change-Id: I8b3615dde738af28e76898d161d6ce9a883b59ec
We were carefully tracking the vertical offset between the view
origin and the user's incident touch, but not actually
including it when performing a fling. (This might have
worked at one point but been later buried under some
refactoring rubble.)
Bug: 5210198
Change-Id: I97ae883491a5dedf1b48683441096fe9938d118f
