- 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
If the current user has not yet made it through the setup wizard,
disable the quick settings panel entirely.
Use Settings.Secure.USER_SETUP_COMPLETE as the signal. This is a
per-user setting, so be careful to observe only on the current user's
behalf.
Bug:6712493
Change-Id: I3076a8a550165a9eeccf7fb129d470ef4ddeaed4
The handle (which is now being drawn by the window and not by itself)
was floating over it.
Bug: 7267529
Change-Id: Ia8902f64ac81616c640bc42400272933063852f4
By default it will still go to Date/Time Settings (see
change Ib430f0c5) but 3Ps can hook it for other useful
things.
Bug: 7264806
Change-Id: Ic561dbeb5cc0738372c079b3eb52749c44b3cf0d
This takes the easy way around notifying the correct users
about GPS state transitions by notifying ALL the users(!).
I've also laid groundwork for proper multiuser support in
LocationManager and did a tiny bit of cleanup in
GpsNetInitiatedHandler while I was looking at notifications.
Bug: 7213552
Change-Id: I2d6dc65c459e55d110ac0f5f79ae7a87ad638ede
Issue #7211769: Crash dialog from background user has non-working "report"
The report button now launches the issue reporter for the correct user.
Also for crashes on background users, either disable the report button,
or simply don't show the dialog depending on the build config.
Issue #7244492: Bugreport button in Quick Settings doesn't actually do anything
Now they do.
Issue #7226656: second user seeing primary user's apps
I haven't had any success at reproducing this. I have tried to tighten up
the path where we create the user to ensure nothing could cause the
user's applications to be accessed before the user it fully created and thus
make them installed... but I can't convince myself that is the actual problem.
Also tightened up the user switch code to use forground broadcasts for all
of the updates about the switch (since this is really a foreground operation),
added a facility to have BOOT_COMPELTED broadcasts not get launched for
secondary users and use that on a few key system receivers, fixed some debug
output.
Change-Id: Iadf8f8e4878a86def2e495e9d0dc40c4fb347021
