Targeted effect:
* Immediate visual response on touch down at
sufficiently visible radius for variable finger sizes.
* Then decelerate radius expansion to convey tension / elicit
force and constrain at limited max radius past first stage.
* Bump values on non-AOD surface to improve visibility with
more variable backgrounds.
Test: `adb shell cmd statusbar auth-ripple dwell` expands ripple (but
doesn't animate the retract)
Test: manual, atest SystemUITests
Bug: 198864174
Change-Id: I1fb2e456e89a824b1b749150e3d82c6bc3223f47
- mAnimatedToSleep is true for the duration of the animation to sleep,
but the last nav visibility is incorrect if it doesn't account for
the last animated state, which results in the showing the bar to be
ignored.
Bug: 199536651
Test: atest StatusBarKeyguardViewManagerTest
Test: Enable aod, power off, power on before it fully dozes
Change-Id: I6d3f7f92be567bb561f8cfc62a367c97b00c799d
During high speed recording mode, it was observed that there was a
memory leak due to too many nodes at mPendingFrameNumbersWithOtherType
list. After ag/1962479 added batching for HFR it only updates the
FrameNumberTracker every 4 or 8 frames during high speed recording. This
change fixes that by updating every frame. A map is used to store
requestIds which have batchOutput. For every such requests we update
each frame in the batch in a for loop.
bug: 194618660
Test: 1. Did validity check with the change. Now frameNumber is incremented
by 1 instead of every 4 or 8 in FrameNumberTracker.
2. The mPendingFrameNumbersWithOtherType for otherType is empty during
HFR recording.
3. Verified using other modes of camera and did not observe any
crashes.
4. CTS tests Pass.
Change-Id: I2638e6663e7b70e4ef7a29dfeb27d423c9c7137d
(cherry picked from commit 236ed73e26)
As there isn't an atomic operation to freeze the main thread and binder
threads altogether, it's possible the main thread initiates a new binder
transaction while the binder threads are already frozen. This race issue
will result in failed binder transaction and unexpectedly kill the app.
Fix it by rescheduling the ongoing freezing opeartion if there's already
an outstanding binder trasaction or new pending binder transactions. At
the same time, treat the REPLY transactions of those pending ones the
same way as an oneway transaction so that it can successfully reach the
frozen process, preventing it from being killed.
Bug: 198493121
Test: app launch/foreground/background stress test
Change-Id: I1009fa33edbd2b1db14cf51b598f5869d41ee6b6
We don't want to change display states while the user
is interacting with the UDFPS sensor or else we'll
lose the touch and cut fp authentication short.
Test: atest DozeScreenSTateTest
Bug: 198710028
Change-Id: I3a8168e6f1970c36717e0a7a223bcc74c3ec5600
All the dimensions are in pixel, not dp. The conversion from complex
value to pixel is done in AppWidgetProviderInfo#updateDimensions.
Fix: 199524613
Test: N/A
Change-Id: Ifdc90e7338ade8494d90e567fc95500b650c4ebb
WindowContext relies on WindowTokenClient#onConfigurationChanged after
calling WMS#attachWindowContextToDisplayArea.
However, it took some time to wait for onConfigurationChanged callback
from the server side so that we may get a stale value right after
creating WindowContext.
This confuses developers especially when the foreground activity is in
size compat mode or freeform because the process config is overridden
by activity's config.
This CL makes #attachWindowContextToDisplayArea return DA's configuration
and applies to WindowContext direcly.
It also benefits WindowProviderService because it can obtain DA's
configuration before onCreate() based on [1] and this CL.
Bug: 190019118
Bug: 190745506
Bug: 198298520
Test: manual - 1. launch an Activity in size compat mode
2. create a WindowContext and verify if WindowMetrics
matches DA bounds.
Test: atest WindowContextTest WindowContextTests
Test: atest WindowContextControllerTest ContextGetDisplayTest
[1]: dd4a748af0
Change-Id: I8dd3987b731662502bc01e9d2ed67e718ada5f46
When calls are performed by a secondary user, the attribution is to UID
1000, so they don't match the current user. However, as they are marked
with isPhoneCall, show them anyway.
Test: atest PrivacyDialogControllerTest (fails without fix)
Fixes: 198552515
Change-Id: I11682eceb578ab3b9bf1b2573294af8ca418e6e2
So that the "End Session" affordance
looks like a button that's tappable
Test: manual, go/testdpc
Fixes: 183708476
Change-Id: Ic09f1dfe741b77567b0b8eaaef7aa3405babe65a
Sometimes see temporary black wallpaper after setting a new image
wallpaper because of:
- decode bitmap twice, results in long latency until drawing.
- the set wallpaper apis didn't sync with wallpaper rendering well.
Solutions:
- Only decode bitmap when necessary.
- Make set wallpaper apis wait for image wallpaper rendering finished.
Bug: 194080642
Test: see b/194080642#comment3
Test: atest WallpaperManagerServiceTests --iterations 50
Test: atest SystemUITests
Change-Id: I369eff5195571161cf286b3ec97175481b02eed7
The timeout in call forwarding is only valid for CF_REASON_NO_REPLY
reason, so only check if reason is CF_REASON_NO_REPLY
Bug: 194112447
Test: enable/disable call forwarding
Change-Id: I290d5fa64f0a32ddcaf1f16c51b99f52e8e38913
This CL aims to optimize the previous CL[1] to schedule removing
tasksnapshot after a fixed timeout according the tasksnapshot:
- With IME snapshot: 350ms
- Without IME snapshot: 100ms
As the previous approach has some cons espically when the tasksnapshot
has IME shown:
1) It lacks a signal or callback to notify WmShell to dismiss
tasksnapshot when IME is actually drawn on the task and always
dismissed after the timeout.
2) The timing to schedule tasksnapsit removal is when
ActivityRecord#onWindowFirstDrawn, which is much eariler than the
window focused (about 100-150ms), and it may easier to see flickering
when the task is showing IME.
The reason is that IME is drawn after window focused and started input
connection. Also, starts from R, IME insets visiblity
is handled by the app's UI thread, so if the schedule removal timing
been triggered too early and if IME / App takes more time to handle IME
surface layout, then user might aware the app task flickering when
tasksnapshot dismissed, since IME is not yet be drawn and then it
show up again when the next layout finished.
In this CL, we made the following changes to improve the above cons
- Postpone the schedule removing tasksnapshot (with IME) timing to
after the app task has focused.
- Modify the tasksnapshot removal timeout (with IME) from 350ms to
450ms (with renaming to MAX_DELAY_REMOVAL_TIME_IME_VISIBLE),
in case some edge cases may take longer time to process IME layout.
- add ITaskOrganizer#onImeDrawnOnTask(taskId) to notify the shell
task organizer to properly remove the tasksnapshot without waiting
until the max timeout.
[1]: I7865e17b57961e12a0cdcf068e412195123a6ec7
Fix: 192065018
Test: ateset StartingSurfaceDrawerTests#\
testRemoveTaskSnapshotWithImeSurfaceWhenOnImeDrawn
Test: manual tests by
1) launching Android Message with focusing an editor
2) swiping out to home and launch another apps (e.g. chrome)
3) swiping up to overview, tapping Android Message task
4) verify if IME is flickering after switched back.
Change-Id: I81031f64966b1aeb55cc09f381d4d83ec3460dc9
