summaryrefslogtreecommitdiff
path: root/core/java/android/view/SurfaceView.java
Commit message (Collapse)AuthorAgeFilesLines
* SurfaceView: Revert SurfaceLock locking changesVishnu Nair2022-08-121-106/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 9e3cd0533fa4dbca75d65750f9ffcd9817779c3c and commit 74c760394aacd5a57ba0acade8cb8151ba14678c. Initially we made a change to address a performance issue in SurfaceView caused by holding the mSurfaceLock whenever we went though the updateSurfaces loop. This had a side effects of causing an ANR since the locking order changed. The followup fix removed the lock but broke some API contracts around lock and unlock canvas. Subsequent fixes, which never went into QPR, introduced new issues. Changing the locking order is too risky QPR so lets revert and try to rework the locking mechanism in U. Test: app in b/234006724 does not ANR Test: app in b/235188096 does not crash Test: app in b/239895124 does not ANR Test: app in b/239142077 does not crash Test: atest SurfaceViewTest Bug: 235188096 Change-Id: I99c5bb707ecad7c8d3c1fbd8b4105a77d58c145d
* Make sure VRI waits for SV to draw before reportchaviw2022-06-101-1/+37
| | | | | | | | | | | | | | | | | | VRI is not currently waiting for SV to draw since SV may start its draw before VRI opened the SyncSet. If that happens, VRI will not include SV in its SyncSet and report draw finished even if SV is not complete. This fix has SV create its own SyncSet when redrawNeeded. Then if VRI creates a sync, SV will merge its own SyncSet into that one. If SV already finished drawing, then nothing will get merged, but it means SV is ready already. If SV is not finished, VRI will now also wait for SV's draw to finish before calling finishDraw. Test: Long delay in surfaceRedrawNeededAsync Test: SurfaceSyncerTest Bug: 230998394 Change-Id: I44331b8f54951e6dc633a4845bbf690abde0f95e
* Remove lock when calling Surface.destroychaviw2022-05-311-7/+2
| | | | | | | | | | Surface already has a lock on the native object so it's safe to call destroy without holding additional locks. This also fixes ANR issues where an app is still attempting to render when the window is destroyed. Test: App from bug doesn't ANR Bug: 234006724 Change-Id: I0d323c03f299e5857d1950870498f3182d019924
* Merge "ViewRootImpl/SurfaceView: Listen for queue stalls" into tm-devRob Carr2022-05-051-0/+2
|\
| * ViewRootImpl/SurfaceView: Listen for queue stallsRobert Carr2022-04-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Native machinery now reports queue stalls from native layer up to java layer, which can more appropriately handle errors. The first case we handle is the case of "stuck fences", generally indicating GPU hangs. In this case we trigger a bespoke ANR rather than waiting for an ANR in dequeueBuffers later. dequeueBuffers ANR could have any number of causes, and this large cluster is difficult to debug. Bug: 216160569 Test: Existing tests pass Change-Id: I7b4429ce96d0bbfa1b74534ddf2b447facb22d10
* | SurfaceView: Fix overlocking of mSurfaceLockRobert Carr2022-05-041-104/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mSurfaceLock is used to ensure the Surface object stays valid over the span of the calls to lockCanvas and unlockCanvasAndPost which could come from any thread. In API Level 29 and below, updateSurface was split in to two paths, a first path (which would acquire mSurfaceLock) for when the Surface could be destroyed, and second path for geometry updates only. The consolidation of these two paths in updateSurface created an overlocking of mSurfaceLock, which is now acquired even when mSurface won't be modified. In fact it's acquired whenever the geometry changes. This means an application rendering thread which creates delays between lock and unlock canvas could create undesirable and needless delays on the main UI thread, if the SurfaceView geometry updates. We also have some underlocking, where we aren't actually locking when destroying the SurfaceView. Test: Manual with test app Bug: 206846658 Change-Id: Idc17d111eee7a7365af4e94a156e7c46c7ea8171
* | Merge "Fix InlineFilteringTest#testFiltering_filtersByPrefix" into tm-devRyan Lin2022-04-191-4/+4
|\ \ | |/ |/|
| * Fix InlineFilteringTest#testFiltering_filtersByPrefixryanlwlin2022-04-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | The window matrix of the embedded window is not updated if the second host SurfaceView doesn't have any offset. To esnure the window matrix is up-to-date, we force to update the matrix when the embedded hierarchy is initialized. Bug: 229178859 Test: atest InlineFilteringTest#testFiltering_filtersByPrefix atest android.accessibilityservice.cts Change-Id: Ib23af520fcbaa1788e3ef22a1086b90a0801375c
* | SurfaceView: Ensure position update listener sets at least onceRobert Carr2022-04-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | If we destroy and recreate a SurfaceView in the same frame its possible for positionChanged for the new surface to arrive before positionLost for the old surface. In this case we won't clear mRtLastReportedPosition, and so we won't set any position at all on the new surface. Bug: 229052731 Test: Existing tests pass Change-Id: I896496afa5b05848f96b20697d33911cae9639a7
* | Merge "Set mSyncBuffer to true when VRI did not initiate the sync request" ↵Chavi Weingarten2022-04-141-1/+1
|\ \ | |/ |/| | | into tm-dev
| * Set mSyncBuffer to true when VRI did not initiate the sync requestchaviw2022-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VRI can initiate syncs, but they can also happen from other places when using SurfaceSyncer. When VRI initiates the sync, sometimes the buffer needs to be synced. Other times, we just want to know the buffer has drawn, but don't actually need to sync the buffer. When a sync is initiated from outside VRI, using SurfaceSyncer, we always want to sync the buffer. This change ensures that if the sync was started from an outside request, it will set mSyncBuffer to true. An additional part to clarify the sync logic, renamed mLastSyncId to mSyncId and renamed isInSync to isInLocalSync to clarify that the mSyncId only represents VRI initiated syncs. Test: Internet Dialog syncs buffer Fixes: 229098223 Change-Id: I99e9e6341a487d59c33a33a61e442be7909518c2
* | Change node bounds procedure based on SufaceFlinger Callbackryanlwlin2022-04-121-1/+6
|/ | | | | | | | | | | | | | | | | | | | The attachInfo from ViewRootImpl is not reliable for DisplayArea manipulation or windowless window. To fix this problem, we use the transform matrix of InputWindowHandle, which could transform the bounds from window coorindate to screen coordinate. We also transfrom the bounds to logical display coordinates with the associated display matrix. Besides, we also record the magnification spec of the window, which could get the bounds before magnification. We use this value to decide the property 'visibleToUser'. Bug: 200797785 Test: atest android.accessibilityservice.cts WindowInfoTest atest com.android.server.accessibility Change-Id: I0917b04fe8b027fb2bd932a6f0604ba1449ebc66
* Clean up buffer sync logic in SurfaceView.chaviw2022-03-241-29/+35
| | | | | | | | | The current code is a bit confuisng to read so cleaned up the code that handles syncing a buffer when a VRI relayout request creates a sync. Test: YT, Camera, Chrome Bug: 200284684 Change-Id: I243ee5ebcb59c478c48461544813cab43a2678d4
* Replace VRI and SV sync logic with SurfaceSyncerchaviw2022-03-231-68/+77
| | | | | | | | | | | | Instead of using the count to keep track of sync information in VRI, use the SurfaceSyncer to handle this. This also means changing SV since SV would also increment the VRI counter. This cleans up the logic since code that's used for the SurfaceSyncer can be re-used in VRI. Test: seamless rotation, launching apps Bug: 200284684 Fixes: 225776224 Change-Id: Idb505b35eef9f99b2f76e9d1f1b26f5c50ed9a90
* Revert "Replace VRI and SV sync logic with SurfaceSyncer"Gary Lin2022-03-211-77/+68
| | | | | | | | This reverts commit f37c024b0049b9cc849c8216fd64c7a7d471fae3. Reason for revert: Google Camera App has black preview Change-Id: Ib691cc8f9a80412756855e5dd7bcc2a12f842ce9
* Replace VRI and SV sync logic with SurfaceSyncerchaviw2022-03-171-68/+77
| | | | | | | | | | | Instead of using the count to keep track of sync information in VRI, use the SurfaceSyncer to handle this. This also means changing SV since SV would also increment the VRI counter. This cleans up the logic since code that's used for the SurfaceSyncer can be re-used in VRI. Test: seamless rotation, launching apps Bug: 200284684 Change-Id: Ia3c1a13b42ceba29a75425295e41e543a00436a3
* Merge "Changed setSyncTransaction to syncNextTransaction with callback ↵Chavi Weingarten2022-03-031-11/+22
|\ | | | | | | logic." into tm-dev
| * Changed setSyncTransaction to syncNextTransaction with callback logic.Tianhao Yao2022-03-021-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Modified SurfaceView and ViewRootImpl to provide callbacks when syncing a transaction instead of sending transactions. This will ensure a clear ownership of the transaction object since it will be provided in the callback when BBQ adds a buffer into the transaction. Modified JNI to add compatibility for native functions. Test: Manual testing from go/wm-smoke. Test: BLASTBufferQueueTest Bug: 210714235. Change-Id: I1f872d6b2846b0d64d5b33b8866d0b2ec7126c8c
* | SurfaceView: Synchronize all surface view changes with VRI drawVishnu Nair2022-03-031-107/+75
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re landing with the following changes: We initially cloned the SurfaceControl handle to avoid locking when accessing the SurfaceControl from the position listener callbacks running from RT workers. But this meant the last reference to the layer handle would only be released by GC. If SurfaceViews are created and destroyed rapidly, we would be at the mercy of GC to release buffers. Original change: There are three transaction queues that can submit SurfaceView changes. 1. Buffer updates via BBQ apply token 2. SCC apply token 3. ViewRootImpl BBQ apply token It makes sense for most SurfaceView changes to be synchronized with ViewRootImpl draws since the caller can optionally synchronize the change with main window content. This change eliminates the tmp transaction that is applied directly via the SCC apply token and instead applies them with the ViewRootImpl draw transaction. Also take the opportunity to scope down mSurfaceControlLock usage. Test: atest SurfaceViewSyncTest Test: go/wm-smoke Test: run mem tests via forrest Bug: b/217973491, b/221631942 Change-Id: Idba712d146e62d7346920dc4f060cba92d47fada
* Merge "Revert "SurfaceView: Synchronize all surface view changes with V..."" ↵TreeHugger Robot2022-03-011-86/+117
|\ | | | | | | into tm-dev
| * Revert "SurfaceView: Synchronize all surface view changes with V..."Vishnu Nair2022-03-011-86/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "SurfaceView: Avoid destination frame updates on multipl..." Revert submission 16944940-sv-changes-tm-dev Reason for revert: b/221631942 Reverted Changes: I0d214e3f7:SurfaceView: Avoid destination frame updates on m... I0b5741b37:SurfaceView: Synchronize all surface view changes ... I5226c304b:SurfaceView: Avoid destination frame updates on mu... Change-Id: I35b7c1be7202ebe89a5309284a9401c8084e9d79
* | Merge "Add SurfaceSyncer class" into tm-devChavi Weingarten2022-02-281-0/+7
|\ \ | |/ |/|
| * Add SurfaceSyncer classchaviw2022-02-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add Syncer class that allows callers to add desired syncs into a set and wait for them to all complete before getting a callback. The purpose of the Syncer is to be an accounting mechanism so each sync implementation doesn't need to handle it themselves. The Syncer class is used the following way. 1. SurfaceSyncer#setupSync is called 2. addToSync is called for every SyncTarget object that wants to be included in the sync. If the addSync is called for a View or SurfaceView it needs to be called on the UI thread. When addToSync is called, it's guaranteed that any UI updates that were requested before addToSync but after the last frame drew, will be included in the sync. 3. SurfaceSyncer#markSyncReady should be called when all the SyncTargets have been added to the SyncSet. Now the SyncSet is closed and no more SyncTargets can be added to it. 4. When all SyncTargets are complete, the final merged Transaction will either be applied or sent back to the caller. The following is what happens within the SyncSet 1. Each SyncableTarget will get an onReadyToSync callback that contains a SyncBufferCallback. 2. Each SyncableTarget needs to invoke SyncBufferCallback#onBufferReady. This makes sure the SyncSet knows when the SyncTarget is complete, allowing the SyncSet to get the Transaction that contains the buffer. 3. When the final FrameCallback finishes for the SyncSet, the syncRequestComplete Consumer will be invoked with the transaction that contains all information requested in the sync. This could include buffers and geometry changes. The buffer update will include the UI changes that were requested for the View. Test: SurfaceSyncerTest Test: SurfaceSyncerContinuousTest Bug: 200284684 Change-Id: Iab87bff8a0483581e57803724eae88f0a3d96c8e
* | SurfaceView: Synchronize all surface view changes with VRI drawVishnu Nair2022-02-191-117/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are three transaction queues that can submit SurfaceView changes. 1. Buffer updates via BBQ apply token 2. SCC apply token 3. ViewRootImpl BBQ apply token It makes sense for most SurfaceView changes to be synchronized with ViewRootImpl draws since the caller can optionally synchronize the change with main window content. This change eliminates the tmp transaction that is applied directly via the SCC apply token and instead applies them with the ViewRootImpl draw transaction. Also take the opportunity to scope down mSurfaceControlLock usage. Test: atest SurfaceViewSyncTest Test: go/wm-smoke Bug: 217973491 Change-Id: I0b5741b376e042537c37ec34644e0a048eb4bfe0
* | SurfaceView: Avoid destination frame updates on multiple threads 1/2Vishnu Nair2022-02-191-4/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | The caller such as SurfaceView can optionally apply destination frame changes if they wish to synchronize buffer scale with other scales in the hierarchy. This is hard to synchronize if the buffer scale changes, since in fixed scaling mode we want the destination frame to be applied when a buffer of the new size is queued. This approach is brittle because SurfaceView does not have control over the buffer production and the app can get into a scenario where there is scaled incorrectly. Fix this by configuring BBQ to always apply destination frame changes or always defer to the caller. If the scaling mode is freeze, then BBQ will set a flag to ignore the destination frame. This allows us to synchronize destination frame changes with scale applied by a parent and avoid unwanted scaling if the scaling mode changes to freeze. Test: atest SurfaceViewTest Test: go/wm-smoke Bug: 217973491 Change-Id: I5226c304bae9dde890306f8528dfeabf6b015a32
* SurfaceView: Clean up synchronized changes with applyTransactionOnVriDrawVishnu Nair2022-02-111-163/+33
| | | | | | | | | Replace existing synchronization logic with calls to ViewRootImpl#applyTransactionOnDraw. There is no functional change. Test: presubmit Bug: 217973491 Change-Id: I3b1416c2889d2c3b5c3833ffab4e28a9e0eb5d76
* SurfaceView: Don't reparent SurfacePackage on releaseRobert Carr2022-02-091-4/+0
| | | | | | | | | | | | | | There is no need to reparent the SurfacePackage to null, if the SurfaceView is destroyed it will naturally die, if it's not it will persist which actually may be the intended behavior if we are in some sort of exiting state. More so, it creates possible confusion around releasing one SurfaceView while reparenting the SurfacePackage to another. Bug: 196926363 Bug: 217973491 Test: SurfaceViewSurfacePackageValidatorTest#testSurfacePackageNoFlicker Change-Id: I4f93c4a6928f6b47371d0a264f1fc99c4e82819f
* SurfaceView: Synchronize add/remove SurfacePackage with VRI drawVishnu Nair2022-02-091-59/+37
| | | | | | | | | | Apply the SurfacePackage reparent transactions with the next ViewRootImpl draw so the caller can optionally synchronize attaching SurfacePackages with contents on the main window. Test: atest CtsWindowManagerDeviceTestCases:SurfaceControlViewHostTests Bug: 217973491 Change-Id: I87f77cb6a5a2505592f6e9431d2964517fe497cd
* SurfaceView: Remove blast debug flagVishnu Nair2022-02-071-91/+23
| | | | | | | | | BufferStateLayer is the now the default interface to SurfaceFlinger and BufferQueueLayer code path is obsolete and non-functional. Test: presubmit Bug: 217973491 Change-Id: I0d083230f3a27d4b0380a1d958fdc5c1b6c3aa51
* Merge "SurfaceView: Synchronize visibility changes with VRI frame"Vishnu Nair2022-01-061-2/+2
|\
| * SurfaceView: Synchronize visibility changes with VRI frameVishnu Nair2022-01-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a flicker in wallpaper picker due to a recent change where SurfaceView creation changes were synchronized with VRI frame. This breaks wallpaper picker because wallpaper picker doesn't actually draw into the SV surface, instead they attach a surface package. The current implementation meant the SurfacePackage would be visible before it was scaled correctly. This fix applies the visibility changes along with the scaling changes. Test: steps in b/211945947 Fixes: 211945947 Change-Id: I4e5107ac2caf634429e1bec3201fdcaa8f5f92bc
* | SurfaceView: Fix unsafe transaction accessesVishnu Nair2021-12-231-56/+49
|/ | | | | | | | | | | | | | | | | | PositionUpdateListener callbacks maybe replaced before they are applied. We need to merge with the existing transaction so we don't drop any destination frame updates. But accessing the previous callback transaction is unsafe since we might fight with render thread. Fix this by locking access to the transaction object. This also fixes a potential SurfaceControl access issue where we may release the SurfaceControl that is used by render thread in the UI thread. Fixes: 211090247 Test: atest SurfaceViewSyncTest Change-Id: I28ed344754601169c6cefd919668e76ef5a467c3
* SurfaceView: Synchronize initial destframe change from BBQVishnu Nair2021-12-071-17/+30
| | | | | | | | | | | | | | | | | | | | | | | | Fixes a case where the SurfaceView is stuck with a wrong scale. Destination frame scales the buffer to the SurfaceView fixed size. Currently the initial destination frame is applied when the first buffer is acquired by BBQ. The transaction is sent via the BBQ apply token. Meanwhile if the client updates the SurfaceView fixed size, the SurfaceView will apply the transaction via the SCC apply token. This can cause destframe changes to be applied out of order causing the app to be stuck with the wrong scale. Bug: 195443440 Test: atest BLASTBufferQueueTest Test: repro steps from bug Change-Id: Ibf53a0efdebb87291d081e48633c373a98d347b1
* Synchronize SV buffers with main window when config changeschaviw2021-12-011-6/+19
| | | | | | | | | | | | | | | When the main window gets a configuration change, the new buffer for the SV will get applied in the same transaction as the main window. This will allow apps to implement seamless rotation without a frame or more of black where the SV was resized, but the buffer was not yet updated. This also includes an optimization where if only SV change occurs, but there was no request from WMS to report drawing, VRI can apply the transaction immediately without reporting to WMS. Test: SV with seamless rotation enabled Bug: 200284684 Change-Id: I5569d815eef92acf3bf9d7f753bd5ab94a332cfe
* Merge "Call applyTransactionOnDraw when removing SV" into sc-v2-dev am: ↵Chavi Weingarten2021-11-091-22/+7
|\ | | | | | | | | | | | | | | 41d736717e am: 47dd5b7ba1 Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/16192255 Change-Id: I14dfbc7a4a106909dd085e380df4caea719d2f16
| * Call applyTransactionOnDraw when removing SVchaviw2021-11-041-22/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When SV is detached, we will try to clean up the SurfaceControls. However, we want the clean up to be synced with the main app window. This is to ensure we don't remove SV's SC before the app window draws in the hole punched area. Instead of relying on postionLost to synchronize with the main app window, we can use applyTransactionOnDraw to ensure the next frame will merge the remove transaction. Therefore, we no longer have to call remove in positionLost since it's already handled elsewhere. Test: No flicker when removing SV Bug: 199860472 Change-Id: I93a91c45c862949e53ee9fd1b4a3b10404fba6bb
* | Merge "ViewRootImpl: Replace usage of orientation with buffer transform for ↵Vishnu Nair2021-10-141-1/+1
|\| | | | | | | | | | | | | | | transform hint" into sc-v2-dev am: fb19c89e4d am: dd8c200bd2 Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/16040767 Change-Id: If7b74fa458c0a2ee14b876a2b3b8fe393fcc85cb
| * Merge "ViewRootImpl: Replace usage of orientation with buffer transform for ↵Vishnu Nair2021-10-141-1/+1
| |\ | | | | | | | | | transform hint" into sc-v2-dev
| | * ViewRootImpl: Replace usage of orientation with buffer transform for ↵Vishnu Nair2021-10-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | transform hint Fixes: 202797234 Test: atest VulkanPreTransformTest#testVulkanPreTransformNotSetToMatchCurrentTransform Change-Id: Iddb2e0b045096b4b86c0bc3f8222b61de67994bc
| * | Merge "Fixes the flicker when transfer splash screen view to client" into ↵Wei Sheng Shih2021-10-131-2/+29
| |\ \ | | |/ | |/| | | | sc-v2-dev
| | * Fixes the flicker when transfer splash screen view to clientwilsonshih2021-10-061-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use applyTransactionOnDraw to ensure all transaction happen during the same frame, including - hide the starting window. - reparent the remote SurfaceView to client. Bug: 198593932 Test: continues launch test app several times then verify with winscope to ensure there is no flicker anymore. Merged-In: I03c600afdc477ca0c8064b215f2b361468db9f3c Change-Id: I03c600afdc477ca0c8064b215f2b361468db9f3c
* | | Merge "Rename getSurfaceTransformHint API and switch to using NDK transform ↵TreeHugger Robot2021-10-121-3/+3
|\| | | | | | | | | | | | | | | | | | | | | | | constants" into sc-v2-dev am: 492bdf0074 am: 030cee8122 Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15937682 Change-Id: Ib479110b56925fc373eeee1a2398fd9ad2e46fb7
| * | Rename getSurfaceTransformHint API and switch to using NDK transform constantsVishnu Nair2021-10-111-3/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | NDK exposes ANativeWindowTransform/NATIVE_WINDOW_TRANSFORM_*. These constants are aligned with HAL definitions and are used internally to specify buffer transforms. Native consumers of the transform hint are expected to generate ANativeWindowTransform from the hint. Aligning the SDK and the NDK transform values will make the API less confusing. Bug: 196167822 Test: atest AttachedSurfaceControlTest Change-Id: Ib20be045f6c8c6d7befef93a839a27098da55ffa
| * SurfaceView: Fix SurfaceControl synchronization issuesVishnu Nair2021-09-131-18/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hold the surface control lock in PositionUpdateListener callbacks before checking if the SurfaceControl will be null. UI tread might release it after the checks causing crashes. Also fix a case where the ViewRootImpl may be null in the positionChanged callback. Bug: 199261027 Test: run steps in bug Test: go/wm-smoke Change-Id: I5a4cac35fe14356389b29268fddf9703b25c03aa (cherry picked from commit 2cafd8b44d0b4c13b16fdcd2557352ec5496fcc3)
* | Fixes the flicker when transfer splash screen view to clientwilsonshih2021-10-051-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | Use applyTransactionOnDraw to ensure all transaction happen during the same frame, including - hide the starting window. - reparent the remote SurfaceView to client. Bug: 198593932 Test: continues launch test app several times then verify with winscope to ensure there is no flicker anymore. Change-Id: I03c600afdc477ca0c8064b215f2b361468db9f3c
* | Merge "SurfaceView: Fix SurfaceControl synchronization issues"TreeHugger Robot2021-09-131-18/+20
|\ \
| * | SurfaceView: Fix SurfaceControl synchronization issuesVishnu Nair2021-09-091-18/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hold the surface control lock in PositionUpdateListener callbacks before checking if the SurfaceControl will be null. UI tread might release it after the checks causing crashes. Also fix a case where the ViewRootImpl may be null in the positionChanged callback. Bug: 199261027 Test: run steps in bug Test: go/wm-smoke Change-Id: I5a4cac35fe14356389b29268fddf9703b25c03aa
* | | Merge "Surface: Release references to BlastBufferQueue and SurfaceControl on ↵Vishnu Nair2021-09-031-1/+1
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | Surface#destroy" into sc-v2-dev am: 8047839069 am: 28bcedef70 Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15720362 Change-Id: Ic9d63f73755f79e96c13c8983920b8184f77a29f
| * | Surface: Release references to BlastBufferQueue and SurfaceControl on ↵Vishnu Nair2021-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Surface#destroy SurfaceView clients may hold on to surface references. In S this means they would extend the lifetime of the SurfaceControl resulting in "leaking" buffers until the references are cleared or the app is terminated. Fix this by calling a new destroy function on Surface which will explicitly remove references to the SurfaceControl and BBQ it holds. This is safe because SurfaceView controls the lifecycle of the Surface and knows when the Surface will become invalid. Once invalid, the Surface cannot become valid again. Test: repro steps in bug Bug: 198133921 Change-Id: I5c7e43736f025fc0965eae2f19719ba40df3cb70
| * | Merge "SurfaceView: Synchronize position updates with fixed size changes" ↵Vishnu Nair2021-08-051-56/+95
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | into sc-dev am: 5d7ae9063a Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15462690 Change-Id: If91aa26d1fbfe17f7dd4c2e5e417c58ba03c0874
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 20:42:09 +0000