A new hidden flag is introduced to layout params to let system UI
components get the global insets state regardless of the z-order. That
is necessary to let components like power menu and system UI dialog.
Test: atest InsetsStateControllerTest
Bug: 178420426
Bug: 178115003
Change-Id: Ib103639ff00bf15919796788c0ba323aba0b4b4a
In order to support auto translation, we need to give information to
content capture service to let the app can use this information to
find the Activity which needed to be translated.
It's not safe to provide an activity token to the client app directly
even if it is a privilege app. They can use this activity token to
access many activity/windows related functions. We create a new token
for use for content capture and translation. This token will be used
get the target Activity for translation new APIs.
This change focuses on the Content capture API change, the API change
about translation will be done in the next change,
Bug: 177789967
Test: manual. Make sure cc service can get the information.
Test: atest android.view.contentcapture.ContentCaptureContextTest
Test: atest CtsContentCaptureServiceTestCases
Change-Id: Ife8096a8bd1e71ce4e686d95043e347222ad7ee6
This is the re-merging of ag/12923546 (where most of that original
message is posted below), which includes various bug fixes.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.
On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.
When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches.
We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330
UiAutomation does't require a main thread, so getMainLooper may
return null. In this case, instead of posting to the main looper,
we cache nodes on the binder thread (which is our ultimate goal
once b/180957109 is fixed).
Added tests to verify AccessibilityInteractionController interactions
Test: atest AccessibilityInteractionControllerNodeRequestsTest,
FrameworksServicesTests FrameworksCoreTests, CtsAccessibility, Manual
testing
Bug: b/176195360, b/175877007, b/175884343, b/178726546, b/175832139,
b/176195505
Change-Id: I346a3f40c84c6697b8a1e1d84a636eada655b984
This CL exposes an API to let apps know when the blur has been enabled
or disabled dynamically.
This could be due to battery saving mode turned on, tunnel mode being
used, minimal post processing requested, etc.
This adds a WindowManager.addCrossWindowBlurEnabledListener, which allows
apps to add/remove a listener for blur enabled state changes. The
listeners are registered in a CrossWindowBlurListeners, which receives
updates from WindowManagerService when blurEnabled changes.
CrossWindowBlurListeners only registers a remote listener if the client
initializes it. I.e. if the app is not interested in blurs, the
CrossWindowBlurListeners won't get initialized and won't register a
remote listener.
WindowManagerService holds a RemoteCallbackList, which holds listeners
for each client process and notifies them when there are updates. If any
of the listeners' process dies, the entry is removed from the list.
Bug: 177524486
Test: m
CTS-Coverage-Bug: 179990440
Change-Id: I3fe8f2d2008171d6b069e8ee6f3b47e5b5d60cfa
Added the following static testAPIs to replace
the usage of adb commands in cts/gts tests:
* resetTemporaryService
* setTemporaryService
* setDefaultServiceEnabled
These APIs are static because by default ContentCaptureManager
isn't available until it's enabled using these APIs.
Test: Confirmed that the APIs are accessible in CTS tests.
Bug: 180328483
Change-Id: I0a94d90b509e1d2f695556955d85d27acab19ae9
Organize the code so that it is easier to read.
Add lots of display-related tests.
Test: atest com.android.server.display
Bug: 168208162
Change-Id: I72a4eb6677e346f615e4730f4888d56333645844
Changing class DeviceProductInfo to public class with hidden ctor to expose via
Display#getDeviceProductInfo. Removing the relative address and changing
to connectionToSinkType.
Bug: 179775994
Test: atest CtsDisplayTestCases
Change-Id: I92f32461a054244b75dc4d5ddfd30e9a7968f3dd
1. Add shell command to allow a temporary override of the
TranslationService that helps e2e CTS tests.
2. Add permission to allow the shell call the UiTranslationManager
APIs for the tests.
3. Dump translation systemservice and activity translation related
information to help debugging
We don't want to leak translation feature now, so we submit the
change about Shell in internal branch.
Bug: 179047265
Test: manual.
1. Switch to temp TranslationService by "adb shell cmd transformer set
<myTranslationService> 12000" and make sure only the same app can
access the APIs when switching to the temp service.
2. adb shell dumpsys transformer
3. adb shell dumpsys activity <myactivity> --translation
(We set "transformer" now to prevent feature leak, the final value is
translation)
Change-Id: I2573b7ea226bd805a951f8346d5370d9c9776364
Previously, before BLAST, we were relying on the recreation of the
SurfaceControl when the SurfaceView was detached and reattached to
remove the SurfacePackage from the display. With BLAST we
can continue to reuse the existing SurfaceControl so this fix explicitly
removes SurfacePackage offscreen before releasing it.
Fixes: 180436742
Test: try bug steps (Change grid options in wallpaper settings and check for no overlap)
Test: go/wm-smoke
Change-Id: I9ffbc4b4a724333c799cb57f67c1fc34fe94ce41
This change includes a series of API review changes. The most
significant update is the addition of cancellation signals to
API methods where needed.
Renames some internal classes and interfaces to support the
API changes and to simplify tests and improve quality.
Test: numerous presubmits
Bug: 175830670
CTS-Coverage-Bug: 180419562
Change-Id: I9b1b950a2779fc902ecf4d6394e3c35171926700
The PositionUpdateListener in BackgroundBlurDrawable is called from
a thread pool to update the position of the BlurRegion. After that,
in frame drawing callback (RenderThread), the Aggregator takes all
the settings in BackgroundBlurDrawable and dispatches them to SF.
However, while the RenderThread is working on frame N, the Ui thread
is working on frame N+1. So when the frame drawing callback is
called on RenderThread for frame N, BackgroundBlurDrawable
might already be holding settings for frame N+1.
In this CL, we fix that by making BackgroundBlurDrawable work only on Ui
thread, while BlurRegion lives only on RenderThread. Just before
drawing, we copy the state of BackgroundBlurDrawable into a BlurRegion.
So when render thread starts doing its thing for frame N, Ui thread can
start setting up BackgroundBlurDrawable for frame N+1. The settings for
frame N are already copied over to BlurRegion. In frame drawing
callback, we take the blur regions if there is a pending update and send
them to SF.
Bug: 167166562
Test: m && atest BlurAggregatorTest
Change-Id: Icec0fa8e97de30b7bad15b97f848ae642076652f
The app will pass a list of views for Textview translation. Currently,
we traverse the view tree for each requested view. That means we will
traverse view tree many times. If the requested size of view list is
large, it shoule be a performance issue. We refine to find views in
sinslge traversal in this change.
Use a sample app with many views and layouts and compare the time of
two implementations. The average time of original solution is 300000
~ 600000 ns. The new approach is 150000 ~ 300000 ns.
Bug:178989965
Test: Write a sample app with many views and complicate structure,
see bug for test sample screenshot. Compare the execute time of two
implementation.
Change-Id: I5a051740ad40e77ed4a54294368031eb82ab87ab
