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
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
takeScreenshot is a system API of GameSession and hence should be
guarded by MANAGE_GAME_ACTIVITY permission.
Bug: b/217986003
Test: atest GameServiceTest
Change-Id: I5591435245ba07abf6c9020ef89905f195309a92
This makes sure existing behaviors don't change, and only dreams that
specify show dream overlay complications get them.
Change-Id: Ic5f440d0519432e6158c5aa64409abd402d48139
Test: atest DreamOverlayServiceTest
Bug: 214456383
Fix: 214456383
This changelist clears the reference to the DreamActivity window once
the activity is cleared in DreamService. Holding onto the reference
will lead to a DreamActivity instance leak.
Test: verified leak no longer present through hprof
Bug: 221285764
Change-Id: I1494bcdeaa1b23c0006867ff8eb1806bd5206eba
* Move the BitmapUtil to com.android.internal package
* Remove bitmap result from GameSession#takeScreenshot API
Bug: 219992742
Test: atest GameServiceProviderInstanceImplTest
Change-Id: I4bf29d623f781434ec7ffe4443e658880c31e619
Move the BitmapUtil to com.android.internal package
This reverts commit ae8b96964c.
Reason for revert: causes overlay elements to not appear.
Test: manual
Bug: 222307681
Change-Id: I2d1f55227774a39f4b2dbe927ddd3aa1a5178351
This makes sure existing behaviors don't change, and only dreams that
specify show dream overlay complications get them.
Test: atest DreamOverlayServiceTest
Bug: 214456383
Fix: 214456383
Change-Id: I5c94484d5af592159a07257137a138e41d0c6b53
The preview overlay needs access to the user-facing label for the dream,
to show the user which dream they are previewing.
Test: atest DreamOverlayServiceTest
Bug: 219747041
Change-Id: I26362ce1fefcd5c9557e99ad2f44374f04017c29
This will allow us to change which complications are shown based on if
we are in preview mode.
Test: atest DreamOverlayServiceTest
Test: locally on device
Bug: 219747041
Change-Id: I4ec34b990fec5e09114a71719c0271da7758aac7
Dump toolbar information to help debug.
Bug: 219664390
Test: dumpsys activity service DefaultSelectionToolbarRenderService
Change-Id: I332d3289dc2533a7583453853f1ec9324b67d088
