Summary:
It seems like CircleCI is not handling well env variables with \n in it.
I'm moving it over to a base64 encoded string and I'm extending the publish
scripts to base64 decode the key.
Changelog:
[Internal] [Changed] - Unbreak Nightly job by providing a GPG key as base64 encoded.
Reviewed By: cipolleschi
Differential Revision: D40426438
fbshipit-source-id: a60a7e7ad71580e81e675c84008d2712712e42a6
Summary: Changelog: [Internal] Add more properties to PointerEvent, ensure all web platform tests are passing
Reviewed By: mdvacca
Differential Revision: D40314330
fbshipit-source-id: 071683f26f5a1e17d7ea49ac022c0ca23b6f9947
Summary:
Changelog: [Internal] - Add more state to PointerEventState per pointer such that `offset` coordinates and `hitPath` accurately reflect each pointer.
This change eagerly calculates the hitPath of every pointer under a MotionEvent.
Reviewed By: mdvacca
Differential Revision: D39736109
fbshipit-source-id: ef76dc19a86eaf9b26f35c6a55781ece6e43eecc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34970
I'm setting up `gradle-nexus` on our build to simplify the closing and releasing of staging repositories.
As of now, you'll have to go to Sonatype UI and manually click the release button.
With this plugin, we can instruct CircleCI to do the publishing automatically for us as
part of the nightly/stable release process.
Changelog:
[Internal] [Changed] - Setup gradle-nexus to automate closing and releasing staging repositories
Reviewed By: cipolleschi
Differential Revision: D40342759
fbshipit-source-id: 72e80f4bcc80058d5a6ea562ae136a91b2aeedbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34967
This diff is a preparatory work for publishing artifacts on Maven Central.
What it does is:
1. It sets up all the 3 modules (react-native, hermes-engine, external-artifacts) for publishg
2. Adds coordinates to publish on the Snapshot repository
3. Adds support for appendign -SNAPSHOT version if invoked with `-PisNightly=true`
4. Configures GPG signing of artifacts.
I haven't touched the CircleCI and JS code yet. I'll do it in another diff.
Changelog:
[General] [Changed] - Setup publishing for Snapshot and Stable on Maven
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40146212
fbshipit-source-id: 9321e16f6c18b35bc3ae785749d613085c56e7bc
Summary:
As identified in https://github.com/facebook/react-native/issues/34350, modals do not honor the system's status bar colors because they may not be set by the deprecated `systemUiVisibility` flags. Unless `android:windowLightStatusBar` is set to true, the default flag is a zero-integer (a.k.a. "dark mode", where the icons show as white). Since the `StatusBar` component is using the new `setSystemBarsAppearance` API, the ModalHost should also infer its status bar settings from the same API.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fixed an issue on Android API 31+ where modals would turn status bar icons white by default
Pull Request resolved: https://github.com/facebook/react-native/pull/34899
Test Plan:
- On a screen with the `StatusBar` bar style set to `dark-content`, the modal also uses white icons
- On a screen with the `StatusBar` bar style set to `light-content`, the modal also uses black icons
### Preview
Here, I change the `barStyle` from `light-content` to `dark-content` and demonstrate that the proper attributes are retained. The "Before" is a recording from `main` and the "After" is this branch. Notice how in "Before", the status bar is always turning the icons white when the modal opens.
|Before|After|
|-|-|
|||
## Other considerations
There's some argument towards removing this check entirely--the status bar appearance should be derived from the theming and/or the parent activity's settings, thereby removing the need to apply separate styling
Reviewed By: lunaleaps
Differential Revision: D40243122
Pulled By: lunaleaps
fbshipit-source-id: ffa56c7d6a1906f89658f95a12f6bf1cefd5be8e
Summary:
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
With this change, if a developer opts into developer support in a release build (i.e. `enableOnCreate == true && ReactBuildConfig.DEBUG == false` in the `DevSupportManagerFactory`), the `PerfTestDevSupportManager` will be used, allowing use of things like heap size reporting and the sampling profiler.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D39468561
fbshipit-source-id: cb3c82e7a8ee74316b23f57dc8d0cc6e5cdb18a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34927
The changes made in D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) and D36958882 (https://github.com/facebook/react-native/commit/d8c25ca1b62df2b93f70bbb1f7b379643ab9ccd4) attempted to reduce flickering and consistency issues when using Animated.
In the old renderer, we explicitly reset all animated props, and wait for the subsequent React commit to set the props to the right state, but if `initialProps` are used, the React reconciliation may not be able to identify the prop-update is required and will leave out the value. This behaviour is different in the new renderer, where we do not explicitly `restoreDefaultValues` on detaching the animated node, and instead rely on the latest state being correct(?).
Changelog:
[General][Fixed] Stop styles from being reset when detaching Animated.Values in old renderer
Fixes#34665
Reviewed By: rshest
Differential Revision: D40194072
fbshipit-source-id: 1b3fb1d1f4a39036a501a8a21e57002035dd5659
Summary:
Noticed that we were using a different tag for each pointer event observed (and that weren't clearing these properly when recyling views).
Each of these tags is a hashmap entry and a boxed boolean, so we can do much better by just using a single (boxed) integer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D40077519
fbshipit-source-id: 130e78c3641eaedfa8787644b98763fd4367bc27
Summary:
This change will expose the rrc_image module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose rrc_image to consuming build
Reviewed By: cipolleschi
Differential Revision: D40098541
fbshipit-source-id: 2e07d8b19f53ba93920009603c95a43b01f131eb
Summary:
This change will expose the `react_render_imagemanager` module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose react_render_imagemanager to consuming build
Reviewed By: cipolleschi
Differential Revision: D40022929
fbshipit-source-id: ece47503b11a641067ae6db82f1d69b244c9c5be
Summary:
Create documentation to write C++ ViewManagers in React AR apps
changelog: [internal] internal
Differential Revision: D40119174
fbshipit-source-id: edce0e6b226a30007c39f924b5896fa2267e98b7
Summary:
This change encapsulates all the NDK configuration logic inside the React Native
Gradle Plugin. The changes are additive so that the user can still specify a
custom configuration if they wish.
So far I've applied the changes to RN Tester. Changes to the template require a
bump of the Gradle Plugin NPM package.
Changelog:
[Android] [Changed] - Hide the C++/Cmake configuration from user space inside the framework
Reviewed By: cipolleschi
Differential Revision: D40139557
fbshipit-source-id: 013220695791e3d0d458e118de16953e0545c3de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34869
Changelog: [Internal]
This merges all instances of `enablePropIteratorSetter` into a single one.
Both `AccesibilityProps` and `BaseTextProps` had their own instances if it, which is now redundant.
Reviewed By: cipolleschi
Differential Revision: D40062555
fbshipit-source-id: b6ccf5a9538612dd731a6f9c4eaceeebcb6d95be
Summary:
Automation tests were hitting issues with view recycling enabled because we use the main tag field to lookup views, and not properly resetting it when recycling.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D40076594
fbshipit-source-id: 5f518b979a23562f7e7fc8271488678e78f50e91
Summary:
While working on https://github.com/facebook/react-native/pull/34513 I noticed that on main branch the versioning is not really consistent everywhere. So this PR is an attempt at realigning so that on the main branch, RN is 1000.0.0 everywhere - in a way, it's cleaning up the room for the monorepo work to go flawlessly).
It's just a pass of `node scripts/set-rn-version.js --to-version 1000.0.0`.
There's the small chance that some versions where kept to 0.0.0 on purpose (build tools are weird), so we might just have to close this off. No big deal :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - re-align version to be 1000.0.0 on main everywhere
Pull Request resolved: https://github.com/facebook/react-native/pull/34817
Test Plan: CI is green and when imported, nothing breaks.
Reviewed By: cortinico
Differential Revision: D39926953
Pulled By: cortinico
fbshipit-source-id: ff66530382f891e17c00b35edf97c03591b6a9a8
Summary:
I'm handling this TODO i left to unbreak the CI.
We need to make sure all the autolinked libraries are getting the folly flags and other common flags propagated correctly.
## Changelog
[Internal] [Change] - Propagate common flag to autolinked libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/34853
Test Plan: Will rely on a green CI
Reviewed By: cipolleschi
Differential Revision: D40055134
Pulled By: cortinico
fbshipit-source-id: fb9afab954ab402f6a3ab417aba934035580f936
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34843
We can now remove a lot of unnecessary code to copy .so
files around as they're consumed via prefab from :ReactAndroid
Changelog:
[Android] [Changed] - Cleanup the Android template after prefab support
Reviewed By: cipolleschi
Differential Revision: D40014642
fbshipit-source-id: 00e69ea62bdb4882b40b8b6f19cdf80235c847b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34831
Historically we had to download an unzip the fbjni Android Archive to use it.
Here I'm updating the way how we consume to use prefab so we can remove a lot
of unnecessary configuration, also from the app template.
Changelog:
[Internal] [Changed] - Consume fbjni via Prefab
Reviewed By: cipolleschi
Differential Revision: D39964574
fbshipit-source-id: 1b18682c2b36aabb1fc1a3819ca09e575182eae4
Summary:
A follow up to D38708718 (https://github.com/facebook/react-native/commit/403fea25f65a38f4b4d8e0edcf89741b29e62059) review, this factors feature flags for Fabric core code into a separate file, `CoreFeatures`.
Keeping them together is arguably better for maintenance and makes code easier to reason about.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D40007784
fbshipit-source-id: 1885d5d6200575c6015f063d8b05813b18b47ffb
Summary:
CMake on Windows uses "Visual Studio **" generators are [multi-configuration](https://cgold.readthedocs.io/en/latest/glossary/multi-config.html),
which requires the hermes cli and hermes runtime build flavors to be compatible. Using the "MakeFile" generator will avoid the requirement and keeps the gradle script simpler. Please note that the "Makefile" generator is the default when only "Visual Studio Community edition" with default packages is available.
Use NMake generator for Hermes build on Windows
## Changelog
CMake on Windows uses "Visual Studio **" generators are [multi-configuration](https://cgold.readthedocs.io/en/latest/glossary/multi-config.html),
which requires the hermes cli and hermes runtime build flavors to be compatible. Using the "MakeFile" generator will avoid the requirement and keeps the gradle script simpler. Please note that the "Makefile" generator is the default when only "Visual Studio Community edition" with default packages is available.
[Android] [Fixed] - Use NMake generator for Hermes build on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/34790
Test Plan: Verified that RN build on Windows with multiple SKUs of Visual studio.d
Reviewed By: cortinico
Differential Revision: D39889332
Pulled By: cortinico
fbshipit-source-id: f2d39d981e7c58c8cb93a4322155c844cb6bded3
Summary:
Ensuring the file paths uses forward slashes as separator to avoid the characters from being interpreted as ASCII escape characters.
## Changelog
Fixing build failure building RN codegen CLI on Windows. Ensuring the file paths uses forward slashes as separator to avoid the characters from being interpreted as ASCII escape characters.
[Android] [Fixed] - Fixing failure building RN codegen CLI on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/34791
Test Plan: Ensured RN main branch builds on Windows with new architecture turned on.
Reviewed By: cipolleschi
Differential Revision: D39889468
Pulled By: cipolleschi
fbshipit-source-id: 7d79eac9f433908cc86dd7ca2eec841739ef6365
Summary:
Works around a crash identified by Sapienz in D39852058 (https://github.com/facebook/react-native/commit/30411ae1a42e46d0e5a2da494a39ed2767ba8808)
These logs will still be logged to the console, as they were before
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39968830
fbshipit-source-id: 5d7a5d935e85a7d67e7780d95b2253e50888ad90
Summary:
Previously, ViewPropsMapBuffer conversions were hardcoded deep in Android infrastructrue. I've generalized this into a different mechanism to allow any Props struct to support MapBuffer props.
There are still some things that need to be cleaned up and this should be treated as experimental. One thing we likely want to do is remove the hardcoded IDs (fine for codegen'd code; less so for handwritten) and use compile-time-hashed IDs instead with human-readable string names.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708719
fbshipit-source-id: 64603dee7f21828be31346c555d99862dab304ea
Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34829
I realized there is a race condition in how prefab headers are prepared and bundled. If the download of boost is not 'fast enough' the headers will be missing during prefab preparation.
This fixes it.
Changelog:
[Internal] [Changed] - Fix broken template tests due to missing boost headers
Reviewed By: cipolleschi
Differential Revision: D39968622
fbshipit-source-id: 4680f84c15f4443a16def45d41a10a1083f4f196
Summary:
I accidentally broke `main` as I added a PRIVATE link for external libraries.
I need to get back to this, but for the meantime I'm disabling this linking
to make the CI green.
Changelog:
[Internal] [Fixed] - Unblock template jobs on main due to accidental PRIVATE linking
Reviewed By: cipolleschi
Differential Revision: D39932205
fbshipit-source-id: 5acbf567e0c194224a01141273665a293ead8e32
Summary:
This adds the YGGutter enum, used to choose between row/column gap variants (row-gap, column-gap, gap).
This used later in changes from https://github.com/facebook/yoga/pull/1116, in the APIs which deal with setting gap on style on yoga node.
Note the original PR called this `YGGap`, but this ending up leading to a couple public method signatures that could appear ambiguous:
1. `SetGap(YGGap gap, float gapLength)`: Enums like `YGAlign` are the vaues for an `align` prop. `YGGap` controls the variant of the gap (like `YGEdge` does for left/right/top/bottom variants). So the enum reads as if it is the `gapValue`, and it looks like we have two of the same parameter.
2. `SetGap(YGGap gapDirection, float gap)`: This is misleading, because the direction gaps flow is the cross-axis of flex-direction.
3. `GetGap(YGGap gap)`: `gap` is the variant, but looks like an out param.
The [CSS Box Alignment](https://www.w3.org/TR/css-align-3/#column-row-gap) spec refers to these gaps as "Gutters", which removes the ambiguity.
Changelog:
[General][Added] - Add YGGutter Enum
Reviewed By: yungsters
Differential Revision: D39922412
fbshipit-source-id: 4b0baf800fecb3d03560a4267c7fb4c4330fd39e
Summary:
https://github.com/facebook/yoga/pull/1116 adds a new enum. The enum generator is out of date with copyright header, and some codemods, but it also looks like there were manual changes, types added, etc since generation. I fixed up the script to incorporate generating the changes folks made manually, and also added an enum that was previously only added manually to the C ABI.
Changelog:
[General][Fixed] - Fixup Yoga Enum Generator
Reviewed By: yungsters
Differential Revision: D39922252
fbshipit-source-id: b678fa9a43a896873d8c434745bdaf3f16fd991f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34819
This is crashing on A12 because of using the regular Context instead of the application context. That said, this probably makes more sense as a log warning.
Reviewed By: javache
Differential Revision: D39852058
fbshipit-source-id: 1ac93f8cc9ecdb14f60baca175c8ecff2ff42ac0
Summary:
This removes the old way of consuming `libreact_nativemodule_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
This is the last mode that we'll have to handle the prefab for.
I'll do the cleanup just after this change landed.
Changelog:
[Internal] [Changed] - Move `react_nativemodule_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39929261
fbshipit-source-id: 61669da2cfd0545160a2a4c596c8e4adb22303ec
Summary:
This removes the old way of consuming `libfolly_runtime.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Moreover, I've exposed a `folly-flags.cmake` file which can be used by libraries
to know which lists of flags they need to use for Folly.
Changelog:
[Internal] [Changed] - Move `folly_runtime` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39928571
fbshipit-source-id: 4864c37813ec681a6a464c97de6dfc078f5553f1
Summary:
This removes the old way of consuming `libyoga.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `yoga` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927496
fbshipit-source-id: f7ab2a3aab3cb42effa648dfeff6711d183260e4
Summary:
This removes the old way of consuming `libreact_renderer_mapbuffer.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_renderer_mapbuffer` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927266
fbshipit-source-id: e82c2bda02c85a2a6747b92a3f20f2a5118bda65
Summary:
This removes the old way of consuming `libfabricjni.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `fabricjni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927210
fbshipit-source-id: dbd8814a6cad38d09484561120df911ab24b5f8a
Summary:
This removes the old way of consuming `libglog.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `glog` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927147
fbshipit-source-id: 99f0241da1dece0efc8d928c3d25f30f3fa48a09
Summary:
This removes the old way of consuming `libjsi.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `jsi` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924434
fbshipit-source-id: cb92d3a4ed6cb87e75462082506f310feb7bec9f
Summary:
This removes the old way of consuming `librrc_view.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `rrc_view` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924231
fbshipit-source-id: 231809631f807ea2ea40d2581759f391adfba94d
Summary:
This removes the old way of consuming `libreact_render_graphics.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_graphics` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923620
fbshipit-source-id: 9edb6557b4d195e1703b1ae532ca14126930a43a
Summary:
This removes the old way of consuming `libreact_render_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923551
fbshipit-source-id: b800d4369f0de8edbc68b11d9efecf2cb5ea68c1
Samuel Susla
Nicola Corti
Luna Wei
generatedunixname89002005287564
Nick Gerleman
Peter Abbondanzo
Matt Blagden
Pieter De Baets
David Vacca
Joshua Selbo
Ruslan Shestopalyuk
Lorenzo Sciandra
Nicola Corti
Anandraj Govindan
Christopher Jones
