When a BroadcastReceiver is registered with UserHandle.CURRENT, the
current user should be obtained. This has to be cached in order to not
call ActivityManager every time.
As it is done in the initializer the initial value caching will happen
before any other BroadcastReceiver is actually registered. The caching
and updating is all done in the background thread.
Also, remove unnecessary dependency.
Test: manual
Test: atest BroadcastDispatcher
Fixes: 158298581
Change-Id: Idfd2dc65f9079c57e971250aa7b0aef222da5af5
registerReceiver takes an optional Executor parameter. The old
registerReceiver that takes a Handler has been renamed and @Deprecated
Test: SystemUITests
Change-Id: I43b97f720b2b153d1019ed3cf19e1533558e380f
Also, remove the "removeAll" method. It was going
to cause more harm than good.
Bug: 145135056
Test: n/a
Change-Id: I39ef8c4aa656e6a9d7ef15e8dd528960e07a406a
This CL migrates most of the remaining classes to use
BroadcastDispatcher. Some classes left are Views or created before the
BroadcastDispatcher can be injected.
Adds docs for instructions on using the BroadcastDispatcher.
Using the broadcast dispatcher, the time system_server spends
dispatching common intents to SystemUI like SCREEN_OFF and SCREEN_ON can
be seen to decrease from ~70-150ms (in a Q build) to ~2-4ms.
Additionally, once a broadcast is received by the dispatcher, time
until it is fully dispatched inside SystemUI is not impacted greatly.
Most broadcasts are fully dispatched after ~20ms with a few of them
taking ~100ms.
Test: atest SystemUITests no regressions
Test: build and boot
Test: tried some random broadcasts and they are properly dispatched
Test: BroadcastDispatch dump
Test: adb shell dumpsys activity broadcasts
Bug: 134566046
Change-Id: I26a592be66b053f25669b5481b58bf7f07bfd0da
This is a significant change that allows Services to have their
constructed injected into.
This change includes DozeService as an example, injecting the
FalsingManager into its constructor.
Bug: 136279712
Test: atest SystemUITests
Change-Id: Ib58f8763c996fbc2aea07ead56493d2d9e936f5b
This also moves the end action methods into the controller, which is a more logical place for it. That way, PhysicsAnimationLayout only has one public method (setActiveController). This sets us up better for future abstractions that don't rely on a custom view at all.
(also updates the docs for these changes and several recent ones)
Test: atest SystemUITests
Bug: 134077101
Change-Id: I6fcc14587b07f14371fa75fbbe0cc31353aa5c0b
See the updated docs for an explanation and example usages. The number of overloaded animateValueForChild methods, and end listener/property setting boilerplate in the controllers were getting annoying, and this is a familiar pattern similar to ViewPropertyAnimator.
Test: atest SystemUITests, also manually tested to ensure no regressions.
Change-Id: Ibca870efda447d79b795c846408f1f6864ce3aa9
This required adding the setChildVisibility method to controllers, to allow them to animate in/out views that pass the max rendered child threshold. This was not previously relevant since in the bubble stack, you can't really see the views when they're set to VISIBLE/GONE.
Also, renamed onChildToBeRemoved to onChildRemoved since that's more accurate given the move to transient views.
Test: atest SystemUITests
Change-Id: I291ff8f6257ba54e0688c1062bbd673e0c7bdb5c
See go/bubble-stack-design for a high level overview of these changes. This is a large CL, but required in order to allow continued development and team testing without breaking functionality over the course of multiple CL submissions.
To integrate the new animations, the following changes have been made to existing code:
* (BubbleStackView) The bubble container (and thus, the stack view) are MATCH_PARENT to allow the bubbles to independently translate anywhere on the screen.
* (BubbleStackView) Start position is set by the stack controller, not BubbleStackView.
* (BubbleStackView) Expand positon is set by the expansion controller, not BubbleStackView.
* (BubbleStackView/BubbleTouchHandler) Added the methods onDragStart/onDragged/onDragFinish, and onBubbleDragStart/onBubbleDragged/onBubbleDragFinish, for cleaner dispatch of touch events to the appropriate animation controller.
* (BubbleStackView/BubbleController) The stack view's getBoundsOnScreen returns the first bubble's bounds, if the stack is not expanded.
* (BubbleStackView) applyCurrentState no longer manages translation of bubbles, or the expanded view, these are controlled by animation.
* (BubbleMovementHelper) Deleted, no longer needed.
* (Everywhere) Changed uses of Point to PointF, since translation values are floats anyway.
Known issues to be fixed in subsequent, far smaller CLs:
* (b/123022862) Bubble dragging out/dismissing is not animated, and the bubbles can be deposited anywhere. Tap outside the stack to collapse them back to normal.
* (b/123023502) New bubbles added while the stack is expanded are not positioned properly.
* (b/123022982) Expanded view arrow is sometimes in the wrong position.
* (b/123023410) If the stack is expanded while animating, it collapses to its original position even if not along the edge of the screen.
* (b/123023904) The expanded view doesn't animate out, it disappears instantly.
* (b/123026584) Bounds in landscape are a bit wonky.
Bug: 111236845
Test: atest SystemUITests
Test: physics-animation-testing.md
Change-Id: Icaca09e5db89c635c9bb7ca82d7d2714362e344e
Create DependencyBinder which is abstract and can tell dagger how
to convert directly between interfaces and implementations without
requiring code for it.
Test: compile (which runs dagger)
Change-Id: I7013ee12d37172441e2c70cf2fe36f707975c821
Convert NavigationBarFragment as a proof of concept and remove all
references to Dependency from NavigationBarFragment.
Test: atest SystemUITests
Change-Id: I0cdb5bc6ac455fce91e67b9e449cb7b78b1da9a4
Early days as we start migration, so lots of duplication between
Dependency and dagger2, but can be removed when migration is done.
Test: existing tests.
Change-Id: I00c3da6ebbd46a26e512d8a7aa1e2b828e08f33f
++1dp for Data saver and Hotspot
--1dp for Total silence
>>1dp for Battery lightning bolt
Also implemented keyword "powersave" for `dispatchDemoCommand()` in
BatteryControllerImpl
Test: visual
Bug: 37013523
Change-Id: I027fd18aadeef5c49826c37db9f681c14175a3aa
