Skip to content

android: Integrate ExoPlayer Java components#8094

Open
osagie98 wants to merge 19 commits intoyoutube:mainfrom
osagie98:implement-exoplayer-java
Open

android: Integrate ExoPlayer Java components#8094
osagie98 wants to merge 19 commits intoyoutube:mainfrom
osagie98:implement-exoplayer-java

Conversation

@osagie98
Copy link
Contributor

@osagie98 osagie98 commented Nov 18, 2025

android: Integrate ExoPlayer Java components

This change introduces the core Java classes for the ExoPlayer
rendering implementation on Android. These classes manage the ExoPlayer
instance, facilitate communication between native and Java code,
handle Digital Rights Management (DRM) sessions, and provide the
mechanism for streaming media samples to ExoPlayer.

This is a foundational step to leverage ExoPlayer for media playback,
aiming to improve media capabilities, performance, and compatibility
on Android devices.

Bug: 191693650

@osagie98 osagie98 requested a review from a team November 18, 2025 10:00
@osagie98 osagie98 requested a review from a team as a code owner November 18, 2025 10:00
@osagie98 osagie98 changed the title Implement ExoPlayer Java classes android: Implement ExoPlayer Java classes Nov 18, 2025
@osagie98
Copy link
Contributor Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces the Java-side implementation for ExoPlayer. The overall structure is sound, using a handler to manage ExoPlayer on the main thread and providing a bridge for native code. However, I've identified several high-severity issues related to thread safety, resource management, and performance that need to be addressed. Specifically, there's a critical issue in ExoPlayerCodecUtil that could lead to a crash, concurrency problems in ExoPlayerBridge, and a performance bottleneck in ExoPlayerSampleStream due to frequent object allocations. I've also included some medium-severity suggestions to improve code robustness and logging practices.

exoplayerHandler.postDelayed(this::updatePlaybackPos, 150);
}

public void destroy() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: to make the function name more consistent with other media components, I feel release can be a better name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

private static final int MAX_BUFFER_DURATION_MS = 5000; // 5 seconds.
// Based on the requirement to begin playback if at least 500 milliseconds of media has been
// appended.
private static final int MIN_BUFFER_DURATION_MS = 450;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment says it needs at least 500ms of data, but MIN_BUFFER_DURATION_MS is 450, which is confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a comment to clarify

@osagie98
Copy link
Contributor Author

osagie98 commented Jan 9, 2026

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request implements the Java-side classes for ExoPlayer-based rendering. The changes include adding new classes for managing the ExoPlayer instance, handling media sources, and streaming samples, along with updating the build configuration. The new classes are well-structured and follow common ExoPlayer integration patterns.

My review has identified a few issues:

  • A critical logic error in ExoPlayerMediaSource.canAcceptMoreData() that could lead to a NullPointerException or incorrect buffer management.
  • A high-severity bug in ExoPlayerBridge.getCurrentPositionUsec() where the playback rate is not considered for position extrapolation.
  • A high-severity race condition in several ExoPlayerBridge methods that could lead to a crash during player release.
  • A minor typo in a log message.

I've provided suggestions to fix these issues. Addressing them will improve the robustness and correctness of the implementation.

@osagie98 osagie98 requested a review from jasonzhangxx January 9, 2026 22:00
@osagie98
Copy link
Contributor Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces the Java-side implementation for ExoPlayer, including bridges for communication with native code, DRM handling, and media source management. The changes are extensive, adding several new classes to support the ExoPlayer pipeline. The code is generally well-structured, using appropriate Android and ExoPlayer patterns. I've identified a few areas for improvement, mainly concerning exception handling correctness and documentation clarity. Specifically, there's an issue with exception types in the DRM bridge and several instances of incorrect Javadoc comments that should be addressed to improve maintainability.

return mPendingProvisionRequestResponse.get(
PROVISION_REQUEST_TIMEOUT_MS, TimeUnit.MILLISECONDS);
} catch (Exception e) {
throw new RuntimeException(e);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The executeProvisionRequest method is declared to throw MediaDrmCallbackException, but it currently catches a generic Exception and wraps it in a RuntimeException. This violates the method's contract. You should wrap the caught exception in a MediaDrmCallbackException to conform to the interface.

Suggested change
throw new RuntimeException(e);
throw new MediaDrmCallbackException(e);

@osagie98
Copy link
Contributor Author

/generate-commit-message

@github-actions
Copy link
Contributor

🤖 Gemini Suggested Commit Message


android: Integrate ExoPlayer Java components

This change introduces the core Java classes for the ExoPlayer
rendering implementation on Android. These classes manage the ExoPlayer
instance, facilitate communication between native and Java code,
handle Digital Rights Management (DRM) sessions, and provide the
mechanism for streaming media samples to ExoPlayer.

This is a foundational step to leverage ExoPlayer for media playback,
aiming to improve media capabilities, performance, and compatibility
on Android devices.

Bug: 191693650

💡 Pro Tips for a Better Commit Message:

  1. Influence the Result: Want to change the output? You can write custom prompts or instructions directly in the Pull Request description. The model uses that text to generate the message.
  2. Re-run the Generator: Post a comment with: /generate-commit-message

@osagie98 osagie98 changed the title android: Implement ExoPlayer Java classes android: Integrate ExoPlayer Java components Feb 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants