If the player is created on a background thread (which is allowed as the only exception to the access-on-one-thread-only rule), it may happen that a callback on the main thread tries to access the player before the constructor even finished. This is dangerous and can cause exceptions due to uninitialized variables. To solve this, we can make sure that every player access is blocked until the constructor finished. Blocking is safe because the constructor itself is not doing any blocking work or acquiring locks. The thread verification method is already called on every entry point to the player, so we can reuse the same method for checking. PiperOrigin-RevId: 365792949
| Name |
Last commit
|
Last Update |
|---|---|---|
| .github/ISSUE_TEMPLATE | Loading commit data... | |
| .idea | Loading commit data... | |
| demos | Loading commit data... | |
| extensions | Loading commit data... | |
| gradle/wrapper | Loading commit data... | |
| library | Loading commit data... | |
| playbacktests | Loading commit data... | |
| robolectricutils | Loading commit data... | |
| testdata | Loading commit data... | |
| testutils | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .hgignore | Loading commit data... | |
| CONTRIBUTING.md | Loading commit data... | |
| LICENSE | Loading commit data... | |
| README.md | Loading commit data... | |
| RELEASENOTES.md | Loading commit data... | |
| build.gradle | Loading commit data... | |
| common_library_config.gradle | Loading commit data... | |
| constants.gradle | Loading commit data... | |
| core_settings.gradle | Loading commit data... | |
| gradle.properties | Loading commit data... | |
| gradlew | Loading commit data... | |
| gradlew.bat | Loading commit data... | |
| javadoc_combined.gradle | Loading commit data... | |
| javadoc_library.gradle | Loading commit data... | |
| javadoc_util.gradle | Loading commit data... | |
| publish.gradle | Loading commit data... | |
| settings.gradle | Loading commit data... |