To better control ripple and turbulence noise, a new flag is added.
Bug: 249536060
Test: MediaControlPanelTest
Change-Id: I95c3cc2121b1c7f4bd6ca106bd4f6304cbbb01e1
Previously, the model's state was being updated every time mIsEnabled changed, causing either a resource load or resource release depending on the direction of the change. However, mIsEnabled changes every time EdgeBackGestureHandler attaches or detaches, which happens every time a foldable folds or unfolds. Releasing and reloading the model's resources every fold/unfold is needless and wasteful.
Now, the model resources only load when the process starts or when the user enables Gesture Navigation mode. The model resources only get released when the user disabled Gesture Navigation mode.
This change is safe because no new behavior is added.
There is also an additional safety check added: now, if the model is currently loading, it will not be asked to predict.
Fix: 214938229
Test: manual
Change-Id: I6127b4a5acfa57e9faa0966d021bd951cf2d7bee
Seems like we can get into a state where the sim pin view does not have
an initial message and is getting an exception because 0 is not a valid
resource id. Moving the getInitialMessageResId to the parent of the sim
pin view controller.
Fixes: 261941458
Test: Add unit test. Open sim pin view.
Change-Id: Ia2782c7c8acd0775bd2fb1cf9774f477264cf899
If the flag for customizable lock screen quick affordances is
enabled, the required geture to activate a lock screen quick affordance
is now a standard long press instead of a click.
Fix: 254857466
Test: long-pressing the button causes it to scale-animate and then
activate. A "tap" sound plays when it activates. Moving the finger too
far off the touch target while holding down cancels the gesture.
Releasing the finger too quickly causes the view to shake-animate and a
corrective message to appear in the indication area.
Change-Id: I130169d6dcdb6779bb914b0a3c0d3b0fc522567d
Adds code on the system UI side that renders a preview of the lock
screen. This is done through the content provider, which receives a
handle to a SurfaceView from wallpaper picker, where the UI is actually
shown to the user.
There are several changes here, following the path of the code, they
are:
1. KeyguardQuickAffordanceProvider can handle the "call" from wallpaper
picker and delegates the rendering to the preview system
2. The preview system starts with KeyguardRemotePreviewManager which is
responsible for driving the lifecycle of the rendering as the
connection to the remote SurfaceView is established or torn down
3. The preview system continues with the KeyguardPreviewRenderer which
builds the view hierarchy and hooks up each view to its appropriate
view-binder or view-controller
4. For quick affordances, we are making a couple of minor changes to the
view-binder, view-model, and interactor to allow for them to run in
"preview" mode where different rules apply: no clicks allowed, the
affordances are ever-visible (as opposed to only when the lock screen
is shown), etc.
Bug: 261362750
Test: unit tests created/updated, manually verified in the shortcuts
settings screen
Change-Id: I5d1c51dacbedf0a7a1fb3ec742244141a2fe8a32
Some padding was removed in ag/20643913 so the bouncer seems to be
offset a little bit and looks strange. Adding this padding back.
Fixes: 260477609
Test: Open bouncer.
Change-Id: Ib93188b6e87ac1324d59869b06a155c9e445f963
It sets the flag on for increasing the penalty on media falsing
Bug: 259445895
Test: manual - tests are in ag/20455102
Change-Id: I443a366acc7bc110f1e2baf5e6bd742898743378
If the double tap power button gesture is detected while the device is
unlocked, we are using a different code path to start the camera app. In
this code path, we were not actually attaching the source to identify
ourselves as the double tap power button System UI gesture.
This CL updates that path to include the source.
Bug: 262193771
Test: manually verified that we are attaching the extra (though it
doesn't fix the camera bug)
Change-Id: If5844a2ceb165303240265f0c0955f94fc8076a0
This allows processes that do not utilize the SysUI Dagger graph to
avoid having to subclass and instantiate it.
This change also makes the Screenshot cross-profile service take
advantage of this change.
Test: Turn on "Enable RequestProcessor" and "Enable Work Profile
Screenshots Policy" SysUI flags
Test: Take a screenshot of a work profile app
Test: Observe successful work profile screenshot
BUG: 259469497
Change-Id: I1a8c62ba079d90e575cab2a0e14b3f1466e1952c
The bug is about keyguard status bar and status bar being visible at the same time.
Bug doesn't have any new reports in the last 6-7 weeks so these bug-specific logs are no longer needed.
Bug: 237743330
Test: just removing logs
Change-Id: Ic25bbf46d23b154ba56b121dd0306c3cb83da032
This is follow-up to ag/20411848 which fixed scrims showing up when going from expanded shade to keyguard with power double press.
The original CL missed the case of going to keyguard from SHADE_LOCKED state, so it's added here.
Fixes: 251025114
Test: NotificationPanelViewControllerTest
Change-Id: I95283f64bc43f2dc45a58cb4ff4b9fff5ffd1799
This CL re-writes almost everything about how chipbar works,
unfortunately. I realized there were some bugs in the implementation of
handling multiple chipbars at once, and with the addition of priorities
it made it easier to just start from scratch.
Fixes: 261895766
Fixes: 258019006
Test: ttt chipbar then active unlock chipbar -> active unlock chipbar
shown, ttt chipbar re-shows after the active unlock chipbar disappears
Test: active unlock chipbar then ttt chipbar -> active unlock chipbar
still displayed, ttt chipbar shows up after active unlock disappears
Test: ttt flow from started -> triggered -> succeeded
Test: ttt flow works for multiple IDs
Test: ttt chipbar, then active unlock chipbar, then ttt chipbar with
updated info -> when active unlock chipbar disappears, ttt chipbar with
updated info *and updated timeout* is displayed
Test: atest TemporaryViewDisplayControllerTest
Change-Id: I7f077f7e05834c34cfd05ab72e307d2798a18ddf
Else, the UDFPS fingerDown state can be stale
and cause downstream bugs (ie: remaining in the screen on state
instead of transitioninf back to AoD since the DozeMachine
thinks that the user is still interacting with UDFPS).
Test: manually fail UDFPS from AoD, observe device goes back
into DOZE_AOD 5+ seconds after the fingerprint failure
Test: atest UdfpsControllerTest
Fixes: 261758656
Change-Id: Ied60ead5aae4f00e57d0e9457581bf3796392aca
And from the AOD_PAUSING state.
So if users immediately attempt UDFPS right after
the prox sensor has become unblocked, the
authentication will still go through rather than
being dropped. The UDFPS longpress gesture is also
prox gated (by the sensor), so this is a safe change.
Test: programmatically set DOZE_AOD_PAUSED and see that UDFPS
longpress can still be triggered when prox isn't blocked
Test: atest DozeTriggersTest
Fixes: 244011650
Change-Id: Ic4f7956cb6082bec5c55d5177c8546e12b969378
Bug: 238425913
Test: manual: Verify wifi icon updates to be the same color as all the
other status bar icons (e.g. light vs dark mode)
Test: atest MobileStatusBarWifiViewTest
Change-Id: I132cc62a8f8b69fc750c5f0b34750f5a1151be76
Adding the following:
<proxSensor/>
to the DDC, will stop any fallback from being used, and allow the usage
of no sensor to be used for that display. This is useful for when a
display has no sensor and the fallback should not be used. If this is
not added to the ddc, the fallback will still only occur if the display
is the default display.
Bug: 202604469
Test: dumpsys display | grep mProximitySensor
Test: com.android.server.display
Change-Id: I018b334a443f6b9a36aaeca70c673bac86446402
Merged-In: I8508a191b7c7c5990929e4d020ffd144c7faeef7
generateCrop does some IO operations and could be responsible for some lock contention; it is useful to know how long it takes to run.
Test: treehugger
Bug: 247076432
Change-Id: I710641d3b15eeca7a34cf6a6b508e769b6604532
The new Engine of ImageWallpaper, a CanvasEngine, was enabled in droidFood under a flag. It has been tested for several weeks and is ready to be enabled by default, wihtout any flag.
The ImageWallpaperTest has been slightly refactored to fix all warnings and reintroduce two GL tests that were ignored.
A very small fix was added in ImageWallpaper.java: if the bitmap fails to load (which should not happen) for another user than USER_SYSTEM, it will be reset to default for this user and not for USER_SYSTEM.
Test: atest ImageWallpaperTest
Test: atest WallpaperLocalColorExtractorTest
Fixes: 243768810
Bug: 243402530
Bug: 254512923
Change-Id: I0bfbe9b6aee7a4da349b412399196504511b69f0
Merged-In: I0bfbe9b6aee7a4da349b412399196504511b69f0
