[0.79] Fix legacy architecture Android freeze on metro refresh

[simarmol]

Target Branch

0.79

Link to commit or PR to be picked

react/react-native#52515

Description

See react/react-native#50274 , react/react-native#52515 and react/react-native@c43952a . This is porting a fix from 0.77 into 0.79 to make it possible to refresh the app while debugging an Android app in the legacy architecture.

I believe this cannot be PRd into main since the legacy architecture is frozen and this does not impact the new architecture. I have picked the commit from 0.77 which as far as I know is the closest version where the issue has been fixed

[react-native-bot]

Thank you for opening a new pick-request for React Native.
Those are the criterias we follow when accepting/rejecting a pick request (source).

If your pick does not satisfy the criteria below, please close it as it will not be considered.

✅ Which pick requests we accept

1. ✅ Fixes for regressions to core APIs. Examples:
   • A core component is behaving differently between version 0.X and 0.X-1
   • The TurboModule.getEnforcing function is throwing an assertion error which is not expected.
2. ✅ Fixes to bugs in the core React Native’s experience. Examples:
   • Breakpoints in React Native DevTools not working correctly in the debugger
   • Fast Refresh not working as expected
   • Metro bundler not starting properly or ignoring the configuration file
   • Buttons that are not clickable
3. ✅ Fixes to APIs used by 3P libraries and Out-of-tree platforms. Examples:
   • An API that is used by react-native-macos is not behaving as expected or regressing
4. ✅ Bump of patch version of dependencies. Example:
   • Bump Gradle from 8.11.0 to 8.11.1
5. ✅ Fixes for Low/High Security Vulnerability. Example:
   • Bump Gradle from 8.11.0 to 8.12.0 if there is a security vulnerability in 8.11 and there is no version 8.11.x which would contain the same fix.
6. ✅ Fixes and reverts of accidental breaking changes. Example:
   • Reverting or fix-forwarding a migration to Kotlin of a file (say ReactRootView.java ) if that is causing a breaking change for the whole React Native ecosystem.
7. ✅ Performance improvements picks. Examples:
   • Fixing unnecessary rendering on FlatList.
8. ✅ Any pick if the release is still in RC0 (after RC1 the previous listed criteria applies)

❌ Which pick requests we don’t accept

9. ❌ Any pick that will introduce a breaking change after RC1. Example:
   • A bugfix that contains a refactoring, resulting in changes to the public API of a class
10. ❌ Any pick that introduces a new feature after RC1. Example:
    • A commit that introduces a new API or a specific feature for a component.
11. ❌ Bump of major/minor version of dependencies. Example:
    • Bump Gradle from 8.11.0 to 8.12.0
    • Bump Gradle from 8.11.0 to 9.0.0
12. ❌Bump of a dependency to a non stable/alpha/beta version. Example:
    • Bump Gradle from 8.11.0 to 8.11.1-beta.1
13. ❌Any pick that introduces changes to the testing infrastructure of React Native after RC1. Examples:
    • Changes to the GitHub Actions workflows to optimize it, even if they’re on main.
    • Changes to the logic used to publish packages to NPM or Maven Central
14. ❌ Pick composed by various commits that has several merge conflicts
    • If your pick is too complicated to apply on the release branch, we’re going to reject it.
15. ❌ Any other non-critical improvement that landed on main.
    • In general those will ship in the following version unless they fit in one of the criteria above
16. ❌ Any other pick which is considered “small enough” to make it into a release.
    • If your pick is a one liner but is a ‘nice to have’, we won’t be picking it, as it has the risk of destabilizing the release and further delaying the release.

ℹ️ What makes for a good pick

In order for your pick to be considered, please do the following:

• ℹ️ Have a pick that contains only one commit from main, or only one PR against the release branch.
• ℹ️ Have a clear explanation of why your pick should be considered, ideally referencing one of the criteria above.
• ℹ️ Target only one minor version of React Native (e.g. [0.76]). If you want your pick to be applied to more versions, please open different picks.

[ChrisZilch]

@cortinico it would be great if we could get this into a 0.79 patch please, this is blocking us on the old architecture 🙏

[cortinico]

@cortinico it would be great if we could get this into a 0.79 patch please, this is blocking us on the old architecture 🙏

As you can imagine, our priority is New Architecture. You should consider migrating to it as soon as possible. We'll include this in a 0.79 patch whenever we have capacity

[ChrisZilch]

Thanks for looking so quickly!

I can appreciate that, the New Architecture is really exciting and I know it is being prioritised (we're mid-migration right now), but with 0.77 having reached EOL it's not currently possible to upgrade to a supported version for those of us who are still in the process of migrating 🙁.

Do you have any estimate as to when you guys might get any capacity to do a patch?

Thanks!

[cortinico]

Do you have any estimate as to when you guys might get any capacity to do a patch?

usually within a couple of weeks, up to a month

[RoryZilch]

@cortinico This is quite important for us for the following reason:

• The Google Play store is requiring us to target API level 35 by August 31st or we won't be able to release future versions of our app.
• We're using expo with react native, and therefore in order to target API 35 safely we need to be on expo 53 and also need react native 79 to support this.

If it's going to be up to a month to merge the patch this is cutting it very close.

Any chance of getting this merged a little bit sooner? 🙏🏻

[cortinico]

@RoryZilch what's preventing you from moving to New Arch?

[RoryZilch]

@cortinico Other dependencies mostly, reanimated for example is causing a multitude of issues with the new arch enabled.

[RoryZilch]

The other simply being time, we have an epic to resolve all of the issues we've found. We'd love to migrate as soon as possible and fully intend to in the next few months, but must maintain all of our current functionality and stability whilst doing so.

[cortinico]

@cortinico Other dependencies mostly, reanimated for example is causing a multitude of issues with the new arch enabled.

Can you be more specific? Reanimated just release v4 which is New Arch only so I'm curious to hear more about which kind of issues are currently blocking you.

[simarmol]

@cortinico have to second @RoryZilch on this, while I would love to enable the new arch and we have already started work on it, we have months at least before we can enable it. There's custom internal libraries that need manual updating, old unmaintained libraries we use we have to migrate off of, libraries we need to do major refactors because of due to major version upgrades in order to get to the version that supports the new arch, etc. We are going as fast as we can, and we are also pressured by the end-of-month Android deadline which there is no chance of being able to enable the New Arch by.

We are building RN source locally in the meantime in order to patch this, but this has it's own issues. Along with slowing down our builds immensely, it's added a lot of additional fragility our builds. Building RN from source has already broken once in the week since we upgraded due to issues in the Maven dependencies.

This issue is making it harder to move to the New Arch, if anything.

[ChrisZilch]

@cortinico do you have any more clarity about when this can go into a patch? We're going to have to make a call very soon on a workaround so that we don't have issues with Google Play but our much preferred solution would be to just update to a fixed version. We are actively working on the new architecture migration but there's no chance it will be done this month.

[cipolleschi]

@react-native-bot merge c43952ac22b2356be3130c906329f61e246082cb 0.79-stable