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
updateSurfaceDimming().
Reduce jank by removing notifyColorsChanged() on updateSurface() which
caused notifyColorsChanged() to be called multiple times successively.
Test: manual, atest WallpaperManagerTest
Bug: 229715857
Change-Id: I552a6956648250cd36787b7ddd79758422ea7f68
By the behavior, the interactor of assistant needs to call the
startRecognition function again after hotword event is triggered.
Otherwise it will not receive the result of detection.
Currently when security exception occurs during onDetected, we
won't inform the interactor of assistant about the hotword event.
It will cause the interactor still to wait the hotword event and
doesn't call startRecognition function again.
After syncing with assistant, we should use onError() callback
to inform interactor.
The behavior of onError() in the interactor:
For both of DSP and Software, assistant will call startRecognition
function.
The behavior of onRejected() in the interactor:
Only for DSP, assistant will call startRecognition function.
For Software, assistant doesn't expect to get onRejected()
Bug: 230738063
Test: atest HotwordDetectionServiceBasicTest
Change-Id: I3083fd5a4a78ad9d2f35acd7fa1a4f2036cf64de
Merged-In: Ideb210d4364d4c48c747d66268d77a2f5b017186
