If you need its functionality for testing:
$ adb shell am start -n com.android.systemui/.Somnambulator
Bug: 7267723
Change-Id: I9e0dd9d020e251d1ced4377329436ea46c3a8af5
The Settings put*() APIs fix up references via the old namespaces,
but the raw insert() interface didn't. Now it does. Also, when
possible we fix up direct query() operations on the old namespace
to point to the correct one. At present that is only done for
query() operations with Uris of the form
content://secure/adb_enabled
There is no rewriting done on queries of the form
content://secure WHERE name='adb_enabled'
since the app-supplied WHERE clause can be arbitrarily complex.
Bug 7267568
Change-Id: I5c8cecbea7f5b1da6247a53b1428d3effb0bbca5
The reason for this is a bit subtle: we want to guarantee that
when a content observer is registered using the public API, it
is *always* bound to the host user's view of the data behind the
observed Uri, never the calling user's. Now, the reason it was
the calling user in the first place is that the Settings provider
(and potentially any singleton provider) needs the observers
underlying Cursors returned from query() to be tied to the caller's
user, not the provider's host user.
In order to accomplish that now that the public-facing behavior is
always tied to the host user, the concrete class that implements
the Cursor type handled by the Settings provider has been extended
with a new hidden API for setting a notification observer tied to
an arbitrary user; and then the provider explicitly downcasts the
query result's Cursor to that class in order to register the
notification observer. We can do this safely because this is platform
code; if we change the way that these underlying cursors are constructed,
we can just fix this point of call to follow along. If they get out
of sync in the future, the Settings provider will scream bloody
murder in the log and throw a crashing exception.
Bug 7231549
Change-Id: I0aaceebb8b4108c56f8b9964ca7f9e698ddd91c8
Ringer mode setting was moved from System to Global group
but a db upgrade cleanup step was missing.
Bug 7128886.
Change-Id: Id20994fe74575afa2b68154a620aa3c8807e8304
Bug 7150006
Single finger notification expansion.
If you liked these changes...
Change Ie4e79aa5
Change I8a6f8606
Change I824937e9
Change I957b6d50
You'll love this one!
Conflicts:
packages/SystemUI/res/values/config.xml
packages/SystemUI/res/values/dimens.xml
Fix notification gestures.
Broken by recent changes to ScaleGestureDetector, which we
were using incorrectly.
Conflicts:
packages/SystemUI/res/values/config.xml
packages/SystemUI/res/values/dimens.xml
Change-Id: Ie534c5b2d320296531a36a9b1c22f9dd6901e0b8
You must move the panel at least 20dp overall, or at a speed
of 150dp/sec or more (actually quite easy; most normal
flings are 500dp/s or more) for it to be considered a fling.
Bug: 7179458
Change-Id: Ic1f4edc641cd2aa1cde89b2ee02eefdf5a0cc044
- You can start pulling down another panel before the first
one has fully expanded. (Protip: tap many times on the
statusbar to invoke Schwarzenegger Mode.)
- When starting to pull down a panel, other panels are
immediately sent running (rather than placing them on a
literal seesaw).
- Rubberbanding is a little less aggressive: if it looks
like you're moving your finger upward, we'll just close
the panel outright rather than sticking to the bottom of
the visible content. (tablets only)
- This has some implications for the background fade; you'll
see a brief increase in brightness as you swap panels
because the fade fraction is based on the sum of all the
panels' fractional visibility. At times there will not be
enough "panel" visible, in the aggregate, to justify
holding the fade steady.
Bug: 7260868 // can't pull down panel, possibly fixed
Bug: 7204435 // double-swipe for QS
Bug: 7179458 // fling & rubberbanding heuristics
Bug: 7172453 // collapse other panels when dragging a new one
Bug: 7221970 // grabbing a flying panel causes twitching
Change-Id: Iad7c1f92c4edab9102cdda45605ef0ead4cc16c5
