As dreams get more complex, we would like more specific loggings for how
dreams are started/stopped for better debugging.
This CL adds "reason" as a required parameter in the start/stop dream
internal/private API. This allows callers to specify reasons.
Bug: 252796782
Fix: 252796782
Test: verified reasons are correctly logged on device
Change-Id: Icea03eb6e23ca113f50fa047f6d57e6e1d0b5604
DISMISSAL_BUBBLE previously had the same value as DISMISSAL_SHADE, so bubble dismissals weren't getting counted correctly. It also needed to be added as a new UiEvent on the logging side so that the dismissal surface could be handled correctly. This dismissal surface is getting set by BubbleManager already, so the necessary changes should be limited to the logging side.
This change also adds a new dismissal surface for the lockscreen, in conjunction with the already existing UiEvent enum for NOTIFICATION_CANCEL_USER_LOCKSCREEN. However, this change does not yet add correct handling of new dismissal surface on the side where notifications get dismissed; that will be in an upcoming change.
Bug: 234507856
Fixes: 252821281
Test: statsd_testdrive
Change-Id: Ib8fe37dc1277c55de1c26a5e2b3835b3a9f3c941
ag/19763724 modified Sandman.java to use LocalServices, but it turns out
that Sandman.java is exposed to clients via PowerManager - where
LocalServices isn't available. This caused PowerManager#dream to break
Fixes: 249916607
Test: atest UiModeManagerServiceTest
Test: "OKG go to ambient" voice command
Change-Id: I3e031593568fdb7b92a1209823463832feeb1601
Introducing a flag to gate the Attention Service usage by Hotword
Detection Service. The Attention Service will be disabled by default.
Bug: 247890608
Test: atest CtsVoiceInteractionTestCases
Change-Id: Ic8a6a11b2a0843a96f135b360f10f7fef5fce274
We pipe the component name of the currently active dream into the
overlay service, and when the active dream is lowlight, we hide the
status bar.
Test: atest DreamOverlayStateControllerTest
Test: atest DreamOverlayStatusBarViewControllerTest
Test: manually on device by entering/exiting low light and ensuring the
status bar is hidden
Fixes: 245386662
Change-Id: I22973538bea19ef108360a319c70c878cfd81800
This app-generated input needs to not be too long to avoid errors in the process of writing to disk.
Bug: 242846316
Test: cts ConditionTest; atest ConditionTest; manually verified exploit apk is OK
Change-Id: Ic2fa8f06cc7a4c1f262115764fbd1be2a226b4b9
Test: Manual on mobile (try to download & attach a wallpaper, check that
nothing breaks)
Test: atest ImageWallpaperTest
Bug: 243402530
Change-Id: I5af1acf08bb1c43a5e119597a9cef2ea667723c3
If the trustGranted call has flag DISPLAY_MESSAGE and
message is intentionally set to an empty string "", then
don't show ANY trust granted message. If the message is null
or DISPLAY_MESSAGE is not set when trust is granted,
then the device will show its default trust granted string.
Test: atest KeyguardIndicationControllerTest
Test: manually grantTrust with the FLAG_GRANT_TRUST_DISPLAY_MESSAGE
and an empty string. See that device has trust granted and doesn't
show any keyguard indication message.
Fixes: 243075236
Change-Id: Ic31a1758e9baa27b236f09ba8e656d15dd04e7f0
This change
- adds a new private API in dream manager that allows a client with
write dream permission to set a system dream component, which takes
precedence over user configured dream
- fixes startDream() API in DreamManager which shouldn't take in a
component name
Test: atest SystemDreamTest
Bug: 222529147
Change-Id: Iee9a0af1071e5ed57fa5bd4b0d06d8178118116e
The keyguard must be showing and unoccluded, or the device is not
interactive (eg screen off) in order for dreams to be started
immediately when docked. This prevents dreams from starting if there is
an activity currently showing over the lockscreen.
Also includes some refactoring to be able to unit test this change,
since dock state changes were not previously tested.
Fixes: 233412496
Test: atest UiModeManagerServiceTest
Test: manually on device with keyguard occluded, unoccluded, and screen
off while docked
Change-Id: I12f1a4cf3ae4784e391e3c5a3fd1d50b4d4f7ecd
This is a regression during refactor toolbar code, we don't intent
to announce the toolbar popup window so we should not set content
description for the container.
Bug: 239563674
Test: manual. Turn on talkback and make sure the announce is correct
and the behavior is the same
Test: atest TextViewIntegrationTest pass for local/remote
Test: atest TextViewActivityTest pass for local/remote
Test: atest SuggestionsPopupWindowTest pass for local/remote
Change-Id: I6e30d2f6d9a2c4905b702c25655fe5e4eb7de5d5
IWindowSession#relayoutAsync is similar to IWindowSession#relayout, but
the former is an oneway method which just sends the layout attributes to
the server. Since the client can compute its own window frame, it just
needs to send attributes to the server without getting blocked for
receving the window frame.
In somes cases, the client still needs to obtain things from the server.
Such as:
- When view visibility is changed. The client maybe not be able to
receive the latest insets state while it is INVISIBLE or GONE. In this
case, the client needs to obtain the frame and the insets state. Also,
the client need to obtain the surface control when it becomes VISIBLE.
- When the insets state is stale but the config is up-to-date. This can
happen when WindowProcessController sends the new config to the client
before WindowState does. In this case, the client needs to obtain the
window frame from the server.
- When the position and the size of the frame are both changed. This
will trigger a BLAST sync, and the client needs to obtain the sync seq
ID.
For cases above, the client needs to call the original relayout method.
Bug: 161810301
Bug: 175861051
Test: Seamless rotation, fixed rotation, and regular rotation.
Merged-In: Ifb365789fa08103773fd3180e486ba1d92042fc5
Change-Id: Ifb365789fa08103773fd3180e486ba1d92042fc5
Reverting the previous revert commit which was merged to resolve the
broken tests. Adding a fix to the broken tests by surrounding
mAttentionManagerInternal with null checks.
dbe5ad1a72
Test: atest CtsVoiceInteractionTestCases, atest CtsVoiceInteractionTestCases:android.voiceinteraction.cts.AlwaysOnHotwordDetectorTest#testAlwaysOnHotwordDetector_startRecognitionWithData -- --abi x86_64
Change-Id: Ife5fb9220518a32a89494217f56932f290cce5f3
Merged-In: Ife5fb9220518a32a89494217f56932f290cce5f3
The toolbar should set the theme to the app's theme. Because the
service cannot get the application context, we should pass this
information from application to service.
Bug: 218833400
Test: manual. Use light/dark theme for app, the toolbar shows with
the same theme
Test: atest TextViewIntegrationTest
Test: atest android.widget.TextViewActivityTest
Change-Id: I6d4e4e117c680ce57e760a87987059eded09b2bc
Currently there is no signal to identify that dreaming has started
from the 'preview' option in screen saver settings. This adds a
way to query IDreamManager for this state.
Bubbles needs a way to identify this so that they can hide when
the dream preview starts, otherwise it wouldn't be an accurate
preview.
Bug: 240510360
Test: manual - (with the CL on top of this), have some bubbles and
trigger dream preview, observe that the bubbles hide.
Change-Id: I5f67a8c793970ada05a010c8d36fd4a47b3f8565
RoleService should not be calling onRoleHoldersChanged() on
pre-created users, but that behavior cannot be changed because its
implemented by a system app, and pre-created users APIs are hidden.
To test it:
$ adb shell pm create-user --pre-create-only --guest
Success: created user id 12
$ adb shell pm create-user --guest ElGuesto
Success: created user id 12
$ adb shell cmd user list --all -v
4 users:
0: id=0, name=Driver, type=system.HEADLESS, flags=ADMIN|INITIALIZED|PRIMARY|SYSTEM (running)
1: id=10, name=Driver, type=full.SECONDARY, flags=ADMIN|FULL|INITIALIZED (running) (current)
2: id=11, name=null, type=full.SECONDARY, flags=FULL|INITIALIZED (pre-created)
3: id=12, name=ElGuesto, type=full.GUEST, flags=EPHEMERAL|FULL|GUEST|INITIALIZED (converted)
$ adb shell am switch-user 12
$ adb shell dumpsys voiceinteraction |egrep '(mBound|implementation)'
mBound=true mService=android.service.voice.IVoiceInteractionService$Stub$Proxy@77da1bc
$ adb shell cmd voiceinteraction show
Test: see bove
Bug: 216141085
Bug: 226201975
Merged-In: I12d9bb32e144ecf91ee4b452affea0dcea546127
Change-Id: I12d9bb32e144ecf91ee4b452affea0dcea546127
(cherry picked from commit 39acca1d72)
The client computes the window frame on its own in ViewRootImpl#setView.
However, the bounds obtained from WindowConfiguration is not size-
compatible, which makes legacy apps produce wrong frames. The frame is
larger than expected, so when computing WindowInsets with size-
compatible InsetsState, the window cannot receive insets.
Although the client will receive the correct window frame from relayout,
but the first WindowInsets has been dispatched before that.
This CL sends the size-compat scale to the client, so the client can use
the correct WindowConfiguration to compute frames.
This is also a step to enable the client to perform local window layout.
Bug: 237749017
Bug: 161810301
Bug: 175861127
Test: atest StartingSurfaceDrawerTests WindowAddRemovePerfTest
ActivityRecordTests WindowManagerServiceTests
Change-Id: I6b23901f4b1f009444c04da7e078ea971a386ad7
This reverts commit:
db407ef12d, and
d8aa7f7882.
Reason for revert:
The surface size would be reduced by mTranslator unexpectedly.
Fix: 233017734
Test: Open a legacy app which has CompatibilityInfo.SCALING_REQUIRED
and see if the app is cropped.
Change-Id: If830866328a5709cf6856fe840a804b304052003
The attached frame is the frame of the parent window that its child
attaches to, as long as the child is not
TYPE_APPLICATION_ATTACHED_DIALOG. It is a factor while computing the
window frame.
Previously, we let the child obtain the attached frame from its parent
view root. However, if the parent and the child are not in the same
process, it can be tricky.
This CL sends the attached frame from the server to the client via
ClientWindowFrames. In this way, the child can compute its window frame
without having to accessing the parent view root.
Bug: 161810301
Bug: 175861127
Test: atest ActivityRecordTests WindowLayoutTests
Change-Id: Ia844a4c927027e305a56114216eaee2bf7933b1f
cleanup.
This ensures the memory is properly cleaned up if an exception is thrown
while building the DreamMetadata object.
Bug: 234343900
Test: locally on device
Change-Id: I29b2bed30c216d5e353fa0a8b0da74579b33cecb
The force-relayout was added in [1] for the side effect of [2].
Since the preserve-surface has been completely removed in [3].
So [1] can be restored to avoid unnecessary cost.
WallpaperService always calls relayout with View.VISIBLE, so
unless it requests to remove the wallpaper window, its surface
should not be removed. Though currently there might be no such
cases, add a log in case something goes wrong.
[1]: I79f97df61696eea325183e9b9057cbb10ce8cc66
[2]: Iea8ed86a9c4a7674804152aa44df7ef3d6341768
[3]: I4574ac0d3b8a63b13ac44846e729b73ca0f88f23
Bug: 233599092
Test: No additional relayout from wallpaper when turning on screen,
swiping/closing up to home.
Test: Toggle overview from wallpaper picker while using live wallpaper.
The wallpaper won't disappear.
Change-Id: I6673e458b5577f780be17a51cf5de1d6493ab5ca
Because animators are not tied to the lifecycle of any UI
elements, it is possible for an app to go into the background
and for the animators to continue running. Ideally, the app would
track the lifecycle of the activity/etc and pause or disable the
animators, but it is common for this to not happen, causing the
animators to continue spinning when the app does not need them.
The animators are not causing as much work as for a foreground
activity (since they do not cause any re-rendering), but they cause
work nonetheless by keeping Choreographer awake to continue pulsing
frames.
The ideal fix would be to introduce new API for animators that
tied them to lifecycle concepts (View, Activity, etc). But that kind
of fix would only be available for future versions of the platform,
and does not address existing app code. A workaround for the current
situation is to address the most egregious problems; infinite animators
running on backgrounded apps.
The fix here is exactly that: when an app's visible surface (either an
activity or, for Wallpapers, a WallpaperService) is backgrounded,
a request is sent to pause animators for that surface. When that surface
comes to the foreground, a request is sent to resume those animators.
Since all animators are handled on the same thread for the same process,
in AnimationHandler, we should only ever pause animators when *all*
surfaces for a process are not visible (and resume them when *any*
surface becomes visible). Also, to mitigate any issues with thrashing
animator state for apps which become only transiently backgrounded,
we delay pausing for some time.
Bug: 228598053
Bug: 233391022
Test: new AnimatorLeak CTS test, plus manual testing for activities
and wallpapers
Change-Id: I8b9f841cc80babb972244c724968a5c085a06b69
Merged-In: I8b9f841cc80babb972244c724968a5c085a06b69
