Currently, DreamService#finish exits early if the window is not
attached. The unbind from the dream overlay service follows this
condition. As a result, it is possible that the service is not
unbound if the window was never attached. This changelist addresses
This potential connection leak by having the unbind precede the
check.
Fixed: 227498355
Test: manual
Change-Id: I7a73258cea5219bea96f4de3b90b4b5a66478fde
In practice, the value of this xml attribute is always going to a
function of whether or not getTargetActivityPendingIntent() is null--
when a QuickAccessWalletService sends us a PendingIntent, we will use
that instead of the SystemUI card switcher activity.
If the PendingIntent is null, we then fall back to our old behavior:
* If the wallet is not currently showing any cards, launch the activity
specified by getWalletIntent() (this is hardcoded in XML metadata).
* If the wallet is currently showing cards, launch the SysUI
switcher activity.
Test: atest CtsQuickAccessWalletTestCases --retry-any-failure
Test: atest QuickAccessWalletControllerTest
Fixes: 218860062
Change-Id: I62f7ca507ebce29b03d6ce76bccaa6d736720a86
Merged-In: I4cfaa5b6035499c47a0ed8b1a4a5f3e1f0f50860
In some cases, the InsetsState and the window frame can be changed at
the same time (such as orientation changed). Reporting them separately
might produce incorrect insets.
When the window layout is moved to the client, it uses the configuration
and the InsetsState to compute the window frame. They need to be
reported together as well.
Bug: 161810301
Bug: 160732586
Test: atest ActivityRecordTests WindowStateTests
Test: Add logs to check if we dispatch the correct insets to apps while
rotating the display.
Change-Id: I5c9f628eda40932def97c5caf968cb62db128e80
The call is protected by the signature permission
START_ACTIVITY_AS_CALLER. This will remove the need for additional data
to be passed from system server.
Bug: 222082547
Bug: 226354782
Test: atest ActivityTaskManagerServiceTests, atest ChooserActivityTest,
manual testing
Change-Id: I94f34a68e390569ec14dfebb1902a7c30558864f
Make to show fill dialog only if IME is not showing. And if the field
will show fill dialog, ignore to show ime when clicks on the field.
Bug: 210926084
Test: Manual
launch sample and click on password field -> show fill dialog
click on username field (no fill dialog) -> show fill UI and IME
IME is showing and click on password field -> show fill UI
Test: atest android.autofillservice.cts.dialog.LoginActivityTest
Test: atest android.widget.cts.EditTextTest
Change-Id: I6080510d87c50969d85fd9ed746ceba7e3c1c685
GateKeeperResponse has inconsistent writeToParcel() and
createFromParcel() methods, making it possible for a malicious app to
create a Bundle that changes contents after reserialization. Such
Bundles can be used to execute Intents with system privileges.
We fixed related issues previously for GateKeeperResponse class, but
one of the case was remaining when payload is byte array of size 0,
Fixing this case now.
Bug: 220303465
Test: With the POC provided in the bug.
Change-Id: Ida28d611edd674e76ed39dd8037f52abcba82586
Merged-In: Ida28d611edd674e76ed39dd8037f52abcba82586
(cherry picked from commit 46653a91c3)
Change-Id: I486348c7a01c6f59c952b20fb4a36429fff22958
This is a step to let the client layout its window locally. The ultimate
goal is to reduce the jank while laying out the window.
With the new AIDL methods, we can divide IWindowSession.relayout into:
- IWindowSession#updateVisibility (synchronized binder call)
- To get or update the surface
- To fetch the latest factors about window-layout
- Only called when the view visibility is changed
- WindowLayout#computeFrames (local function call)
- To compute the window frames
- IWindowSession#updateLayout (one way binder call)
- To report the result of layout to the server
In this way, if the view visibility is not changed, the UI thread of
the client won't be blocked by the binder call during relayout.
The local layout project won't be done in a single CL. In order not to
break the existing logic, this CL introduces a flag: LOCAL_LAYOUT. The
flag will be enabled when the logic of local layout is ready.
Bug: 161810301
Bug: 175861051
Test: presubmit (no behavior change)
Change-Id: Ic4b2fc78a318f3a68e1ef8a35d8f3ab705856702
Context#bindService can take unreasonably long to execute, causing API
clients to miss frames.
Test: atest TestQuickAccessWalletService
Test: atest QuickAccessWalletControllerTest
Fixes: 218323803
Change-Id: If0278a531b4eb07aad713986315118ac91337b0b
1. Add additional trigger onUserMayRequestUnlock
- point existing trigger points from SystemUI to this
2. Argument added to onUserRequestedUnlock to indicate if user wants to
dismiss keyguard.
3. Callback for result of grantTrust calls.
- curently only calls back if device was unlocked as a result of the
call
See design: go/au-noise-reduction
Note: changes made to SystemUI are manually tested and may need
refactoring which is being skipped now to meet the API Freeze deadline.
Bug: 225231929
Test: atest TrustTests
Test: Manual interaction with wake & fingerprint sensor
CTS-Coverage-Bug: 213944235
Change-Id: I8d08229f09c9a1f2295b7eb464d12cad0c6b8303
The goal of this CL is to remove RELAYOUT_RES_DRAG_RESIZING_DOCKED and
RELAYOUT_RES_DRAG_RESIZING_FREEFORM, which is a step to make relayout an
oneway binder call.
When the resize mode is changed at the server side, the server will send
the new mode to the client via IWindow#resized, so the client doesn't
need to obtain the resize mode from the flags returned from relayout.
Bug: 161810301
Test: Perform drag-resize and drag-move on a freeform task and see if
there is any unexpected behavior.
Change-Id: I450abc113932b6c1dc0ce0e2b76bebdf85a60777
We introduce a filed for ui presentation in FillEventHistory.Event,
the type will be set for TYPE_DATASET_SHOWN and TYPE_DATASET_SELECTED.
The AutofillService can know which dataset is shown to user and which
type dataset user is clicked.
This change defines the definition and apply to TYPE_DATASET_SHOWN,
the TYPE_DATASET_SELECTED will be implemented on the follow up
change.
Bug: 223472350
Test: manual. build and boot pass. Test app and see dumpsys autofill
CTS-Coverage-Bug: 225310516
Change-Id: Ic221bd79e2ad512db5cd1ef8fd96c6bfae2ca616
If the fill dialog is available for the field, the FillRequest flags
will contain FLAG_ACIVITY_START. The field is hidden originally but
it needs to be get from AutofillService to avoid creating unnessary
fill dialog presentation. Rename the flag because the it's not clear
to combine the relationship with fill dialog.
Bug: 223472039
Test: manual. Build and boot pass.
Change-Id: I52c367e75100f6af2ab782f58755bc5727b1dd72
There's no need for the constructor and it shows up as missing CTS tests
for it. Rather than adding tests, just remove the constructor.
Test: atest DisplayHashManagerTest
Bug: 220812349
Change-Id: I6104a4955c4ca107820de39d0547d3901d96ca18
Bug: 207717787
Test: build & boot pass.
Test: manual. Both trust and no-trust still work.
Test: manual. In nornal case, log with expected values, see bug for
details. Log expected value for some error cases (not all are tested)
by local changes.
Android Metrics Design Review : eldar/276723226
Merged-in: Iaa778616eca4cfad83a94297d9cd6116bb9577e7
Change-Id: I98fde2467e09564569cdbf10b20e9defece65cbf
(cherry picked from commit e4b76fc200)
Expands the existing test API to include the KeyphraseExtra information
in the fake DSP trigger event.
Test: atest CtsVoiceInteractionTestCases
Test: atest CtsVoiceInteractionHostTestCases
Bug: 193232191
Change-Id: I3392cb37afaed6f67fb2f3b22edcbe7c869d1eba
(cherry picked from commit 46c4ba27d1)
GateKeeperResponse has inconsistent writeToParcel() and
createFromParcel() methods, making it possible for a malicious app to
create a Bundle that changes contents after reserialization. Such
Bundles can be used to execute Intents with system privileges.
We fixed related issues previously for GateKeeperResponse class, but
one of the case was remaining when payload is byte array of size 0,
Fixing this case now.
Bug: 220303465
Test: With the POC provided in the bug.
Change-Id: Ida28d611edd674e76ed39dd8037f52abcba82586
We would like to make relayoutWindow a non-blocking call,
and of course why not, who likes blocking. However it functions
as a critical path of BLASTSync. To understand why examine the
Guarantee described in BLASTSync.md.
In order to implement this guarantee we need to know
“Which frame has the client finished drawing” when it calls
finishDrawing. The current answer to this question is
“The frame reflecting the state observed in the last call
to relayoutWindow”. The comments on mPending and mCurrentDrawHandlers
also have a lot more context on how this works currently. Since
relayoutWindow has a critical section, it also ensures that changes
to syncable state and preparation of sync will be observed atomically
(since they are both observed over relayoutWindow, which is always
called before any frame drawing updated syncable state).
We design a new protocol described in BLASTSync.md, which uses a seqId
to track which call to finishDrawing reflects which syncable state.
We implement this seqId based system. Unfortunately the WindowManager
doesn’t quite conform to the requirements specified by the protocol,
and a follow up CL ensures that syncable state changes will
always be sent with the seqId.
This CL simply adds the protocol specification and makes some required
interface changes. It can be seen to be a no-op.
Bug: 161810301
Bug: 175861051
Bug: 175861127
Bug: 200285149
Change-Id: If2dea07121fe7de5d2524c5b63678dddf955d4b7
This adds a new hidden API in StatusBarManager for active
TileService#requestListeningState. That way, we can verify that the
calling package is the same as the one belonging to the tile.
This is enforced using CompatChange for apps that target T+.
Test: atest StatusBarManagerServiceTest
Test: atest TileServicesTest
Test: atest CtsSystemUiHostTestCases
Test: sample app targetting T
Fixes: 172251878
Change-Id: Ic9b8aca55dcfc2b32b018a5308f19e49a933c4c9
