That way, we don't need to use Resources#getIdentifier
Test: atest QSTileViewImpl TilesStatesTextTest
Test: microbenchmark jank test
Fixes: 191483200
Change-Id: I0d92c6e5b9861e5001df5e2ffb7f80734b2b9ff8
For stock tiles state (filled in subtitle when there is not one set by
the tiles), we specify values for each of the tiles states. That way,
they can be translated with that specific tile name in mind for
grammatical matching.
Custom tiles will use the default.
New stock tiles must add a new array to pass tests.
Test: QSTileViewImplTest TilesStatesTextTest
Fixes: 188163204
Change-Id: Idd4da01994e37cb4778dcdd3080711179cb884c7
This CL collapses the hierarchy QSTileBaseView - QSTileView -
QSTileViewHorizontal into QSTileViewImpl. This can be done because now
there's a single type of view for the tiles. The benefit of this is that
we do not have to hack our way to undo things that are done in parent
classes. As part of this remove a lot of unnecessary files.
As part of this, bring some colors/sizes up to spec and make sure that
the sizes are reloaded in config changes.
Test: manual
Test: atest com.android.systemui.qs
Fixes: 187061459
Bug: 186057842
Change-Id: I63dbe8fa2b44833c11a486e84195e33e170c6f58
Method no longer takes `robustCheck` parameter. Instead,
FalsingManager#isSimpleTap is added for basic checking, and
FalsingManager#isTap does robust checking by default.
FalsingManager#isTap takes an enum value for penalty instead of
a double, making the value more understandable.
Bug: 172655679
Test: atest SystemUITests && manual
Change-Id: Ib4a99f87bcd6acee67a98420f460c98d44fa6360
Process gestures in the FalsingManager as soon as they complete,
instead of waiting for the next gesture to begin.
This provides more accurate and useful feedback about falsing belief.
It means that a falsing "event" will be fired as soon as the indicated
threshold is crossed, instead of on the next, possibly intentional
gesture.
Bug: 184042853
Test: atest SystemUITests && manual
Change-Id: Idd9227de3a03c52dabe31f52dbb45ff890615ded
Using an implicit intent at the moment of picture-taking
usually goes unnoticed. But immediately after installing a
new camera, this behavior becomes incredibly frustrating to
users as they are presented with a puzzling resolver dialog
(or in the case of the secure camera, the authenticator).
And if, at this moment, the user chooses to make one of the
options a default, it's almost impossible to figure out how
to change this setting.
As a result, many OEMs simply hardcode the camera gesture to
launch a specific preinstalled camera, but this is poorly
supported by AOSP, leading to duplicate implementations and
bugs. This patch routes all camera intents in System UI
through a single utility class, creating a convenient spot
to insert a resource that contains the OEM's default
preinstalled camera app.
Note that this does not affect implicit intent resolution in
any way; any app may create a chooser for, e.g.,
MediaStore.INTENT_ACTION_STILL_IMAGE_CAMERA and allow the
user to pick from the available cameras.
Bugreport/dumpsys output to look for:
$ adb shell dumpsys activity service com.android.systemui | grep -C3 'Camera gesture' | tail -3
Camera gesture intents:
Insecure camera: Intent { act=android.media.action.STILL_IMAGE_CAMERA }
Secure camera: Intent { act=android.media.action.STILL_IMAGE_CAMERA_SECURE flg=0x800000 }
Override package: null
Bug: 171807357
Fixes: 154218868
Test: atest SystemUITests
Change-Id: I2c0033e52c8a3963768d29f2e76e555d405aaa7e
This improves mocking it, as the Java code that results in creating the
overloads doesn't need to call context.getMainExecutor or
context.getUser.
As an example, with a mock mDispatcher, calls to
`mDispatcher(receiver, filter)` with some configurations of Mockito
would fail, as the actual Java method would create the default parameters
calling `context.getMainExecutor()` and `context.getUser()`, but `context`
is null in the mock.
Test: atest SystemUITests
Change-Id: Ia97b62134532c60525d1df33023cc2dd99c1f6a8
Allows Toasts that route through SystemUI to be implemented by a
ToastPlugin. This CL also adds the ability for plugins to create a
custom animation for when the toast shows and hides.
Also adds logging for Toasts that get routed through SystemUI. By
default, these logs aren't logged to logcat but can be enabled via adb (see
LogBuffer.kt).
To dump ToastLog:
adb shell dumpsys activity service com.android.systemui/.SystemUIService ToastLog
Bug: 169587378
Test: manually add CustomToastPlugin
Test: atest ToastUITest
Change-Id: I0a0b16fdc2a5ba1908054197f6dc6728f10a0d2e
This simplifies the dagger initilization, removing constructs that
provided no value to the process, but did serve to make the code
more complex to analyze.
Update dagger.md while we're here.
Fixes: 161911916
Test: manual
Change-Id: I84ced47d7cd6ce90664b68339acb7d7db765d56f
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
