fix(android/v6): implement native viewType switching in ExoPlayerView#4871
Open
saseungmin wants to merge 2 commits into
Open
fix(android/v6): implement native viewType switching in ExoPlayerView#4871saseungmin wants to merge 2 commits into
saseungmin wants to merge 2 commits into
Conversation
|
Thanks for this, we need it ! 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This fixes Android
viewTypehandling inExoPlayerViewfor the v6 branch.react-native-videoalready exposesviewType/useTextureViewon the JS side, and the Android manager forwards that prop toExoPlayerView.However,
ExoPlayerView.updateSurfaceView()is currently a no-op, so requestingViewType.TEXTUREdoes not actually switch the underlying native view type.This becomes visible in layouts with multiple adjacent videos using
resizeMode="cover"on Android, where the video can render outside of its clipped bounds because the defaultSurfaceViewpath is still used.What changed
updateSurfaceView(viewType)inExoPlayerViewPlayerViewbacked bytexture_viewwhenViewType.TEXTUREis requestedPlayerViewwhen the native view type changesPlayerViewstate after recreationSURFACE_SECUREbehavior when the secure surface type is requestedWhy this is needed
The JS API already supports selecting the Android view type, but the native implementation in
ExoPlayerViewdoes not currently apply that choice.With this change,
viewType={ViewType.TEXTURE}and the deprecateduseTextureViewpath can correctly use aTextureView-backedPlayerView, which makes clipping behavior work as expected in Android UI layouts that rely on view bounds.Scope
This PR intentionally keeps the change limited to the Android
viewTypeimplementation inExoPlayerView.It does not include app-specific behavior changes or unrelated refactors.
Related issues
Notes
PlayerViewdoes not expose a runtime setter forsurface_type, so switching betweensurface_viewandtexture_viewrequires recreating the internalPlayerViewinstance and restoring its state.