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
This was already working fine for the area of the panel
below the ScrollView, but intuitively it seems that dragging
in the unused portion of a partially-filled row would behave
the same way. Because it's part of the scrolling content,
though, drags in that region are (correctly) interpreted by
the ScrollView as scrolling requests.
The new QuickSettingsScrollView works around this by
ignoring touch events if its contents are too small to be
scrolled. So in the common case (QS tiles on a phone) you
will be able to drag in any empty area and have your taps
interpreted by the PanelView (which hands them off to the
handle to collapse the view).
We don't handle drags in empty areas when there are too many
tiles to show on-screen, and really, it's impossible to do
so: this gesture should then definitely be interpreted as a
scroll.
Bug: 7203193
Change-Id: I4cfcb029481a88d3604c7105185e8bcb7dbde8a5
USB settings are now isolated per-user, since they revolve around
installed packages. User-specific settings are returned based on
calling user, or referenced by UserHandle passed to SystemUI. Each
settings Context is wrapped as a specific user, so all broadcasts are
sent correctly. Upgrades any existing USB settings to OWNER.
Physical events, like new devices, are routed to the currently active
user. Switch to using AtomicFile when persisting settings.
Bug: 7244888
Change-Id: I8a723ad3d55ac1bff99276c5f3a3f5e8f013432f
1) Properly handle restores of settings elements that have been migrated
to the new global namespace
1) Back up and restore the new global settings namespace
3) Make sure to back up / restore the global entity
ENABLE_ACCESSIBILITY_GLOBAL_GESTURE_ENABLED
Bug 7249405
Change-Id: Ibfa9930ea4d0e16c7635697e8c631b155e4c0cb2
