- Initial changes to show a history view within Overview (behind tuner
flag)
- Restoring the task view dim in the stack
Change-Id: I0503d11768736c86f3145942404391dfacd0ddd6
- Removing old broadcasts in favor of direct aidl interface between
system and secondary users. Also moving user specific implementation
into RecentsImpl, allowing Recents to handle proxying between users.
Change-Id: I4bd5ef1d1ee47309b7c754f50a5e8b2e2aab988f
Derive the app labels in a right way.
Not forgetting to get accessibility labels for newly dragged-in apps.
The change adds inefficiency with apps getting repeatedly resolved several times,
which is OK for a prototype, but I have plans to optimize this.
Bug: 20024603
Change-Id: I755d38de34c016d0ec31ecc617f7accfd876693b
2 copies of NavigationBarApps (for vertical and for horizontal orientation) share a single
static copy of NavigationBarsAppsModel.
If the active orientation's view made changes, they are not conveyed
to the inactive one, and if we rotate to show the other view, it will show
stale data.
The fix introduces an event generated by the model, which allows the invisible
shelf to get updated when the visible one makes changes.
Bug: 20024603
Change-Id: I0d749dbac700857b081bce8a5a232f24ba271b25
The existing Shelf DND crashes if profile or app removal happens
while dragging from outside of shelf. This is because in this case
shelf temporary adds a null placeholder enter to the model, and
doesn’t check for nulls in user-removed and app-removed callbacks.
Adding checking for nulls.
In addition, since adding nulls muds the contract between the
shelf view and its model, I’m getting rid of adding null entries
to the model. Nulls are used on the view side, but never leak to
the model.
Because of that, the state of the view (which may have nulls) and the
mode may not match each other during the drag, I introduce storing
app data in views, as a tag. Null tag means a drag placeholder.
Now that the state of the model doesn’t always follow the state
of the shelf via add/remove operations, it makes sense to introduce
set-all/get-all calls in the model, instead of add/remove/get(i)
calls.
Again, all these changes, even though relatively massive, add clarity
into the view/model contract by eliminating strange states where the
model can have nulls in certain positions.
Also fixing a case when removing an app while dragging it happily
creates an icon.
Bug: 20024603
Change-Id: Ie4e617ccf9278708d64ee100265a4858d1227aed
Fixing an issue when installed apps in Guest user were treated incorrectly.
This happened because we used APIs using the systemui current user (0),
not the app's user.
Also, switching AppInfo from user's serial numbers to UserHandle. Earlier,
I declared that user ids (not serials) is the "lingua franca" between different classes,
so, this move is along these lines. In addition, this is simply more convenient.
Bug: 20024603
Change-Id: I749d900aa17083a41e4215c6587ae5ccaa31f5eb
Added a new component which tracks touch and sensor events and
also events like showing the bouncer tapping a notification and
others. The collection is enabled when the screen is turned on and
is disabled after the phone is unlocked. The data is saved in a
protobuf file in internal storage in a directory called
"good_touches". There is also an option to collect events which
end with the screen turning off. These are saved in the
"bad_touches" file. Everything is hidden behind the
ENABLE_ANALYTICS flag which is set by default to false and can be
turned on only if Build.IS_DEBUGGABLE is true. Also
behind the ENFORCE_BOUNCER flag the class shows the bouncer before
expanding a notification, showing quick settings or launching an
affordance from one of the bottom corners.
Change-Id: Iaeae0fb7a0d9c707daf7a270201fa5b1cd84c74a
When loading apps from prefs, detecting apps that cannot
be launched (for example, were uninstalled) and not adding them
to the shelf.
Also watching for apps that become unlauncheable while the shelf
is shown, and removing them as it happens.
Bug: 22694757
Change-Id: Iab9494f0480e9bf4438b72a94041002be010334f
These users required special treatment and complicated code development.
Now simply always using the actual value.
Bug: 22609426
Change-Id: Ife44de442de455248ae7a8ebf8655ddbc4c289d4
All users are stored in same SharedPreferences file. User serial number is included in the preference key.
Prefs for deleted users get cleaned up upon switching to a new user.
Bug: 22853745, 22609426
Change-Id: I7f774483bc660ed5b1e8115da9b468a291488723
We need this to differentiate between starting apps for the primary and
managed users.
This in particular solves the issue when apps were executed as Owner
while we are in Guest account (see the bug).
Valid user ids for a shelf app are either primary or a managed (work)
user for the profile.
Launcher allows mixing apps for for primary and the managed users on
its home screen. Apps for the managed user are marked with a suitcase
badge.
Launcher includes a user id in the drag and drop info that it sends to
SystemUI, as “profile” extra added to the intent.
Shelf now stores this user id and uses it to start apps.
Bug: 22609426
Change-Id: Id4c6c1ac8617a83f4484f78db578955699d1a888
Need to look at a ServiceState to determine if we are actually in
a emergency only state.
Bug: 22619451
Change-Id: I06a2a6fab85ed2ce41d8f7cbb98a1f169ec61b33
The icon list is stored in SharedPreferences under
com.android.systemui.navbarapps.
* Introduced a separate data model class for the navbar app list
* All icons are now loaded from PackageManager, not from LauncherApps
* Added test for NavigationBarAppsModel
Bug: 20024603
Change-Id: I0eb3b9e927d3311818096cfd484d6f5a81acbbc7
- Do some cleanup so that things are more testable
- Test emergency callback since its possible
- Fix emergency callback in no sims case
Bug: 16218652
Change-Id: Ic859eff732cc11c5ae8aa6ced3584905bbe215c7
Taking connect/disconnect events into accounts results in frequent jank
while trying to show the icon.
Bug: 21504588
Change-Id: If271980cc46cfc20f80083de17a4b57c42439069
Now that AnimatedVectorDrawables can use themed animations, SysUI no longer
needs to track separate AVDs for the carrier network change icons.
Bug: 21118142
Change-Id: Ifb6d7b5e7e3de85c10bc13183b4142fd2e6714b6
Show it in the status bar when its a default network, but always show
it in QS when its connected, so that users can know its connected.
Also fix the tests.
Bug: 18776546
Change-Id: I553588fc6850b0c2ef6e6015b313222bf4c786e7
Also do some refactoring to avoid having to sets of callback interfaces
with 75% of the same data.
Bug: 19520495
Change-Id: Ife1c71174c0d6a21f924f7de3cb2f97a04c3d5a1
- Includes unit tests for verifying mobile data indicators.
- Found one bug where dark mode icon wasn't showing properly when
different from light mode icon.
- Comment out failing test
NetworkControllerSignalTest#testSetCurrentSubscriptions
Bug: 20288155
Change-Id: Ib3c9ba224c4187cab35d6bfa68f6bd4c489cf98e
- Listen for new PhoneStateListener.CARRIER_NETWORK_CHANGE events.
- Show/hide a new unique animated icon in status bar and quick settings during
Carrier Network Change events if we are instructed by PhoneStateListener
and it's during a period without connectivity.
- ObjectAnimator doesn't let you animate colors between themed colors, so
there's quite a bit of boilerplate duplication in the animation xml.
- Add a new demo mode command to toggle it on/off.
Change-Id: Ic5bb2aa7444303c6b7f2456526a9c25325c6e1f4
Also add a test for it, because despite the comment next to it, I
try to set it to an invalid value...
Bug: 19201696
Change-Id: I3c12c871c73ad5ab15f39a6b91b29c71101adad6
The public API of HeadsUpNotificaitonView was not well suited to the
new requirements, so it changed slightly.
Old API:
- showNotification: show or update a notification
- clear: close the window and forget the notification
- release: send the notification to the shade and forget about it.
- releaseAndClose: release and close the window
- dismiss: clear the notification if clearable, or release it
New API:
- showNotification: show a new notification
- updateNotification: show a new version of the same notification
- removeNotification: respond to a cancel
- release: send the notification to the shade at some point
- releaseImmediately: send the notification to the shade right now
The new API makes updating vs. posting and removing vs. releasing more explicit.
There is a new internal concept: lingering. The heads up lingers
after an event that would have closed it if the minimum visibility
time has not been satisfied. In the case that the notification was
deleted, the heads up may be visible, but mHeadsUp will be null. In
this case, touches on the notification views are disabled.
More responsibility for control of the heads of policy was moved into
the HeadsUpNotificaitonView class. This should continue on master.
Some changes to support testing.
Added a test to cover all the edge cases for minimum visibility time:
1. extend visibility when canceled too soon
2. extend when updated with a low-priority version, fast update.
3. extend when updated with a low-priority version, slow update.
4. don't extend the visibility in any other case
TODO: Policy parts of HeadsUpNotificationView should be split out
into a separate HeadsUpNotificationPolicy class, and even more of the
policy should be lifted from status bar that new class.
Bug: 17878008
Change-Id: I192419d0685dd022ee7edcd792e346a4f39c6adb
Most were fixed by including the correct subscription id in the
broadcast.
The last was testing based on SIM card state which is not something
the MobileSignalControllers track anymore so I just pulled it out
completely.
Change-Id: Ie52068a3c8f8652f1b0641e6376696aeddda26a2
Also add some more testing for this section of code that manages
when MobileSignalControllers are added/removed to make sure we
are all good.
Bug: 18728593
Change-Id: I9902854c54d2e1deb58b38b7bd97dac1617831c0
We need to remap or recalculate icons after a config change, so
configs based on mccmnc can update properly.
Bug: 18654943
Change-Id: I6a4c1debf9b266d486143b9869abb569bbc31aef
