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
Testing to verify correct mobile icon in edge cases such as no sim,
or no mobile data feature. Tests for updating the network name.
Change-Id: I0e4114d0c1e4109d4b2aae761181bedb841fe8b6
Expand SignalClusterView and NetworkController to handle multiple
SIMs. It does this by creating multiple MobileSignalControllers
for each of the active subscriptions on the device.
Also some minor changes for followup on the NetworkController
refactor that went in before this.
Bug: 18222975
Change-Id: Ic7a857cfc5cadb46d51bb9ded0df8187eea799f7
Minimal changes to interface/callbacks, all of the changes are
internal and prepare for MSIM.
Separate out AccessPoint and MobileData from the NetworkController
interface to give some space.
A SignalController class has been created as a base for both
WifiSignalController and MobileSignalController, both of which
internally handle the state of their respective connectivity and
only reach up into the NetworkControllerImpl when completely
necessary (such as for combined carrier label).
Bug: 18222975
Change-Id: I75b954bbece187371cdb8571dd8420e7d2cad978
Now you can run the tests without getting the blank broken sysui.
The tests instrument themselves so they include all of the source
they need to run rather than piggybacking on the sysui process.
A couple of changes were needed for this. The xml files cannot
reference com.android.systemui, instead they must use res-auto.
The tests can no longer make privileged calls, so some restructuring
to avoid those calls was needed.
Bug: 18222975
Change-Id: I67b794af854f1420583d48960bd6e52ca753b56d
Add some tests that verify for varios wifi, and mobile signal
strengths and types that the correct icons are sent out in the
callbacks. Still in prep for MSIM refactoring.
Bug: 18222975
Change-Id: I477bf9a90e5c32fb1cba9c150ec6314f4b707108
This will allow us to add some test cases to verify that under
certain phone/signal conditions we get out the icons we expect.
This will let us break less things when refactoring for MSIM.
Bug: 18222975
Change-Id: I7bd3e66e7de6b30fede72e40fb6aa37dd523336c
