Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for mapbuffer
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - mapbuffer
Reviewed By: cipolleschi
Differential Revision: D38699253
fbshipit-source-id: c1c8f8693b6da4e3428f8f280e1ca4d5c5d0f853
Summary:
Add ability to store and retrieve a list of MapBuffer as an entry of MapBuffer.
```
Example:
MapBuffer1
{
key1: "test string",
key2: MapBuffer2,
key3: [MapBuffer3, MapBuffer4]
}
```
Changelog:
[General][Added] Add ability to store and retrieve a list of MapBuffer
Reviewed By: JoshuaGross
Differential Revision: D38460204
fbshipit-source-id: 3e721418be2dca6d5f15f665753844d6f531e31c
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33535
Hack to support Kotlin functions in Buck compilation: adds Kotlin stdlib as a dependency to make sure upstream targets include Kotlin jvm internal classes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35284430
fbshipit-source-id: 0d29ad30386514c8df5376d0a6809d3105f0cd0f
Summary:
Aligns naming with `JWritableMapBuffer` and other fbjni classes to indicate that it is a JNI binding.
Changelog: [Internal] - Rename C++ part of ReadableMapBuffer to JReadableMapBuffer
Reviewed By: mdvacca
Differential Revision: D35219323
fbshipit-source-id: a7eb644a700a35dc94fa18e4fb3cc68f2cfa3e99
Summary:
Updates `ReadableMapBuffer` to conform to `MapBuffer` interface, to allow interchangeable use of `Readable/WritableMapBuffer` in the code.
Notable changes:
- MapBuffer.Entry getters are now represented as Kotlin properties and appended `Value` suffix (e.g. `entry.getInt()` becomes `entry.getIntValue()` in Java, or `entry.intValue` in Kotlin)
- `ByteBuffer` is imported in constructor instead of on demand. This method doesn't copy the data as the bytes are read directly from native heap, and benchmarking a 500-byte `MapBuffer` shows no difference in import speed.
- Internal logic of `ReadableMapBuffer` uses `UShort` kotlin type for key retrieval, for more correct representation of values.
- Explicit exception throws are replaced with `require` and `check` methods for `IllegalArgumentException` and `IllegalStateException` (default FB conversion).
The change also updates `ReadableMapBuffer` usages to `MapBuffer` interface where possible (virtually everywhere except JNI methods).
Changelog: [Android][Changed] - Adopt `MapBuffer` interface for `ReadableMapBuffer`
Reviewed By: mdvacca
Differential Revision: D35218633
fbshipit-source-id: 515dd974c27b2978ade325b2e1750ab8f068a20a
Summary:
Creates a `WritableMapBuffer` abstraction to pass data from JVM to C++, similarly to `ReadableMapBuffer`. This part also defines a Kotlin interface for both `Readable/WritableMapBuffer` to allow to use them interchangeably on Java side.
`WritableMapBuffer` is using Android's `SparseArray` which has almost identical structure to `MapBuffer`, with `log(N)` random access and instant sequential access.
To avoid paying the cost of JNI transfer, the data is only transferred when requested by native `JWritableMapBuffer::getMapBuffer`. `WritableMapBuffer` also owns it data, meaning it cannot be "consumed" as `WritableNativeMap`, with C++ usually receiving copy of the data on conversion. This allows to use `WritableMapBuffer` as JVM-only implementation of `MapBuffer` interface as well, e.g. for testing (although Robolectric will still be required due to `SparseArray` used as storage)
Changelog: [Android][Added] - MapBuffer implementation for JVM -> C++ communication
Reviewed By: mdvacca
Differential Revision: D35014011
fbshipit-source-id: 8430212bf6152b966cde8e6f483b4f2dab369e4e
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
This Diff moves from specifying a list of files to use file(GLOB) with
CONFIGURE_DEPENDS on several CMakefiles.
I've updates those where we use globbing also inside buck.
Changelog:
[Internal] [Changed] - Setup Globbing with CONFIGURE_DEPENDS inside CMake files
Reviewed By: ShikaSD
Differential Revision: D34826311
fbshipit-source-id: 8fc654626c897cdc4cdd79c699ce19f1e5e1212f
Summary:
Rearranges folly_futures configuration into a static library only required for `hermes-inspector` + `folly_runtime` which merges `folly_json` and mutex-related implementations `folly_futures` was used for. As `hermes-executor-debug` is removed by `vmCleanup` configurations later, it allows to shave additional 300KB from the release APK size.
Changelog: [Internal] - Rearrange folly build to reduce APK size
Reviewed By: cortinico
Differential Revision: D34342514
fbshipit-source-id: b646680343e6b9a7674019506b87b96f6007caf2
Summary:
This is the first round of CMake files to support the React Native build on Android.
They're supposed to eventually replace the various Android.mk files we have around in the codebase.
So far we're not actively using them. This is the first step towards migrating our
setup to use CMake
Changelog:
[Internal] [Changed] - First Round of CMake files for React Android
Reviewed By: ShikaSD
Differential Revision: D34762524
fbshipit-source-id: 6671e203a2c83b8874cefe796aa55aa987902a3b
Summary:
Provides an alternative way of diffing props on Android side. Instead of passing dynamic JSON values from JS, the new approach diff C++ props and serializes difference into a `MapBuffer`. Current implementation does this only for `RCTView` component to test performance, correctness and memory impact (as MapBuffers are supposed to be more compact and performant).
This way of passing props allows for additional alignment between platforms, as C++ props are now source of truth for the view state, similar to iOS. At the same time, changing serialization method requires reimplementing `ViewManager` codegen (done manually for now) to account for `MapBuffer`s.
Changelog: [Added][Android] - Added an experimental prop serialization path based on MapBuffer
Reviewed By: mdvacca
Differential Revision: D33735245
fbshipit-source-id: 1515b5fe92f6557ae55abe215ce48277c83974a6
Summary:
Was trying out some behaviour when using the MapBuffer experiment and fixed some small issues.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34108859
fbshipit-source-id: 550ca0847419006ec17472cc4b70d38fc8d05396
Summary:
This diff adds `RedBoxSurfaceDelegate` to replace existing logic in `DevSupportManagerBase` to abstract how we show/hide the RedBox surface. The delegate will wrap a RedBoxDialog instance, which is used to show/hide the dialog for default behavior (when there is no surface delegate for redbox got provided).
I also updated the interface for delegate to accomodate new use cases:
- Add `isShowing` for the `SurfaceDelegate`
- Add a list of getters for `DevSupportManager` for data access in the delegate
- (Update 2/7) Separate Dialog from `RedBoxDialog`, and re-named it to `RedBoxContentView`. This is to make it clear that the delegate is responsible to provide actual surface implementation (Dialog). The content view is meant to be shared.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D33987835
fbshipit-source-id: 57c20648e7f2ec8238963feca27ccd5518e7931d
Summary:
Serializes type information along with key/value in MapBuffer, asserting the data type on Java side during read. At the moment, accessing value with incorrect will result in a crash.
Other changes:
Adds a `getType` method to verify types before accessing them.
Removes `null` as a type, as just not inserting value and checking for its existence with `hasKey` is more optimal.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33656841
fbshipit-source-id: 23a78daa0d84704aab141088b5dfe881e9609472
Summary:
Rename `_header` to `header_` to align with the C++ naming scheme we use.
Rename `readKey` to `readUnsignedShort` as purpose of the method have changed.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33637127
fbshipit-source-id: a82f4d6c1b753b21e0567fbe919af98e4c78105d
Summary:
MapBuffer uses unsigned short in C++, but Java doesn't really have a type that represents that. That means that MapBuffer would be limited to max 32768 values instead of 65536, which doesn't make much sense as a limitation.
Considering weird (and usually not performant) handling of short values in Java in general, this change replaces them with ints, converting keys from short when needed with `key & 0xFFFF`.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33595308
fbshipit-source-id: a7adde8a207bb4aa1d81d367ab5d7b41ace2e291
Summary:
Cleans up `ReadableMapBuffer` APIs and migrates to use `std::vector` instead of raw pointer array.
Also uses `fbjni` utility to allocate the bytes instead of making manual JNI calls.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33513027
fbshipit-source-id: afe7d320d12830503de4c9994117d849f0b25245
Summary:
We have `LOCAL_SHARED_LIBRARIES` that are getting longer and are
making reviewing them on Diffs quite hard.
Having all the list of the dependency on a single line is suboptimal
and it makes hard to find duplicated entries.
I've updated the longest `LOCAL_SHARED_LIBRARIES` to be multilines and
I've sorted the entries here.
Changelog:
[Internal] [Changed] - LOCAL_SHARED_LIBRARIES
Reviewed By: ShikaSD
Differential Revision: D32695127
fbshipit-source-id: f5b381c501ddff083ef9f4baaca6c4c8c9523368
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
This diff introduces a new interface named `SurfaceDelegate`. The interface abstracts the API for interacting with a surface, which is required for platforms other than mobile to implement how it wants to show and hide a surface. For existing Mobile use cases, the `LogBoxDialogSurfaceDelegate` is provided as a fallback solution so everything still works.
Changelog:
[Android][Added] - Add SurfaceDelegate abstraction to support interaction in multiple platforms and provide default implementation in LogBoxModule
Reviewed By: mdvacca
Differential Revision: D31132285
fbshipit-source-id: 13315a8bc5b7bcaee9b5e53ef5c6f6cc8cb01f31
Summary:
This diff creates a ReactFeatureFlag to initialize MapBufferSo file during Fabric initialization.
This is necessary to be able to compare properly Mapbuffer vs ReadableNativeMap (because ReadableNativeMap c++ files is already included in the bridge so file)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D28436044
fbshipit-source-id: 338e1bb72b5313dc29a309e1b0e979e7c8bd1c18
Summary:
This diff replaces all usages of int by int32_t. This is to ensure we always use a fixed size for int that matches what's expected on Java.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27915608
fbshipit-source-id: 634c45796dda1d4434c3ad6ff3e199931c22940b
Summary:
Refactor MapBufferBuilder to use int to store size of Mapbuffer data
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904646
fbshipit-source-id: 6b8b96fdd30184b6d35c1d612743eae653854d6d
Summary:
DynamicData can contain a big amount of data, refactoring type to use int instead of short
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904643
fbshipit-source-id: 157064b280e27a9c7c4a4f55af310392b178feda
Summary:
Add extra asserts and early deallocation in ReadableMapBuffer::importByteBufferAllocateDirect
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904645
fbshipit-source-id: 075a007c4ec5e005b839add054bd68c233b65801
Summary:
This diff fixes the importByteBufferAllocateDirect method.
This was tested enabling importByteBufferAllocateDirect in ReadableMapBuffer.java
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27867055
fbshipit-source-id: 9ef5e93ff6c7903782598dde1c499daa82cd467b
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
This diff contains the code from the 35 diff stack - D27210587
This diff implement and integrates Mapbuffer into Fabric text measure system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27241836
fbshipit-source-id: f40a780df0723f27da440f709a8676cfcca63953
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30595
Changelog: [Internal]
Add support for loading HBC bundles from Metro in Twilight.
* adds `runtimeBytecodeVersion` to the bundleURL
* adds logic to check chunk hermes bytecode bundles
* adds support for running the bytecode bundles
Reviewed By: cpojer
Differential Revision: D24966992
fbshipit-source-id: acdd03a2e9e2b3e4c29c99c35a7c9136a3a7ef01
Summary:
In preparation for flipping the default, marking autoglob as False in places where it isn't explicitly specified.
Changelog: [Internal]
Reviewed By: strulovich
Differential Revision: D25497305
fbshipit-source-id: 142e5caca2d67efcb3c25067a36934f7f6dd4b21
Summary:
This diff changes the InitialLifeCycleState used when initializing RN in FB4A from BEFORE_RESUME to BEFORE_CREATE.
The value of this field is used during the teardown of RN to determine if RN is actually running or not
The intention of this change is to represent the right behavior of RN during initialization, also this will allow RN to be turn down in case of memory pressure when the bridge has been initialized but before the user has navigated to a RN screen (preloading)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D22577555
fbshipit-source-id: e54ef596cfe4429745611fe6022eb000051a93d0
Summary:
Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server".
Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330966
fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Riccardo Cipolleschi
Jonathan Keljo
Stanley Shi
Joshua Selbo
Nicola Corti
Lulu Wu
Ron Edelstein
Anandraj Govindan
Steven Vascellaro
Chris Olszewski
Andrei Shikov
CodemodService Bot
Pieter De Baets
Xin Chen
Andres Suarez
Joshua Gross
Moti Zilberman
Chatura Atapattu
David Vacca
Samuel Susla
Keion Anvaripour
Christoph Nakazawa