[video_player_android] Avoid sending unset duration on initialization

[dao-wkm]

Description

Fixes flutter/flutter#176575

Avoid sending an initialized event with an unset duration in video_player_android.

On Android, ExoPlayer can briefly report C.TIME_UNSET for non-live, non-dynamic media when playback first reaches STATE_READY. That value can be converted into an invalid Duration on the Dart side, causing some videos to report a duration such as 0:00:00.001000.

This PR delays sending the initialized event until a valid duration is available for regular media. It also listens for timeline updates and retries initialization when the timeline becomes ready. A short fallback timeout is kept so initialization is not blocked indefinitely if a valid duration is never reported.

Breaking Changes

None - all changes are additive and backward compatible.

Pre-Review Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools.
• I read the [Tree Hygiene] page, which explains my responsibilities.
• I read and followed the [relevant style guides] and ran [the auto-formatter].
• I signed the [CLA].
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I [linked to at least one issue that this PR fixes] in the description above.
• I followed [the version and CHANGELOG instructions], using [semantic versioning] and the [repository CHANGELOG style], or I have commented below to indicate which documented exception this PR falls under[^1].
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
• All existing and new tests are passing.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request modifies ExoPlayerEventListener to delay the initialization event until a valid media duration is available, implementing a 500ms fallback mechanism using a Handler. Feedback suggests adding a release method to cancel pending callbacks and prevent potential crashes upon disposal. Additionally, the reviewer recommended ensuring the fallback timer is not repeatedly reset and requested the inclusion of unit tests to verify the new logic and timeout behavior.