The ArrayEquals, ArrayHashCode, ArrayToString, and
ArraysAsListPrimitiveArray errorprone findings were
demoted from errors to warnings. Fix existing
occurrences of them so they can be made errors again.
Bug: 242630963
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: Ia6f216cc36ad0a5758f39fd9b34962cd4adf9d8e
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
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
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
Revert submission 17936037-hotword_proximity
Reason for revert: https://buganizer.corp.google.com/issues/242223069
Reverted Changes:
If8c23a9c6:Refactor ProximityUpdateCallbackInternal to interf...
Ib0ad1da25:Verify that proximity key is added to the hotword ...
I71e9d3da9:Add proximity state to the HotwordDetectedResult
Change-Id: I6b79d9400671362dd63be1e2a0d05280003587d3
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.
Change-Id: Ifb365789fa08103773fd3180e486ba1d92042fc5
HotwordDetectionConnection will interact with AttentionService to
receive updated proximity state. Then it will fill the
HotwordDetectedResult returned from Hotword service to set
proximity state.
Bug: 214395649
Test: atest CtsVoiceInteractionTestCases
Change-Id: I71e9d3da999cda2d9b17e3abc900fa42e4364c90
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)
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
Change-Id: I12d9bb32e144ecf91ee4b452affea0dcea546127
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
To audit data access and verify the uid and package are consistent,
use noteOpNoThrow instead of checkOpNoThrow.
Bug: 187439908
Test: atest AssistDataRequesterTest
Test: atest CtsVoiceInteractionTestCases
Test: atest CtsAssistTestCases
Change-Id: Ib48040b5b55be09958da4398f4d663908573568c
Java side for a new API, setFrameRateDefault, where policy implementation logic is made using setFrameRateDefault instead of checking window types.
Bug b/192291754
Test: manual
Change-Id: I3ff35dbe3551746b90448531dccec09d8355824c
