This reverts commit 02d3a8ad07.
Reason for revert: the original change caused the infinite message loop.
Bug: 155794233
Change-Id: I3d72541cd51cd8b16ce4f44124d486b4615b09da
Clarify when some of the ContentResolver APIs could return null.
Bug: 112833761
Test: builds (documentation update)
Change-Id: I3af1a23bc484d05b167a86bbff0c93ff1bd364e7
Two recent checkins broke the Javadoc (in both cases, an <h3> wasn't
properly closed). Made the fix by hand to the HTML output in
cl/309818465 but we need to make the corresponding change to
the Java source or it'll get reverted next time we update the reference
docs.
Staged to:
go/dac-stage/reference/android/content/pm/LauncherApps.PinItemRequest
go/dac-stage/reference/android/service/autofill/AutofillService
go/dac-stage/reference/kotlin/android/content/pm/LauncherApps.PinItemRequest
go/dac-stage/reference/kotlin/android/service/autofill/AutofillService
BUG: 155669442
Exempt-from-owner-approval: Docs-only change
Test: make ds-docs
Change-Id: I97be9550689544304dff276cf3c9406f9cd98408
Currently, there is
onOpNoted - tells listeners that noteOp has occurred
onOpActiveChanged - tells listeners that an op's 'active' state has
changed, i.e. that a successfull startOp or stopOp has happened
There was, however, no way of telling a listener that a startOp has
happened (regardless of whether it was successful). This cl introduces
it, via a OnOpStartedListener.
This is required by the ForegroundServiceAppOpSessionEnded atom,
which counts the number of accepted vs. rejected attempts, and
therefore also needs to know when a rejected start happened.
This cl also contains some cosmetic moving of code so that
startOperation() and noteOperationImpl() are almost
exactly parallel.
* Also *
This cl fixes a bug I discovered in stopWatchingNoted, in which
the callback wasn't fully removed. Consequently, if a callback
was unregistered and then re-registered, the re-registration would
mistakingly be ignored (in direct contradiction to the javadoc).
Test: atest UidAtomTests#testForegroundServiceAccessAppOp
Test: atest AppOpsStartedWatcherTest AppOpsActiveWatcherTest AppOpsNotedWatcherTest
Test: manually monitor: adb shell cmd stats print-logs && adb logcat -v uid -s statsd | grep "statsd : {" | egrep '\(256\)'
Bug: 152800926
Change-Id: Icdb9edf6b2b7c5807b339c1aabb32e882190b071
Introduces new test api to access the background view of status bar and
navigation bar.
Bug: 154720832
Test: atest WindowInsetsPolicyTest
Change-Id: If38d3f57edfbb2631d4c1e47ed5347a332edacfb
Previously, we've notified it only when we have the control.
But to update color views, we should notify it even when we have no control.
Bug: 154720832
Test: atest WindowInsetsPolicyTest
Test: make sure no regression on b/150195782, b/151425506
Change-Id: I44b88ddc206f36d8ef11dae9c1477739a185ff21
* The use case of this API was for augmented autofill service to send
updated suggestions
* Before this change, the dynamic autofill request by the augmented
autofill service only triggers a manual request, but this has caused
some regular autofill providers to always some suggestion due to
their special handling for the manual request. Thus the augmented
autofill service will not receive the request.
* With this cahnge, the request cancels the previous session to start a
new session, and also it triggers a regular request (non-manual) so
the autofill provider will not special handle the request.
Test: atest CtsAutoFillServiceTestCases
Bug: 154543563
Change-Id: I233125a6070394a102ad40b9a50b98a43d952b9f
In SurfaceControlViewHost#release we currently immediately
release mSurfaceControl and then call ViewRootImpl#doDie.
However doDie executes on a handler so the ViewRootImpl may try
and use the SurfaceControl between posting and executing
the message. Actually this release is totally erroneous,
mSurfaceControl is the same object used by the ViewRootImpl
and the ViewRootImpl will release it when processing
doDie().
Bug: 155575445
Test: Existing tests pass
Change-Id: I6a4bf41ba38636ff884aa73d2653b1bab6958b00
