summaryrefslogtreecommitdiff
path: root/core/java/android/view/WindowlessWindowManager.java
Commit message (Collapse)AuthorAgeFilesLines
* Introduce IWindowSession#relayoutAsyncTiger Huang2022-08-161-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Send size-compat scale to the clientTiger Huang2022-07-271-4/+9
| | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Revert "Introduce updateVisibility and updateLayout"" into tm-qpr-devTiger Huang2022-06-241-15/+0
|\
| * Revert "Introduce updateVisibility and updateLayout"Tiger Huang2022-06-221-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit: db407ef12de94280658d22835856377cc6b6b96a, and d8aa7f78821c8014d3ac02dc5ff7acaf9d690ee8. Reason for revert: The surface size would be reduced by mTranslator unexpectedly. Fix: 233017734 Test: Open a legacy app which has CompatibilityInfo.SCALING_REQUIRED and see if the app is cropped. Change-Id: If830866328a5709cf6856fe840a804b304052003
* | Merge "Send the attached frame to the client" into tm-qpr-devTiger Huang2022-06-231-4/+5
|\|
| * Send the attached frame to the clientTiger Huang2022-06-201-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The attached frame is the frame of the parent window that its child attaches to, as long as the child is not TYPE_APPLICATION_ATTACHED_DIALOG. It is a factor while computing the window frame. Previously, we let the child obtain the attached frame from its parent view root. However, if the parent and the child are not in the same process, it can be tricky. This CL sends the attached frame from the server to the client via ClientWindowFrames. In this way, the child can compute its window frame without having to accessing the parent view root. Bug: 161810301 Bug: 175861127 Test: atest ActivityRecordTests WindowLayoutTests Change-Id: Ia844a4c927027e305a56114216eaee2bf7933b1f
* | Prevent windows from drawing if they're in an active sync setchaviw2022-06-131-0/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | If a window is in a sync, but it already drew it's sync buffer, it normally would be allowed to continue processing draws and just block when it runs out of buffers. It would unblock once the sync is complete at the sync buffer was sent to SF. However, this has a few issues 1. In some cases, WMS wants to retry the draw again due to configuration changes. This could cause deadlocks because the client may already be blocked since there are no more buffers. Instead, the client will block and WMS would be responsible for dropping the last buffer and notifying the client that it can draw for a sync again 2. If there are multiple UI threads, each can block each other due to the shared Render Thread. If one of the windows in the sync continues to draw and then blocks RT due to no more buffers, all other UI threads are unable to draw. If the behavior in 1 is desired, we'd need to make sure no one in the same sync continues to draw until everyone is complete. This is to ensure dropping will actually allow another render to occur. If other windows are blocking the RT, then even with dropping, the requested sync window cannot get another buffer and will cause a deadlock. Test: Current sync requests work Bug: 233625646 Change-Id: I3a0a4f36bf61a6677507672578e447060b806651
* Create OnBackInvokedCallbackInfo to wrap callback and its priority.Shan Huang2022-04-071-3/+3
| | | | | | | | | | | | | | | Main motivation is to store a back callback's exact priority value in WM. This is required by the IME migration (ag/17076160) to compare the priority levels of IME window callback and focused window callback in BackNavigationController. This also consolidates the WindowState#mSystemOnBackInvokedCallback and WindowState#mApplicationOnBackInvokedCallback fields into one field, as tracking two fields for one callback was error prone. We had to remember to clear the application / system field when the other field is set, and failing to do so has resulted in bugs such as b/222675481. Bug: 224856664 Test: atest BackNavigationControllerTest Test: atest WindowOnBackInvokedDispatcherTest Test: m -j and test back behavior throughout the system on apps that opted in and out. Change-Id: Ic57113610d934f33d2c9ca4cef59f39a9b87e832
* Send InsetsState to the client via IWindow#resizedTiger Huang2022-03-251-4/+10
| | | | | | | | | | | | | | | | | 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
* Introduce updateVisibility and updateLayoutTiger Huang2022-03-221-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Remove RELAYOUT_RES_IN_TOUCH_MODE" into tm-devTiger Huang2022-03-161-2/+1
|\
| * Remove RELAYOUT_RES_IN_TOUCH_MODETiger Huang2022-03-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When WindowManagerService.mInTouchMode is changed, we will set the new mode to InputManagerService, and clients will be notified via ViewRootImpl.WindowInputEventReceiver#onTouchModeChanged. We don't need the flag to bring the information to the client. This is also a step to make relayout an oneway binder call. Bug: 161810301 Test: Invoke View#requestFocusFromTouch on one window and see if another window can receive OnTouchModeChangeListener#onTouchModeChanged. Change-Id: Ic149c95bee89b2be83a85eb4858131224b63a7c8
* | Merge "Fix divider disappear when rotation on shell transition" into tm-devTony Huang2022-03-151-1/+5
|\ \
| * | Fix divider disappear when rotation on shell transitionTony Huang2022-03-141-1/+5
| |/ | | | | | | | | | | | | | | | | | | | | | | | | When rotation, it will re-init the split divider for new rotation on DAinfoChanged callback, but when shell transition, we should do it on startAnimation to make transition smooth and make didider could release by specfic Transcation to avoid it hide immediately but didn't sync with transition. Fix: 222158856 Test: manual Test: pass existing tests Change-Id: I797ffd0ea35d89b4ec1e3ef4828ce36e18c860be
* / WMS/ViewRoot: Prepare for Async BLAST Sync [1/N]Robert Carr2022-03-141-2/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add SystemApi to set unrestricted keep-clear rectsGalia Peycheva2022-02-281-3/+4
| | | | | | | | | | | | | This CL allows applications to choose whether to set restricted or unrestricted keep-clear areas by adding a dedicated SystemApi for unrestricted keep-clear areas - View#setUnrestrictedKeepClearRects. The SET_UNRESTRICTED_PREFER_KEEP_CLEAR_AREAS permission is now only checked for keep-clear areas from that API Bug: 221094507 Test: atest CtsWindowManagerDeviceTestCases:KeepClearRectsTests Test: atest WindowStateTests#testUnrestrictedKeepClearAreas Change-Id: I89ca3149117b4d457c5521d617880870706d7793
* Invoke callbacks based on back navigation type.Shan Huang2022-02-111-3/+1
| | | | | | | | | Test: m -j. Test: Open and swipe back on pre-T and T apps. Test: atest .../BackNavigationControllerTests.java Test: atest .../BackAnimationControllerTest.java Bug: b/195946584 Change-Id: I00cf7ab5b57760d57d30ac74dc5b3443a4203f38
* Add identifier for EmbeddedWindowsTianhao Yao2022-02-041-6/+7
| | | | | | | | Use LayoutParams title as identifier for EmbeddedWindows Test: `adb shell dumpsys input` shows the names for EmbeddedWindows Bug: 205621873 Change-Id: I5c10b1e38aafff0734f42429c4f421a95de3d0da
* WM/SurfacePackage: Forward insets to WindowContainer overlaysRobert Carr2022-01-261-2/+22
| | | | | | | | | | | | | | | | | | | | We add support for forwarding InsetsState over SurfacePackage to reach embedded ViewRootImpl. As a next step we hook up forwarding of insets from the main visible window of a task with overlays, to said overlays. We provide a frame so that the remote ViewRootImpl can interpret the insets relative to this frame. In the TaskOverlay case everything in the remote SurfaceControlViewHost is in a world relative to the task bounds, and so we send the task bounds. Transient insets are also forwarded via this channel. This is due to the specific requirements of game service overlay, but seems to make sense in general for overlays, who will need to be able to intelligently handle immersive mode. Bug: 213603716 Bug: 214239892 Test: SurfaceControlWindowInsetsTest Change-Id: I22e22050a5dec71d8120ef4fea4a1c9bc452e02f
* Reland "SurfaceControlViewHost: Restrict disclosure of input token""Robert Carr2022-01-261-3/+9
| | | | | | | | | | The original CL only updated one of the two implementations of grantEmbeddedWindowFocus, and for as of yet unknown reasons presubmit did not detect the failure until after it landed. Bug: 215912712 Test: SurfaceControlViewHostTests Change-Id: Ie278f678f12f50c32f142a4260ff7d1c2a9ca57c
* Merge "Revert "SurfaceControlViewHost: Restrict disclosure of input token""Joseph Jang2022-01-261-9/+3
|\
| * Revert "SurfaceControlViewHost: Restrict disclosure of input token"Joseph Jang2022-01-261-9/+3
| | | | | | | | | | | | | | | | This reverts commit 131444d50077884daf4e00c097f1f2335c465c04. Reason for revert: <Test break by b/216355943> Change-Id: I172db29e4eebea9214d05fc1309abbc0c4487804
* | Merge "SurfaceControlViewHost: Restrict disclosure of input token"Rob Carr2022-01-251-3/+9
|\|
| * SurfaceControlViewHost: Restrict disclosure of input tokenRobert Carr2022-01-241-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we send the input (channel) token from the embedded view hierarchy to the remote embedding process via SurfacePackage. This is used to call grantEmbeddedWindowFocus. However this could also allow the host process to invoke updateInputChannel, which is not desirable. To fix this we rework updateInputChannel to work in terms of a focusGrantToken, which only carries this 1 capability. SurfacePackage is modified to not include the input token, but rather include this focus grant token. Bug: 215912712 Test: Existing tests pass Change-Id: Ia9153c54e3e36e73c2b56763b96afab9e9f20d40
* | Merge "AttachedSurfaceControl: Add setTouchableRegion API"Rob Carr2022-01-251-0/+5
|\ \
| * | AttachedSurfaceControl: Add setTouchableRegion APIRobert Carr2022-01-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an API for setting touchable regions. This API allows a view hierarchy to allow touches to pass through its surface in certain regions. Touch pass through of course follows the regular rules about UID/PID origins and touchable region does not effect the calculation of the TOUCH_OBSCURED flag. Such an API has existed as @hide since the beginning of time, via ViewTreeObserver.ComputeInternalInsetsListener. The API has already been wrapped in the IME system, and in VoiceInteractionSession. Desire to make the API public is motivated by 3 use cases: 1. GameOverlayService UI code moving out of framework required for their UX (multiple small buttons in a large transparent overlay) 2. SurfaceControlViewHost: A common point request among people who ask me about SurfaceControlViewHost is to be able to embed the SurfaceControlViewHost in a SurfaceView which is "setZOrderOnTop(false)" (hole punching) so that the host hierarchy can draw on top of the embedded hierarchy in some regions. This is possible today, but there will be no way to receive input without input hole punching. 3. There may be cases where apps are using multiple Popup type windows which could be combined in to one. In general reducing HWC layer count this way will be a good trade off. It was considered to ViewTreeObserver.ComputeInternalInsetsListener directly but ultimately decided against it for a few reasons: 1. Obscure naming 2. Other fields not useful for our use cases. Because insets/touchable region linkage not a useful API concept for us 3. Forces dispatch model via callbacks which may or may not be useful for a given app. It was also considered to create a gatherTouchableRegion API mirroring gatherTransparentRegion. Such a concept (as setting root surface touchable regions) is not really composable though. For example maybe a parent view requires touch regions, then a child view one day starts removing them. The fact that input order is not simply reverse drawing order (since parents come before children in both) means there is no way to ensure this always cleanly composes as expected. Given this, it's better to expose a "global" API and require the app developer to understand how their components are fitting together, rather than invite a View implementer to subclass gatherTouchableRegion and allow someone to break them. Bug: 213603716 Bug: 214239892 Test: SetTouchableRegionTest, SurfaceControlViewHostTests Change-Id: Ie49caec964455b7129daa2aaa6990a368309f8e9
* | | Remove the frame number from WindowManagerServiceTiger Huang2022-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The frame number at the server side is not used anymore since BLAST. Bug: 161810301 Test: presubmit Change-Id: I01c6fb0750799aa94766f2582ce6ac031c9426cf
* | | Let the client compute the surface size on its ownTiger Huang2022-01-241-14/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | This is a step to move the layout logic to the client side. We won't obtain the surface size from the server then. This CL also moves the logic about adjusting the LayoutParams of wallpaper to the client side. Bug: 161810301 Test: presubmit Change-Id: I3a81e174035c67a285cab449c0701ee2fe6f6a24
* | Merge "Implement OnBackInvokedDispatcher"Shan Huang2022-01-241-0/+5
|\ \
| * | Implement OnBackInvokedDispatcherShan Huang2022-01-231-0/+5
| |/ | | | | | | | | | | | | Bug:209867448 Test: mp core services sysuig. atest FrameworksCoreTests:WindowOnBackInvokedDispatcherTest Change-Id: Ib74250e93926854f07ebba6b9f680040aa98f9a4
* / Add keep clear rects APIGalia Peycheva2022-01-221-0/+5
|/ | | | | | | | | | This allows the app to set views as keep-clear areas, which the system will avoid laying out floating windows over, like Pip or Bubbles. Bug: 209577354 Bug: 209578131 Test: atest CtsWindowManagerDeviceTestCases:KeepClearRectTests Change-Id: I02f72376b709c0534bd678b7ce66cd95cab41832
* WindowlessWindowManager: Support touchable regionRobert Carr2022-01-151-0/+1
| | | | | | | | | We just need to forward the WindowSession call to the internal method we already support. Bug: 213603716 Test: Existing tests pass Change-Id: I692d321a96b5278c75bceb14d5b38459d360b4b9
* SurfaceControlViewHost: Add side-channel to SurfacePackageRobert Carr2022-01-121-1/+1
| | | | | | | | | | | We add a control interface in to surface-package which allows the embedding process to dispatch events back to the embedded process. So far we support forwarding configuration changes, and dispatching a detach view hierarchy message. Bug: 213603716 Test: Existing tests pass Change-Id: I7d68628d845b5da687568ffa20529ce2a7772495
* Remove parent window from display contentTiger Huang2021-10-061-5/+0
| | | | | | | | | This CL removes the logic related to the legacy ActivityView. Bug: 179161778 Bug: 161810301 Test: build and boot to home. Change-Id: I757769d3cac89ebddbdc467f533fed99c74941ee
* Add accessibility support for Drag & Dropsallyyuen2021-09-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | go/a11yDragAndDrop Add AccessibilityAction#ACTION_DROP to potential drop targets. Add A11yAction#ACTION_CANCEL to the source of the drag. Developers will be required add the A11yAction#ACTION_DRAG action (androidX can do this) Send AccessibilityEvents when appropriate. These events will be sent when a drag is performed via a11y actions, or via touch events with a11y enabled. Drop and cancel events are mutuall exclusive. To avoid a scenario where a user starts a drag via an a11yAction but doesn't drop or cancel, the system will cancel the event after a minute timeout. Corner cases: 1) A user cannot start a drag on another view without first cancelling the current one 2) An ACTION_DRAG on a View won't be successful if the last touch point was in that View For a11y, we send window events directly from the View to avoid source merging in ViewRootImpl. (Specifically for the start events, where the event gets sent from the common ancestor of the source and target instead of the source) Bug: 26871588 Test: atest DragDropControllerTests CtsWindowManagerDeviceTestCases:CrossAppDragAndDropTests AccessibilityDragAndDropTest Use Android's official sample drag and drop apps. Drag within window and across split screens Use ReceiveContentDemo target app with sample app Change-Id: Ie8554d25ab6c43b08d2dacb8c8907b1636bd72b4
* Use InsetsVisibilities to carry requested visibilitiesTiger Huang2021-07-261-4/+4
| | | | | | | | | | | | | | | | | | | | | | InsetsState contains much more information than visibilities, such as display frame, display cutout, rounded corners, privacy indicator bounds, and frames of of insets sources. The control target only needs to send the requested visibilities to WMS, so it can be too heavy to use InsetsState. This CL introduces an new class, InsetsVisibilities, which only contains which type has which visibility. So it uses less memory, and it is more efficient on copying and checking the equality. Fix: 194186241 Test: atest InsetsVisibilitiesTest WindowAddRemovePerfTest InsetsControllerTest RegisterStatusBarResultTest CommandQueueTest LightsOutNotifControllerTest ActivityRecordTests DisplayContentTests DisplayPolicyLayoutTests InsetsPolicyTest InsetsSourceProviderTest InsetsStateControllerTest WindowFrameTests WindowManagerServiceTests WindowStateTests Change-Id: I86c1b26b4383bfa3b924726d580e5706e13ba735
* Deleting DisplayContent#reparentDisplayContent and related codeAntonio Kantek2021-05-311-5/+0
| | | | | | | | This code was used by ActivityView (which was deleted) only. Test: manual (seahawk) Bug: 179161778 Change-Id: I65544daac3bc2a280239bdcbd54dc726d604165f
* Copy SurfaceControl object for inprocess calls from WindowlessWindowManager ↵Sakar Khattar2021-03-041-3/+16
| | | | | | | | | to WindowManager Test: Manually tested on device via SurfaceControlViewHost.setView()->WindowlessWindowManager.addToDisplay() Bug: b/171914211 (for original change on rvc-wear-dev) Change-Id: I474949b53c570e01ba678e088a5001618ff0b26e (cherry picked from commit 9eec64f031a1a1992461251ed3451fc48fd59224)
* Added public APIs to generate and validate a DisplayHash.chaviw2021-02-171-4/+3
| | | | | | | | | Added public APIs to call into WindowManagerService, which will then call into DisplayHasherService in mainline. Also, renamed to DisplayHash Test: atest DisplayHashManagerTest Bug: 155825630 Change-Id: I1e10a773fba9471dff41894389e0a9508446d3cc
* Merge "WindowManagerService: Handle transparent region on client" into sc-devRob Carr2021-02-091-4/+0
|\
| * WindowManagerService: Handle transparent region on clientRobert Carr2021-02-081-5/+1
| | | | | | | | | | | | | | | | | | Since the client owns its own SurfaceControl now, there is no need to call through to the WM just to set transparent regions. Bug: 161937501 Test: Existing tests pass Change-Id: I1767090bc60be72b86879ae806876d49bfa0e06c
* | Port SurfaceControlViewHost to BLASTRobert Carr2021-02-081-7/+19
|/ | | | | | | | | | | | | | | This is mostly a matter of flipping the flag, except for the case of SystemWindows. While external SurfaceControlViewHost clients use the leash provided by the SurfaceControlViewHost rather than the internal ViewRootImpl surface, SystemWindows clients will use the actual ViewRootImpl surface. This can conflict with the BLAST adapter setting crop/frame/etc on this Surface. We modify SystemWindows to put each layer inside a leash, and hand this out to other parts of SysUI instead of the ViewRootImpl surface. Test: Existing tests pass Bug: 168505645 Change-Id: Ie621f89166f00ce385d450f1f1cea4d4abd1b805
* Merge "Include whether in touch mode for WindowlessWindowManager" into sc-devChris Li2021-02-081-2/+15
|\
| * Include whether in touch mode for WindowlessWindowManagerChris Li2021-02-061-2/+15
| | | | | | | | | | | | Fix: 179583920 Test: manually with a windowless button Change-Id: Ice37c3182a44c6284ffa8950996507025c59270b
* | Merge "Remove outFrame from the parameters of addWindow" into sc-devTiger Huang2021-02-041-3/+3
|\ \ | |/ |/|
| * Remove outFrame from the parameters of addWindowTiger Huang2021-02-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This CL moves computeWindowBounds to the client side. The client can use it to compute the frame hint on its own. This can be a step to make client compute its window frame locally. Bug: 161810301 BUg: 175858823 Test: atest WindowAddRemovePerfTest ActivityRecordTests DisplayPolicyLayoutTests TaskSnapshotSurfaceTest Change-Id: Ia5af1919b8e0e973646a63d1a4c3bf7ea7e2d1f6
* | Rename ImpressionAttestation to ScreenshotHashchaviw2021-02-021-2/+2
|/ | | | | | | | Rename to reflect what the code is actually doing Test: Builds Bug: 155825630 Change-Id: I7cef8f10d9cc6e6a6a69c5ae6d79e5794b288d96
* Send display cutout to client via insetsChangedTiger Huang2021-01-051-5/+4
| | | | | | | | | | | | | | | | | | | | | Since the display cutout is a type of insets and the display cutout can be obtained from WindowInsets, it makes sense that InsetsState has the display cutout instance. In this way, we can send the display cutout to client via W#insetsChanged instead of W#resized. This can be a step to remove the class of ClientWindowFrames, and can also be a step to make client compute its window frame locally. Fix: 175858810 Bug: 161810301 Test: atest WindowAddRemovePerfTest ImeInsetsSourceConsumerTest InsetsControllerTest InsetsStateTest ViewRootImplTest WindowInsetsControllerTests ActivityRecordTests DisplayPolicyLayoutTests LaunchParamsControllerTests TaskSnapshotSurfaceTest WindowMetricsActivityTests WindowMetricsWindowContextTests WindowMetricsTest WindowFrameTests WindowStateTests WmDisplayCutoutTest Change-Id: I9a930b1d2f7df3cea2b29629b767a4a5f31bca17
* Added support for RootTaskDisplayAreaOrganizerWale Ogunwale2020-12-141-1/+5
| | | | | | | | | | | | | Allows shell to have information on the parent container for tasks so it can do things like attach other surfaces to it. E.g. split-screen divider. Also, have DisplayAreaOrganizer ctor take an executor so incoming calls from the binder threads can be posted to the main thread. Bug: 175416931 Test: They pass! Change-Id: Ia3d0b978cf43badd8c495b75708aa027fe9a2aa1
* Added client requests for ImpressionAttestationchaviw2020-11-241-0/+7
| | | | | | | | | | | | | | | | | | | | | Since the ImpressionAttestation requests will be from outside the system, exposed some methods in IWindowManager and IWindowSession to allow apps to generate the impression token and allow the ads services to validate the token. Most of the methods are passthroughs to ExtServices since client apps cannot directly call into ExtServices For the generateImpressionToken method, WindowManager will look up the information about the window to find it's location in the display. It will then update the bounds passed in so they are in screen space instead of window space. WindowManager will take the screenshot, using the uid from the window session, and send the screenshot to ExtServices. That's where the hash and token will be generated. Test: Builds Bug: 155825630 Change-Id: Iacc6c398794d9a302e4d609a16fa99a810369aff
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 05:08:50 +0000