Because we need to implement a data layer repository that will access
quick affordance configs, we need the latter to be moved to the data
layer as well (since currently they are in the domain layer and code in
the data layer is not allowed to depend on code in the domain layer).
This CL has no changes, only moves and renames.
Bug: 254858696
Test: All tests still pass. Bottom area affordances still work.
Change-Id: Ibe1f0387886950ef7e9ef11a8716603aa547493e
After much discussion, it became clear that it would be better to move
quic affordance config definitions out of the data layer and into the
domain layer.
This CL does the following:
1. Moves config definitions to the domain layer
2. Moves the "configs" class to the domain layer and renames it to
"registry"
3. Eliminates the quick affordance repository from the data layer,
merging its logic into the observe quick affordance use-case
4. Updates the documentation
Fix: 241681067
Test: Unit tests updated. Manually verified the bottom area quick
affordances still work properly when locked, unlocked, and dozing.
Played with the settings under Display > Lock screen to turn the on and
off.
Change-Id: I4b293eeef02e5546fc834008b096e4a7935657fe
This is a guide for developers for how to add new quick affordance
buttons to the lockscreen.
Bug: 235403546
Test: N/A
Change-Id: Id8417c48732e25331027f11442c16d0220e690c4
Adds a class that handles files access for multiple users. Will work on
integration in follow-up CL.
Test: Add unit tests.
Change-Id: Ia0af0d18970a8376edcccbe0f59e3d21e55c4f42
Following ag/19119857, this existing piece of documentation is updated.
Note that most of the class names and links in the document were
incorrect, probably due to drift between refactors that renamed stuff
(like `StatusBar.java`) and this document.
Where it was possible and sensical, I updated the document. Where it
wasn't, I removed specifics related to class/method names or line
numbers. The general gist of how the double-click on the power button
ends up launching the camera is still correct.
Bug: b/235403546
Test: N/A
Change-Id: I017c2f83ce70545b9044e11ade7e5c15e8ca8a53
This change introduces a new DozeMachine state DOZE_SUSPEND_TRIGGERS
that is equivalent of DOZE but also suspends any triggers that awaken
the device. Entering car mode transitions the state machine to
DOZE_SUSPEND_TRIGGERS and leaving the car mode transitions to either
DOZE or DOZE_AOD depending on whether Always on Display is enabled.
Current behavior when entering car mode:
- DozeService is finished.
- Always on display is turned off
- Tap on screen doesn’t wake up the device
- Lifting device doesn’t wake up the device
- Sending a notification doesn’t wake up the device.
New behavior when entering car mode:
- DozeService is not finished.
- Remaining behavior is the same as DozeTrigger stops listening to all
triggers (sensors, intents, notifications)
Current behavior when exiting car mode:
- DozeService is not running, normal triggers don't wake up the device
New behavior when exiting car mode:
- DozeService is running, normal triggers wake up the device as
expected.
- DozeSuppressor transitions from DOZE_SUSPEND_TRIGGERS to DOZE/DOZE_AOD
Bug: 230968777
Fixes: 230968777
Test: manual
Test: atest com.android.systemui.doze
Change-Id: I5f49bb5700d7ed38763dccc8c5b6438d934c6476
for both Direct USB Access and AoC Offload feature
According to USB audio warning dialog message conditions matrix, add
a UsbAudioWarningDialogMessage to handle the conditions.
Test: manually install NeutronPlayer to test usb audio device
permission warning dialog sentence.
Test: manually modify each audio api condition to test each sentence
correntness.
Test: atest SystemUITests
Change-Id: Ic9731590cb3bad259add1b93b43341af9518e107
Since the new layout is complete and can handle notification action buttons,
we can remove the old one now.
- Deleted layout files (xml and PlayerViewHolder), and moved
PlayerSessionViewHolder into MediaViewHolder
- Removed the flag MEDIA_SESSION_LAYOUT
- Refactored MediaControlPanel to be more readable
Bug: 218875984
Test: atest com.android.systemui.media
Test: atest QSPanelControllerTest QuickQSPanelControllerTest
Change-Id: I37681542dec5cf10ec7346aa9f888f8f890d2c11
Supports fullscreen user switcher launched from QS, and enabled by
config_enableFullscreenUserSwitcher. Allows adding guests, with
support for adding new users coming shortly. First round of work on
this feature.
Bug: 217365397
Test: atest UserSwitcherControllerTest
Change-Id: Ib81f44c9b950830a7d89b95cbaef53b7228ed5a4
* Deprecate getMetricsCategory, as UiEvents just use a string for each
tile.
* Remove all a11y announcements methods. These were not used, as we've
been using stateDescription
Test: atest SystemUITests
Bug: no bug
Change-Id: Id7a53abe59bc2b265f3049e844d9e8d9c4ef1f83
Part 2 of ???. One-handed mode and user-switcher mode will be
mututally exclusive. Encapsulate one-handed logic into a separate
static class. Add logic to decide between implementations. More
support for user-switcher will be coming next.
Bug: 206825213
Test: atest KeyguardSecurityContainerTest
KeyguardSecurityContainerControllerTest
Change-Id: Iba89b62890d6e7e3252505ae38831930484ded3b
Part one of many, to add a multi-user switcher to the bouncer for
supported displays.
This CL:
1. Removes a config that was not-needed, in favor of the
can_use_one_handed_bouncer resource.
2. Adds a new boolean resource to determine when to use the new
bouncer layout with user switcher
Test: atest KeyguardHostViewControllerTest
KeyguardSecurityContainerControllerTest
Bug: 206825213
Change-Id: I18e5e8ef68a57c5c633664062bb2f4fd5d7b778f
1. Move responsibility for the bouncer container to the
NotificationShadeWindowViewController
2. Start very basic keyguard documentation (much more to come)
Bug: 195430376
Test: atest KeyguardBouncerTest StatusBarTest StatusBarKeyguardViewManagerTest
NotificationPanelViewControllerTest
Change-Id: Iba45a9252fd37c00b2023407eb44bd91c44a87ad
Starting soon, one of Context#RECEIVER_NOT_EXPORTED or
Context#RECEIVER_EXPORTED is required when registering broadcasts. This
CL adds an optional argument to BroadcastDispatcher#registerReceiver to
add flags. The default is RECEIVER_EXPORTED, as it's the backwards
compatible behavior.
Note that many actions listened from SystemUI are platform actions and
as such require RECEIVER_EXPORTED.
This CL does not address receivers registered directly with Context.
Test: logs and dumps
Test: atest SystemUITests
Fixes: 198424247
Change-Id: I80d0cee9347c22c4246bd3da8abc9b040d35490a
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
