Skip to content

[pull] main from expo:main#578

Merged
pull[bot] merged 5 commits intocode:mainfrom
expo:main
Feb 10, 2026
Merged

[pull] main from expo:main#578
pull[bot] merged 5 commits intocode:mainfrom
expo:main

Conversation

@pull
Copy link

@pull pull bot commented Feb 10, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

behenate and others added 5 commits February 10, 2026 12:05
…rray` (#42694)

# Why

On iOS, when using a method that accepts an array as an argument we
convert calls which only provide a single, non-array argument into an
array. e.g.:

`function processArray(arr: Int[]) { ... }`
call:
`processArray(1)` should be equivalent to `processArray([1])`

Our current implementation of `cast(jsValue: JavaScriptValue,
appContext: AppContext)` doesn't take this into account, leading to
crashes.

# How

Handle this case in `DynamicArrayType.swift`

# Test Plan

Tested in BareExpo on iOS, added a couple of unit tests.
# Why

Running `et publish-packages --canary --dry` in the SDK 56 branch does
not generate the expected versions for packages, even when it detects
SDK 56 and the next major.

# How

Instead of maintaining a hardcoded list, we now dynamically determine
which packages should be bumped to the next SDK version by comparing
their current major version to the current SDK major version. If they
match, the package is considered SDK-constrained and will be bumped to
the next SDK version for canary releases (e.g., 55.0.2 →
56.0.0-canary-...).

# Test Plan

Run `et publish-packages --canary --dry` and observe the bumped versions

# Checklist

<!--
Please check the appropriate items below if they apply to your diff.
-->

- [ ] I added a `changelog.md` entry and rebuilt the package sources
according to [this short
guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting)
- [ ] This diff will work correctly for `npx expo prebuild` & EAS Build
(eg: updated a module plugin).
- [ ] Conforms with the [Documentation Writing Style
Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why

When reloading the `sharedObjectDidDeallocate` is correctly called on
the `VideoPlayer` instance, but the actual `ExoPlayer.release` sometimes
won't be called, especially when multiple players are present.
This is because the release calls are queued on `appContext.mainQueue`,
which gets cancelled during the reload.

# How

- Move the release process onto `GlobalScope.launch(Dispatchers.Main)`
which won't get cancelled during a reload.
Since firstFrameEventGenerator `release` also needs to be run on the
main queue during deinit, remove the internal main queue usage and mark
it with a @mainthread annotation.

Also did a few quick changes that don't fix anything, but make the code
a bit safer
- Clear all listeners when releasing
- In `FirstFrameEventGenerator` set onFirstFrameRendered callback to
null, in case it holds a reference to the player.
- Clear the `intervalUpdateClock`

# Test Plan

Tested in BareExpo on Android.
# Why

Closes #37187

While not possible on iOS without hacking, we can relatively easily make
the native controls button visibility configurable on Android.

# How

- Use the provided ExoPlayer methods as well as some manual finding of
views to show/hide parts of the native controls UI.
- Hide the next/previous buttons by default - we are not using a Queue
player so they are not useful anyways

# Test Plan

Tested in BareExpo on Android



https://github.com/user-attachments/assets/c1aeab8c-dfd6-433c-b88a-18e3407b4c8b
@pull pull bot locked and limited conversation to collaborators Feb 10, 2026
@pull pull bot added the ⤵️ pull label Feb 10, 2026
@pull pull bot merged commit 33be413 into code:main Feb 10, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants