Making Android versionCodeOverride for new apps using the template human-readable #29808
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
the
CLA Signed
Base commit: 7b82df2 |
Base commit: 7b82df2 |
|
cc @dulmandakh - thoughts? If people are already using the arbitrary version like 1048580 before, will this cause any problem? |
|
@fkgozali @dulmandakh I also have this concern but I am not familiar with the react-native CLI |
|
IIRC, Play Store requires a new release to increment versionCode. So I don't think this PR will fix the issue, but cause more. |
|
what do you mean about yes versionCode need to be incremented, but with the current config it will generate a very arbitrary version number. With this change if you update and my thought is because this is a template file this could prevent future issues and not change the older implementation. |
|
My thoughts:
This seems OK to me, thoughts @dulmandakh? On the implementation note, I usually prefer the "details" to have lower digit in the version number. Your proposal is: so versionCode 4 will produce:
What if versionCode reaches 1000? That would cause problem because it doesn't fit the formula. What about reversing this? This way, each "release" for the versionCode always give you strictly increasing version numbers: 4001, 4002, ... In practice, the build number should always monotonically increase, regardless of flavor (e.g. in CI environment). So I think reversing the logic as suggested would satisfy this? |
|
tbh I want to complete remove this part, and lock versionCode to current highest value. And instruct user to modify this when they make a new release. |
|
@fkgozali That makes sense, just updated the pr with those changes. @gengjiawen What is your strategy to instruct the user to change the versionCode? via the CLI?. From the DX standpoint when you |
Like any other normal android app, change it in build.gradle. If they like, they can change it to link to commit count or any other dynamic approach.
I don't think this will be a problem. tbh current plan make version smaller only make this worse and broken user upgrade. |
I was talking about
If we remove the By default, when Gradle generates multiple APKs, each APK will have the same version information, as specified in the module-level build.gradle file. Because the Google Play Store does not allow multiple APKs for the same app that all have the same version information, you need to ensure each APK has its own unique versionCode before you upload to the Play Store. https://developer.android.com/studio/build/configure-apk-splits |
Thanks for the info. The number 1048580 is take from google android docs (include the whole applicationVariants part). Change it to smaller 1000 will cause more trouble. |
What google docs are you reffering to? https://developer.android.com/studio/build/configure-apk-splits it seems to me that the docs is using 1000 not 1048580? |
Google probably delete the original page recently, it's a long page introduce android gradle build system exists for many years. |
Is the Gradle template file patched automatically to the user Gradle file when they update react-native via the CLI? my main concern is to fix this problem for users that generate new app using the template not patching the older implementation. and also probably put some code comments disclaimer for those that update react-native via the rndiff website. |
Will make defaultConfig default version code to 1048580 and make |
|
@gengjiawen what are you trying to achieve with that configuration? is not going to solve anything, it will break the current config and still produce an arbitrary number. And the versionCode should never be static, the user should maintain this. |
|
Thinking about this, I think this change is still reasonable for new apps created via react-native init. Existing apps won't be affected. @gedeagas, can you update a few things?
|
|
@fkgozali updated. |
gedeagas
changed the title
There was a problem hiding this comment.
@fkgozali has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
|
This pull request was successfully merged by @gedeagas in e1bf515. When will my fix make it into a release? | Upcoming Releases |
3 tasks
HeyImChris
pushed a commit
to microsoft/react-native-macos
that referenced
this pull request
Sep 28, 2021
* Fix initial padding value for TextInput
Summary:
Changelog: [internal]
# Problem
Default padding for TextEdit is top: 26, bottom: 29, left: 10, right: 10 however the default values for LayoutMetrics.contentInsets is {0, 0, 0, 0}.
If you try to construct TextEdit with padding 0, Fabric will drop padding update because padding is already 0, 0, 0, 0.
# Fix
To fix this, I added a special case to `Binding::createUpdatePaddingMountItem`, if the mutation is insert, proceed with updating padding.
Reviewed By: JoshuaGross
Differential Revision: D23731498
fbshipit-source-id: 294ab053e562c05aadf6e743fb6bf12285d50307
* Fabric: Simplifying ShadowTreeRevision implementation
Summary:
The implementation of this class is too complex for the purpose it serves. Making it simpler will make the code simpler and faster.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725688
fbshipit-source-id: 5e1ecddb0dd3c4c4f94786e2ba0af9b67e7426ce
* Fabric: Using ShadowTreeRevision inside ShadowTree to store current commited tree
Summary:
Instead of storing tree separate instance variables, we now store a single object that contains them. We will need it to be able to postpone the mounting stage (we save all info we need for mounting inside the new instance variable).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725690
fbshipit-source-id: 09dd4a0912c6f5b34d805636b62f73ca12287329
* Fabric: Introducing `ShadowTree::getCurrentRevision()`
Summary:
Previously, to get a current root shadow node for a shadow tree, we called `tryCommit` method and stole a pointer from this. That was not a very straightforward method to get things done, and most importantly we need to do this to change the shape of the ShadowTreeCommitTransaction signature (remove a shared pointer from the callback) to make it simpler, faster and allow future improvements (see the next diff).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725689
fbshipit-source-id: 51950b843a0e401828b6c6a38e5e2aaaf21ec166
* Fabric: Removing shared_ptr from ShadowTreeCommitTransaction's argument
Summary:
We don't need a shared_ptr here and without it the code will be faster and simpler.
This change is aligned with any clone-line callbacks we have in the Core which accepts a `const &` and return `shared_ptr<>`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725687
fbshipit-source-id: 1cd959f4273913175d342302e2f12752f0114768
* Fabric: Using `thread_local` keyword instead on own implementation in TransactionTelemetry
Summary:
Apparently, there is C++ keyword for this.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23754284
fbshipit-source-id: 5f9bbcc72d9c586173624869d614f12d2319fb7b
* Add an explicit NDK version to Android template (#29403)
Summary:
Added an explicit NDK version to the Android template. This allows tooling to detect which NDK version to install automatically.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Added] - Add an explicit NDK version to Android template
Pull Request resolved: https://github.com/facebook/react-native/pull/29403
Test Plan: Template builds as it should. NDK version gets installed with initial Android set up.
Reviewed By: passy
Differential Revision: D23752007
Pulled By: fkgozali
fbshipit-source-id: 31c33f275f94a4a62338a61e79b31c4b996969bf
* Fabric: Removing `RCTCGColorRefUnretainedFromSharedColor()`
Summary:
This diff removes `RCTCGColorRefUnretainedFromSharedColor` function because it's not compatible with future changes we plan to make.
Converting SharedColor to unretained CGColorRef is actually quite dangerous because... it's an unowned pointer.
Reviewed By: JoshuaGross
Differential Revision: D23753509
fbshipit-source-id: df030ade69b63cbb872d6bdbde51575eedc6a4a6
* Fabric: Using RCTUIColorFromSharedColor everywhere
Summary:
Even though we have wonderful helper functions converting SharedColor to UIColor and CGColorRef, in many places we still use some hardcoded things. This diff fixes that; it will be important for the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753508
fbshipit-source-id: 09d280b132266252753526c2735ab3e41b96c8d5
* Fabric: Color conversion functions now do not depend on internal implementations of SharedColor
Summary:
This diff changes the implementation of `RCTCreateCGColorRefFromSharedColor` and `RCTUIColorFromSharedColor` in such a way that they don't rely on the fact that SharedColor is actually a `shared_ptr<CGColorRef>`. Instead, the methods just extract color components from SharedColor and create UIColor and CGColorRef objects on demand.
This allows us to change the implementation of SharedColor without worrying much about the rest of the system, which will do in the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753510
fbshipit-source-id: 340127527888776ebd5d241ed60c7e5220564013
* Fabric: Using `optional<int>` instead of `CGColorRef` on iOS
Summary:
Finally, this diff changes the internal implementation of SharedColor to be `optional<int>`.
Initially, when we started working on the new renderer, it seemed like a good idea to allocated CGColor objects ahead of time and store them with Props. Now, this idea does not look so good, especially because:
* Having `SharedColor` as a `shared_ptr` is a quite big perf overhead for copying this thing. And the size of the object is not small.
* Having `SharedColor` as a `shared_ptr` creates huge interconnectedness among pieces of the core and rendering. E.g. improper releasing a pointer in some component view can cause a crash somewhere in the core (because both places might use the same shared `blackColor`.
On Android, we already use simple `int` as a representation of a color, and this works great. And this diff implements something very similar to Android, but a bit differently: here we use `optional<int>` instead of custom class with a single `int` field and some magic value that represents "empty value".
This approach should fix T75836417 because now we don't have allocation and deallocation when we simply assign color values.
If this solution works fine on iOS, I will do unify all implementations among all platforms.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753507
fbshipit-source-id: 42fd6cee6bf7b39c92c88536da06ba9e8cf4d4db
* Fabric: Using pre-cached UIColor objects for black, white, and clear colors
Summary:
This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.)
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753506
fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246
* Coalesce touchMove events
Summary:
Changelog: [Internal]
To align more closely with Paper, Fabric should coalesce touchMove events.
on iOS it happens:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/React/Base/RCTTouchEvent.m?lines=43
Reviewed By: JoshuaGross
Differential Revision: D23734212
fbshipit-source-id: a9d324a6481884905d7be6637fcafe4e71f2bd9f
* Fix LayoutAnimations assertion on `adjustDelayedMutationIndicesForMutation`
Summary:
`adjustDelayedMutationIndicesForMutation` asserts that the mutation is either Remove or Insert. At one callsite, we weren't checking the mutation type before calling `adjustDelayedMutationIndicesForMutation`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746617
fbshipit-source-id: 6046fec2eb4821094937b1b16f40347bbc55c20e
* Fix MountingCoordinator override mode
Summary:
In MountingCoordinator override mode (used in LayoutAnimations) we must set the start and end `diff` time when no real diff happens, otherwise we will hit an assert in telemetry later.
I also ensure that the TransactionNumber is incremented in that case.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746684
fbshipit-source-id: b1fe3864e453fdba89d43cc827bd37434abf7a4d
* Fix MountingCoordinator RN_SHADOW_TREE_INTROSPECTION + LayoutAnimations
Summary:
Currently, MountingCoordinator's RN_SHADOW_TREE_INTROSPECTION code will crash often because it assumes there is always a "new" tree to compare the old tree to. In the LayoutAnimations context this is not always the case - in fact, the majority of the time, LayoutAnimations is producing mutations for animation without a "new" tree.
Just check that the tree exists before trying to print it.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23747289
fbshipit-source-id: a1ba22aeae32ed8915a53bc33cdc199e8ce5128a
* Fix compilation for LayoutAnimations debug mode
Summary:
iOS needs this function to be marked as static.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D23749613
fbshipit-source-id: a8c160646853450fc7d849448bdbb45e02beb964
* LayoutAnimations: at the end of every animation, issue an update mutation
Summary:
LayoutAnimations: at the end of every animation, issue an update mutation - this is so that the props data on the Mounting layer/StubViewTree layer is pointer-identical to the props data on the ShadowTree.
This unblocks iOS debug mode crashes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23753606
fbshipit-source-id: 407e0c2746a65e6d3ee29c1cce891cd7c1013593
* Layout Events: throttle layout events sent to same node repeatedly
Summary:
Under Fabric only, we can enter an infinite layout loop where the emitted layout event oscillates between two height values that are off by a very small amount.
The cause is, in part, components that use layoutEvents to determine their dimensions: for example, using onLayout event "height" parameters to determine the height of a child. If the onLayout height changes rapidly, the child's height will change, causing another layout, ad infinitum.
This might seem like an extreme case but there are product use-cases where this is done in non-Fabric and layout stabilizes quickly. In Fabric, currently it may never stabilize.
Part of this is due to a longstanding issue that exists in Fabric and non-Fabric, that we cannot immediately fix: If in a single frame, C++ emits 100 layout events to ReactJS, ReactJS may only process 50 before committing the root. That will trigger more layout events, even though product code has only partially processed the layout events. At the next frame, the next 50 events will be processed which may again change the layout, emitting more events... etc. In most cases the tree will converge and layout values will stabilize, but in extreme cases in Fabric, it might not.
Part of this is because Fabric does not drop *stale* layout events. If 10 layout events are dispatched to the same node, it will process all 10 events in older. Non-Fabric does not have this behavior, so we're changing Fabric to drop stale events when they queue up.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23719494
fbshipit-source-id: e44a3b3e40585b59680299db3a4efdc63cdf0de8
* Copy all blocks generated by TurboModules
Summary:
The Apple documentation states: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW1
> Typically, you shouldn’t need to copy (or retain) a block. You only need to make a copy when you expect the block to be used after destruction of the scope within which it was declared. Copying moves a block to the heap.
All blocks generated in the TurboModule infra, for callbacks and promise resolve/reject handlers, can be used after the destruction of the scope within which they were declared. Therefore, let's copy them in the hopes that they mitigate T75876134.
**Note:** We copy blocks before pushing them into the `retainedObjects` array in the legacy Infra as well. Context: D2559997 (https://github.com/facebook/react-native/commit/71da2917e577b7ec659083408cff7f9981d6600f), D5589246 (https://github.com/facebook/react-native/commit/2a6965df9063c795b3d3098c4db76e5f595ba44f)
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23764329
fbshipit-source-id: e71360977bdff74dc570bd40f0139792860f811f
* Upgrade Hermes dependency to 0.7.0
Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.7.0
allow-large-files
Reviewed By: cpojer
Differential Revision: D23725129
fbshipit-source-id: 50938433147100e97699b717d77a687fbbfe892b
* Fabric: Enabling state auto-repeating for all state updates (gated)
Summary:
This enables a new state auto repeating mechanism built-in mechanism for all state updates which we already use for CK interop. This experiment is supposed to help with T74769670 and co.
This change is gated with MC.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23762508
fbshipit-source-id: f535513c724ace9ede570177281324eb507329c5
* Stop accessing JVM in ~JavaTurboModule
Summary:
Inside JavaTurboModule, the native `CallInvoker` is used to schedule work on the NativeModules thread. So, in ~JavaTurboModule(), I scheduled some work on the NativeModules thread. This work holds a copy of the JNI global reference to the Java NativeModule object, and when it's executed, it resets this global reference to the Java NativeModule object. This should ensure that the we don't access the JVM in ~JavaTurboModule, which could crash the program.
I also removed the redundant `quitSynchronous()` in `~CatalystInstanceImpl()`, to prevent the NativeModules thread from being deleted before we delete the `jsi::Runtime`. This shouldn't cause an issue, because we delete the NativeModules thread when we call [ReactQueueConfigurationImpl.destroy()](https://fburl.com/codesearch/p7aurwn3).
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23744777
fbshipit-source-id: a5c8d3f2ac4287dfef9a4b4404a04b335aa0963d
* Improve performance logger definition and type safety
Summary:
The way the performance logger is defined now is very unsafe regarding type safety, as all accesses to its properties is untyped (`any`) and it uses several `mixed` types in cases that could be more refined.
This migrates the creation of performance loggers to instances of a class to improve its type safety. If there's an impact in performance, it's expected to be positive.
Changelog:
[Internal][Changed] - Replaced object literals with class instances to create performance loggers
Reviewed By: lunaleaps
Differential Revision: D23758609
fbshipit-source-id: 0734742eb97d92a4a53f7b66a8ca45a2ae90946c
* Remove unused timespan descriptions from performance loggers
Summary:
The `description` parameter is never used so we can simplify the API.
Changelog:
[Internal][Changed] Removed `description` option from performance logger timespans
Reviewed By: lunaleaps
Differential Revision: D23758829
fbshipit-source-id: 10900f86effc3e1f54a408cf8f9fbc9b3b52f569
* Remove unnecessary addTimeAnnotation method from performance logger
Summary:
Changelog:
[Internal][Removed] Removed `addTimeAnnotation` method from performance loggers
Reviewed By: lunaleaps
Differential Revision: D23758816
fbshipit-source-id: 98e0abae25266f3dcc5953f25f20cde8e3dac190
* Remove update option from stopTimestamp method in performance loggers
Summary:
Changelog:
[Internal][Changed] Removed `update` option from `stopTimestamp` method in performance loggers
Reviewed By: lunaleaps
Differential Revision: D23759138
fbshipit-source-id: bb83b6f5ff2f640733c2e508779b3bc52800e4f6
* Propagate nativeID in createAnimatedComponent
Summary:
Changelog: [internal]
https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/Libraries/Animated/createAnimatedComponent.js?commit=1b6ce6c3a69a&lines=82-112
`_isFabric` in `createAnimatedComponent` returns false for Fabric component, that's why nativeID was not being assigned and view got flattened.
To fix this, props.nativeID is propagated. SnackBar already has nativeID https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/RKJSModules/Libraries/FDS/FDSLightweightFeedback/DEPRECATED_FDSSnackBar.js?commit=1b6ce6c3a69a&lines=277
Reviewed By: PeteTheHeat
Differential Revision: D23757304
fbshipit-source-id: 9e4b4599c95b8af8767793bc8cdce717a347a273
* Reintroduce experiment flag for Reparenting/Flattening Differ
Summary:
This flag was deleted in D23374948 (https://github.com/facebook/react-native/commit/6729a3e0bfc01119c8513dfcbb1f5fbe5fe81263), reintroduce it.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23771273
fbshipit-source-id: ae9595194bf14bc740d05b2ca6e7b5e22bdd566f
* Add cause to jsi::instrumentation::collectGarbage
Summary:
Continuing the adding of a "cause" field for logging to GCs.
This allows embedders of Hermes (such as React Native) to specify
the cause of a call to `collectGarbage`.
Notably, this allows Hermes to know when a GC is triggered by a memory warning.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23742099
fbshipit-source-id: 99453e632328c00045b92a72f789d41c898dc518
* Update Flipper (#29787)
Summary:
The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it.
Fixes
This fixes https://github.com/facebook/react-native/issues/29492 /
https://github.com/facebook/flipper/issues/1399
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[general][changed] - Update Flipper to 0.54
Pull Request resolved: https://github.com/facebook/react-native/pull/29787
Test Plan:
Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present.
Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error:
```
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
[armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt'
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
return int(wrapNoInt(open, name, flags, mode));
^~~~~~~~~
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F'
ssize_t wrapNoInt(F f, Args... args) {
^
1 error generated.
make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1
make: *** Waiting for unfinished jobs....
fcntl(): Bad file descriptor
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
[armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp
```
No idea if it is related. I guess not since without making the change I got the same error.
Reviewed By: mweststrate
Differential Revision: D23767388
Pulled By: fkgozali
fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e
* Fix flattening/unflattening case on Android
Summary:
There are cases where we Delete+Create a node in the same frame. Practically, the new differ should prevent this, but we don't want to rely on that necessarily.
See comments for further justification on why deleteView can do less work overall.
In reparenting cases, this causes crashes because dropView removes *and deletes* children that shouldn't necessarily be deleted.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775453
fbshipit-source-id: c577c5af8c27cfb185d527f0afd8aeb08ee3a5fe
* Have BatchMountItem log the exact item that crashes
Summary:
Because BatchMountItem executes many items, sometimes it's unclear which MountItem causes a crash. Catch and log the exact item.
This shouldn't cause perf regressions because we have a try/catch block in FabricUIManager where execute is called.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775500
fbshipit-source-id: c878e085c23d3d3a7ef02a34e5aca57759376aa6
* Additional differ test: flattening differ should not produce DELETE and CREATE mutation for the same tag in the same frame
Summary:
See additional assertion. Tests still pass, so no other change was necessary.
Changelog: [Internal]
Differential Revision: D23775553
fbshipit-source-id: 57d3191f25dd55ab4da189207f6d201a31b175e0
* Fabric: Removing catching all exceptions in UIManager::completeRoot
Summary:
This is a revert of D23529233 (https://github.com/facebook/react-native/commit/902611f14837752353e919dd1740812ec7260fb8).
It turns out it was a bad idea. With this catch-all thing, we don't get new information. Yeah, we crash earlier now but seems we have even less information about the crash. :(
I think D23754284 (https://github.com/facebook/react-native/commit/04c874bd9c6b15274fd87acf10cb3533b2eabc0d) should fix the issue.
Changelog: [Internal] Fabric-specific internal change.
Original commit changeset: 7ac7fb26ac08
Reviewed By: sammy-SC
Differential Revision: D23786086
fbshipit-source-id: 86784df0193abfb7328c4d5a16a9af4214e9a161
* Fabric: Marking all JS function lambdas `noexcept` in UIManagerBinding
Summary:
Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue).
Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core.
This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling.
I hope that will give us much more informative crash reports.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23787492
fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642
* Move TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
Summary:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D23362253
fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37
* Notify ViewManagers when a View is deleted
Summary:
In a previous recent diff we changed Android's Delete mount instruction to *not* recursively delete the tree. This is fine, but because of that, we stopped calling `onDropViewInstance` when views are normally deleted.
Bring back that behaviour.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23801666
fbshipit-source-id: 54e6b52ab51fff2a45102e37077fe41081499888
* Prevent calling onTextLayout with the same value
Summary:
Changelog: [internal]
In D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) I made a mistake. I prevented calling `onTextLayout` unless there are attachments in the component. It fixed the problem because I unintentionally prevented `onTextLayout` to be called. Therefore, changes from D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) need to be reverted.
To prevent infinite loop in `onTextLayout`, ParagraphEventEmitter checks if `linesMeasurements` have changed before dispatching it to JS.
Reviewed By: shergin
Differential Revision: D23782717
fbshipit-source-id: 0e84ae4f46d79ce0cf4c7340cd32be6f562ae179
* TurboModule Android: compile TurboModule C++ Core into ReactAndroid
Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.
New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate
To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23805717
fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
* Add additional logging and asserts to StubViewTree
Summary:
Helps in testing LayoutAnimations or differ changes.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23797890
fbshipit-source-id: 1e612c04f9fbb256f2ace8a4a2ed9a477b4695a1
* Deleting unnecessary Differentiator code
Summary:
In the new Flattening differ, I experimentally verified that these two code paths are not hit (or redundant) and deleted them.
One of the branches did nothing and the other produced duplicate DELETE mutations for the same tag, that is handled elsewhere.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23806161
fbshipit-source-id: 9ad2929e2d719a7b9b34640ed35f7a696103604b
* LayoutAnimations: simplify index adjustment, (un)flattening detection
Summary:
In this diff I simplify index adjustment and add comments to rigorously describe what we're doing at each step of index adjustment.
I've also made unflattening detection more correct, robust, and slightly more efficient.
Bugs that existed before:
1) The reparenting detection that existed in the animations layer had some subtle bugs. I don't have proof that it results in any correctness issues or crashes, but I suspect it.
2) Correctness of index adjustment: there were cases where the Android mounting layer would crash because LayoutAnimations would try to remove a View at an index, but the index was wrong. This is why I sat down and diagrammed the relationships between all the bits of data we have for index readjustment - I believe this to be correct now.
3) Correctness of INSERT index adjustment: I had the insight that when we have batches of INSERTs to consecutive indices, we essentially want them to be treated as a single INSERT for adjustment purposes, so that they're all placed consecutively in the view layer. I added `ConsecutiveAdjustmentMetadata` to deal with this, and there are more comments in the code.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23806163
fbshipit-source-id: cd9e94945034db8b840f2a806c6377034a91af61
* Deploy Flow v0.134.0
Summary: Changelog: [Internal]
Reviewed By: dsainati1
Differential Revision: D23769795
fbshipit-source-id: 520e3974a53ba5961a081219c0cbf19b7dfade06
* Daily `arc lint --take CLANGFORMAT`
Reviewed By: zertosh
Differential Revision: D23811656
fbshipit-source-id: 4104948d2e4db786998320bcfdb1598d4a497f2d
* Add extras to timespan and points in performance logger
Summary:
Changelog:
[Internal][Added] Added point-level extras to performance logger
Reviewed By: lunaleaps, rubennorte
Differential Revision: D23730275
fbshipit-source-id: 285c5d7ac769bd109df7ce0294da024401edf7d3
* Making Android versionCodeOverride for new apps using the template human-readable (#29808)
Summary:
The current calculation on versionCodeOverride is not human-readable.
Imagine if we have an android app with **versionName** `4.0` and **version code** `4`.
In the current implementation, the result of **versionCode** `4` for `armeabi-v7a` will be the seemingly arbitrary **1048580**. This makes the version code to be seemingly arbitrary and hard to read for humans. This PR proposes to change this calculation closer to google implementation of build number in Flutter (`abiVersionCode * 1000 + variant.versionCode`).
https://github.com/flutter/flutter/blob/39d7a019c150ca421b980426e85b254a0ec63ebd/packages/flutter_tools/gradle/flutter.gradle#L643-L647
With this change, our app with `versionCode 4 versionName "4.0"` for `armeabi-v7a` will have **1004** as the version code instead of the seemingly arbitrary **1048580**. As you can see adopting the flutter style implementation make the version code easier to read and debug.
**1004**
**1** - The ABI Type `["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]`
**004** - Our versionCode.
Hopefully, this can prevent future issues like this https://github.com/facebook/react-native/issues/29790.
## Changelog
[Android] [Changed] - Making Android versionCodeOverride for new apps using the template human-readable
Pull Request resolved: https://github.com/facebook/react-native/pull/29808
Reviewed By: sammy-SC
Differential Revision: D23804632
Pulled By: fkgozali
fbshipit-source-id: 89b2c196b3bfe01fa608dfb595db6d3314ca1d63
* Codegen Android: adjust JNI output to compile from Gradle
Summary:
This adjusted the C++ output for Android codegen (NativeModule specs) so we can compile it with ndk-build in Gradle:
* Use `#include` instead of `#import` for header files
* Added `#pragma once`
* Removed direct include of `<fb/fbjni.h>` -- this is not necessary
* Added generated Android.mk file based on library name
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809082
fbshipit-source-id: 11ddfea7b48c8b2eb6efe885641ace4fc327d50d
* Codegen Android: Compile ReactAndroid codegen C++ output
Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.
Note: RNTester specific C++ spec files are not compiled here.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809081
fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44
* Use Element<> in FindNodeAtPointTest
Summary: Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23815171
fbshipit-source-id: bf420be172a55a966f8881371473e121c3848c78
* Fix ordering of children in LayoutableShadowNode::findNodeAtPoint
Summary:
Changelog: [internal]
`LayoutableShadowNode::findNodeAtPoint` was iterating children in incorrect order and wasn't taking zIndex into accout.
Reviewed By: JoshuaGross
Differential Revision: D23814866
fbshipit-source-id: 38eee297147a5c5912304d139bb10f8b16ae2ee1
* Call stopObserving on correct queue
Summary:
Since `dealloc` can be called from any thread, this would result `stopObserving` being called on a different thread/queue than the specified `methodQueue`. We specifically encountered this issue with a module needing the main queue having its `stopObserving` called on a background queue.
Changelog:
[iOS][Fixed] - Call [RCTEventEmitter stopObserving] on specified method queue
Reviewed By: RSNara
Differential Revision: D23821741
fbshipit-source-id: 693c3be6876f863da6dd214a829af2cc13a09c3f
* Pull out construction of Layout from TextLayoutManager.measureText into separate function
Summary:
Changelog: [Internal]
Construction of Layout will be needed in `TextLayoutManager.measureLines`, pulling it out into separate function prevents code duplication.
Reviewed By: shergin
Differential Revision: D23782905
fbshipit-source-id: 8ab817559ca154716a190ca1012e809c5fa2fd6e
* Wire call from C++ to Java to get lines measurements
Summary: Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23782998
fbshipit-source-id: fa9bda274c024d5bbd3ca24f394b5d76f8c07ad2
* Implement onTextLayout on Text component.
Summary:
Changelog: [Internal]
Add `Text.onTextLayout` implementation to Android's Text component.
Reviewed By: JoshuaGross
Differential Revision: D23782311
fbshipit-source-id: fdb5709aaf68efee0ab895a6661396f92cfc768a
* Fix Xcode bundler in staging and release (#29477)
Summary:
Revert "feat: improve monorepo support by removing redundant PROJECT_ROOT (https://github.com/facebook/react-native/issues/28354)"
This reverts commit a8e85026cfa60056b1bcbcd39cde789e4d65f9cb.
This commit a8e85026cfa60056b1bcbcd39cde789e4d65f9cb somehow broke the bundler when making a staging or release build in Xcode that results in unresolved files and main.jsbundle nonexistance issue. I figured this out by replacing react-native-xcode.sh from RN v0.63.2 by the one from v0.62.2 where everything works just fine and then reverting the changes line by line. It seems like this pr will fix similar issues stated here https://stackoverflow.com/questions/62806319/main-jsbundle-does-not-exist-this-must-be-a-bug-with-main-jsbundle-issue-afte/62829256#62829256 and here https://github.com/facebook/react-native/issues/29205
## Changelog
[iOS] [Fixed] - fix "main.jsbundle does not exist" issue
Pull Request resolved: https://github.com/facebook/react-native/pull/29477
Test Plan:
With react-native-xcode.sh from RN v0.63.2
With my changes
Reviewed By: sammy-SC
Differential Revision: D23817847
Pulled By: hramos
fbshipit-source-id: 4b729c1231d30e89073b2520aeadee944c84421c
* New Share API Use Cases (#29856)
Summary:
* New use cases for share API in rn-tester
## Changelog
[General] [Changed] - Changed use cases for share API in rn-tester
## Test Plan
* Tested app in both Android and iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/29856
Reviewed By: hramos
Differential Revision: D23784222
Pulled By: rickhanlonii
fbshipit-source-id: f311201a49e0a76abb6634232106ed756143da30
* Open source react-native-modules ESLint rule
Summary:
Open source this ESLint rule so that we can lint our open source NativeModule specs.
Changelog: [Internal]
Reviewed By: shergin, cpojer
Differential Revision: D23791748
fbshipit-source-id: e44444bc87eaa9dc9b7f2b3ed03151798a35e8a5
* feat: enable bitcode (#365)
Summary:
Bitcode is turned on by default in React Native and so, setting it here as well.
Changelog: [iOS] [Changed] - Upgraded JSI with a new HERMES_ENABLE_BITCODE flag
Pull Request resolved: https://github.com/facebook/hermes/pull/365
Reviewed By: tmikov
Differential Revision: D23823228
Pulled By: Huxpro
fbshipit-source-id: d43638818a733f6a87b2f4a1ecadad8ea9c7a419
* Add new ReactMarkers for bridgeless init start/end
Summary: Adding two new ReactMarkers for start and end of bridgeless initialization. Creating new ones instead of reusing existing ones to make it easier to differentiate data from the bridge vs. bridgeless, and also because our existing markers 1) aren't very easy to understand, and 2) don't map cleanly to the new architecture.
Reviewed By: PeteTheHeat
Differential Revision: D23789156
fbshipit-source-id: 2ed10769e08604e591503a2bc9566aeb1d0563ed
* Set useLineSpacingFromFallbacks when measuring text
Summary:
Changelog: [internal]
When paper measures text, it sets `useLineSpacingFromFallbacks` flag on the Layout object. In Fabric this was missing and can cause incorrect layout.
Reviewed By: JoshuaGross
Differential Revision: D23845441
fbshipit-source-id: 538f440cdbbf8df2cba0458837b80db103888113
* Make React-Core compatible with Swift modules (#29995)
Summary:
Related to https://github.com/facebook/react-native/issues/29633
Support Swift based libraries using Xcode 12’s build system.
## Changelog
[iOS] [Fixed] - Support Swift based libraries using Xcode 12’s build system.
Pull Request resolved: https://github.com/facebook/react-native/pull/29995
Test Plan:
* Building RNTester still works
* Swift based pod tested in https://github.com/mrousavy/react-native-blurhash/issues/58
Reviewed By: fkgozali
Differential Revision: D23824438
Pulled By: appden
fbshipit-source-id: 418caf9808cb6326e3d6efdc8b37131a5705e7f6
* Sort logger alphabetically
Summary:
Rearranging to alphabetically sort, no functionality changes
Changelog: [Internal]
Reviewed By: rubennorte, motiz88
Differential Revision: D23836997
fbshipit-source-id: 00232b88379e44920ecb74fa6ff43f36d941d93b
* Add close() to IPerformanceLogger
Summary:
To represent a final state where a logger should no longer be used
Changelog: [Internal] - To represent a final state where a logger should no longer be used
Reviewed By: rubennorte
Differential Revision: D23845307
fbshipit-source-id: 4b2bfda4f7425ba6bc8e5e1233d9baea60dd8667
* RNTester Android: Add stub C++ for TurboModule provider (#30014)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30014
This is the base setup to compile C++ as part of RNTester app. There is no dependencies on ReactAndroidNdk lib yet, just a bunch of ndkBuild setup in Gradle. Note: this is using Gradle's `nkdBuild` support instead of calling `ndk-build` manually like in ReactAndroid/build.gradle.
Reference: https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ExternalNativeNdkBuildOptions.html
Note that `ANDROID_NDK` env var is honored to pick the right NDK version.
For now, this is gated behind `USE_CODEGEN` env variable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23887058
fbshipit-source-id: 7a962649461d15af46999a15b900464543e5b05c
* New Button Component Use Cases (#29848)
Summary:
* New use cases for button component in rn-tester
* E2E tests for the button component
## Changelog
[General] [Changed] - Changed use cases for button component in rn-tester
## Test Plan
After -
Before -
Pull Request resolved: https://github.com/facebook/react-native/pull/29848
Reviewed By: hramos
Differential Revision: D23649694
Pulled By: rickhanlonii
fbshipit-source-id: 3590eca08ea58c771596ad731f74eb233b1a40d8
* Minor Code Improvements in RNTester (#29868)
Summary:
* Update single-letter variable names to be more descriptive
* Remove event listener on component unmount
* Add flow types
* Refactor RNTesterNavbar to use descriptive component names
Pull Request resolved: https://github.com/facebook/react-native/pull/29868
Reviewed By: hramos
Differential Revision: D23598579
Pulled By: rickhanlonii
fbshipit-source-id: c5cfc61d7b2fcb2942bf149d0a8ba0b58b0192e6
* Prevent change of delegate in RCTUITextView
Summary:
Changelog: [internal]
# Problem
`[RCTUITextView setDelegate]` is a public method and if something changes the delegate, appropriate events won't be called on the component (onTextChange, onSelectionChange and the others).
# Solution
Prevent setting of delegate from outside of the class. Ideally we would want to hide `setDelegate` altogether but that would require a rewrite of `RCTUITextView`.
Reviewed By: JoshuaGross, shergin
Differential Revision: D23813095
fbshipit-source-id: 8b76ac86727d262d0f9b81adfc8e75157847284c
* Fix touch handling in bridged paper components
Summary:
Changelog: [internal]
If view was bridged from Paper, hit testing would return Paper view which doesn't have reference to Fabric's event emitter.
To fix this, if the bridged view is returned from hit testing, it is swapped with interop view which has reference to event emitter.
Reviewed By: shergin
Differential Revision: D23840054
fbshipit-source-id: d4aa4ee8da4e1da80d2e2b69b79ed82d726f04e3
* TurboModule Android: add dependency on ReactAndroid codegen output to RNTester
Summary:
This adds shared libraries dependencies to RNTester so that it can call `ReactAndroidSpec_ReactAndroidSpec_ModuleProvider()` C++ lookup function. That function is generated by the react-native-codegen during build time. This does not make RNTester use TurboModule yet, just the necessary setup to link the C++ libs together.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23901952
fbshipit-source-id: fd5ee0ca266609207962adc5ceaf814956052eec
* Fix rounding in Slider component
Summary:
Changelog: [Internal]
There was a typo in condition. We need to be comparing step prop and not value. The same condition is implemented in Paper.
Reviewed By: JoshuaGross
Differential Revision: D23903493
fbshipit-source-id: 37506d0fac63f624332041602489ab1cf378bfcc
* Do not override decoders to RCTImageLoader (#29711)
Summary:
I (actually, [we](https://github.com/expo/expo/issues/9858)) noticed GIFs are no longer animating in Expo client after [enabling TurboModules](https://github.com/expo/expo/pull/9687).
## Changelog
[iOS] [Fixed] - Fix `RCTImageLoader` not using decoders provided.
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/29711
Test Plan:
The cat is moving! Before applying this commit `RCTGIFDecoder` provided in the initalizer is removed from the `_decoders` array in the
```objc
_decoders = [_bridge modulesConformingToProtocol:protocol(RCTImageDataDecoder)];
```
Also, compare
https://github.com/facebook/react-native/blob/8f306cd66a8bc6054ee13701f02329ab5817b69a/Libraries/Image/RCTImageLoader.mm#L243-L250
and
https://github.com/facebook/react-native/blob/8f306cd66a8bc6054ee13701f02329ab5817b69a/Libraries/Image/RCTImageLoader.mm#L177-L184
This PR makes `_decoders` behave the same as `_loaders`.
Reviewed By: PeteTheHeat
Differential Revision: D23908238
Pulled By: fkgozali
fbshipit-source-id: 1d7a6e0d180277f23d8c28916734713bc1833b8b
* Fix rounding issue when setting padding
Summary:
Changelog: [Internal]
Padding needs to be rounded down (floor function), not rounded to the closest natural number.
Otherwise the content of the view might not fit.
Reviewed By: JoshuaGross
Differential Revision: D23905145
fbshipit-source-id: e84d70155b207144b98646dd0c4fea7a8c4bd876
* LayoutAnimations: force props to update when executing "final" mutations
Summary:
When an animation is completed or a conflicting animation is detected, force props, state, layout, etc to update.
Currently, when a final animation mutation is queued, some attributes can be updated but not others, causing unexpected visual glitches at least on Android.
Some of these are arguably component bugs, but it's easier to just flush all attributes by tricking the platforms into updating all attributes. This will also prevent us from having to track down more of these bugs, potentially.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23886519
fbshipit-source-id: 8e5081bbe3b7843c16c0f283fa07fdec0e211aa8
* TurboModule Android: compile codegen C++ output into librntester_appmodules.so
Summary:
The react-native-codegen provides Android.mk in the Android C++ output, but for RNTester (or hosting apps), we should just compile the codegen output with the rest of the app-specific C++ files. This is to simplify the build configuration, and also to not add too many additional .so libs to the APK.
With this commit, `RNTesterAppModuleProvider.cpp` should be "complete" for RNTester use-case. This TurboModule lookup function is the one described in https://github.com/react-native-community/discussions-and-proposals/issues/273.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23913149
fbshipit-source-id: d1ca136787b87a0e8e6504318e1f0a78efef46ea
* Follow-up for fixing xiaomi NullPointer crash
Summary:
This is a follow-up for fixing the xiaomi NullPointer crash (D23331828 (https://github.com/facebook/react-native/commit/07a597ad185c8c31ac38bdd4d022b0b880d02859) D23451929 (https://github.com/facebook/react-native/commit/b5b4a7041027fd767850a564b5d80fa4a98ba2a2)):
1, Clean up previous temporary fix in js.
2, Cover all cases including caretHidden is set and isn't set, in previous fix if caretHidden isn't set then fix won't be executed.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D23816541
fbshipit-source-id: a7543f6767430abb74141a747b08391986662958
* Workaround for Date Picker in iOS14
Summary:
iOS14 has introduced new styles for date picker. The default new calendar style breaks the old spinner type style.
This is a workaround to keep the spinner style as a default, until the calendar style is properly supported. According to [this github comment](https://github.com/react-native-community/datetimepicker/issues/285) it works well.
This will fix DatePicker for both Fabric and Paper, since Fabric uses the interop layer to render it.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23935328
fbshipit-source-id: 1a7fadba274e0537f0ac4ced60e23e7c809d57dc
* Group accessible views using the view hierarchy
Summary: In iOS when a parent UIView returns YES on [shouldGroupAccessibilityChildren](https://developer.apple.com/documentation/objectivec/nsobject/1615143-shouldgroupaccessibilitychildren), VoiceOver groups together the accessible children of the parent view, regardless of their position on screen. In iOS this defaults to NO.
Reviewed By: sammy-SC
Differential Revision: D23844265
fbshipit-source-id: eb99bf0873ccfd9fb196f8f7b6eafe055f6ae810
* Fabric: Fixed crash in `colorComponentsFromColor()`
Summary:
This fixes a recently introduced crash in `colorComponentsFromColor()` (iOS implementation) caused by dereferencing a null pointer.
The fix is just a copy of a code fragment from a previous implementation.
Reviewed By: fkgozali
Differential Revision: D23944812
fbshipit-source-id: 977135dd75c4375affddfd75183e4890618ae819
* round up layoutWidth for Android 11 in ReactTextShadowNode
Summary:
in Android 11, there's an issue where Text content is being clipped. The root cause appears to be a breaking change in how Android 11 is measuring text. rounding up the layoutWidth calculation mitigates the issue.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23944772
fbshipit-source-id: 1639259da1c2c507c6bfc80fed377577316febac
* Don't crash when promise task is cancelled before its resolved (#29969)
Summary:
This pull request fixes a potential `TypeError` in TaskQueue.js, that happens if a promise is added to the task queue, which is cancelled between the promise starting and resolving.
The exact error this resolves is
```js
TypeError: TaskQueue: Error resolving Promise in task gen1: Cannot set property ‘popable’ of undefined
167 | queueStackSize: this._queueStack.length,
168 | });
> 169 | this._queueStack[stackIdx].popable = true;
| ^
170 | this.hasTasksToProcess() && this._onMoreTasks();
171 | })
172 | .catch(ex => {
at Libraries/Interaction/TaskQueue.js:169:46
```
This specific error was also reported in https://github.com/facebook/react-native/issues/16321
## Changelog
[General] [Fixed] - Prevent TypeError in TaskQueue when cancelling a started but not resolved promise.
Pull Request resolved: https://github.com/facebook/react-native/pull/29969
Test Plan:
The added test demonstrates the error, if run without the fixed applied to TaskQueue.js.
This is a race condition error, so is difficult to replicate!
Reviewed By: yungsters
Differential Revision: D23785972
Pulled By: appden
fbshipit-source-id: ddb8d06b37d296ee934ff39815cf5c9026d73871
* Android: consolidate various prebuilt C++ .so configuration into Android-prebuilt.mk
Summary:
To make it easier for hosting app or other lib to get access to the ReactAndroidNdk .so outputs, let's define common targets in a dedicated Android-prebuilt.mk. Hosting app's Android.mk just need to include the mk path.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23938538
fbshipit-source-id: 850d690326d134212d5f040c6fa54ab50c53cb87
* TurboModule Android: rename libreact_nativemodule_manager to libturbomodulejsijni
Summary:
TurboModule Java files are still using the old lib name: `turbomodulejsijni`, so let's keep it that way for now.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23946945
fbshipit-source-id: ff095ff51dca532c82e67e1c75e9a4e9be392d61
* TurboModule Android: Implement TurboModuleManagerDelegate specific to RNTester
Summary:
This provides the RNTester specific impl of the manager delegate. The class is responsible to provide module lookup during runtime for TurboModule, and the C++ impl is using the codegen-generated lookup functions from :ReactAndroid and :packages:rn-tester:android:app Gradle targets.
Note: RNTester still needs to explicitly enable TurboModule and instantiate this manager before it can activate TurboModule.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23938537
fbshipit-source-id: 7957847ecc58fef8d9a276d9d3d477ecec36a700
* TurboModule Android: allow RNTester to activate TurboModule system
Summary:
If built with `USE_CODEGEN=1` flag set, RNTester now activates the TurboModule system, also using various codegen output from the previous commits.
Note that this is very early integration, and not thoroughly tested yet.
To verify:
```
console.warn('TM enabled?', global.__turboModuleProxy != null);
```
{F337454276}
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23946944
fbshipit-source-id: 5838aeb9ded07b1cc0fcb069535d1c6fb3725973
* Fix passing react native path in Podfile template (#29285)
Summary:
Since https://github.com/react-native-community/cli/commit/e949e234b03fb65f8e4ed2706dfaa745aa59a14f#diff-d1800049b92343288bcbc1c484575058 the RN cli script returns an object with `:reactNativePath` instead of just JSON. Not super familiar with how objects / JSON works in ruby but using this syntax instead works.
## Changelog
[Fixed] [iOS] - Fix passing react native path in Podfile template
Pull Request resolved: https://github.com/facebook/react-native/pull/29285
Test Plan: Tested in a project inside a monorepo using the latest version of RN CLI that the proper react-native path is now passed.
Reviewed By: fkgozali
Differential Revision: D23941162
Pulled By: hramos
fbshipit-source-id: 0115412ec6d6bca101612d760dfc00cf89d97f1e
* Animated: Early detection of division by zero in AnimatedDivision
Summary:
Same as D20969087 (https://github.com/facebook/react-native/commit/be7867375580ed391bb10c50b768d998087e848d) but a bit more sophisticated.
We currently see a lot of errors happens because of division by zero in AnimatedDivision module. We already have a check for that in the module but it happens during the animation tick where the context of execution is already lost and it's hard to find why exactly it happens.
Adding an additional check to the constructor should trigger an error right inside render function which should make the error actionable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: fkgozali
Differential Revision: D23908993
fbshipit-source-id: d21be9a72ec04fe4ff0740777d9ff49cf1bcde73
* Fabric: Failing early in case if a argument of `-[RCTComponentViewFactory registerComponentViewClass:]` is nil
Summary:
Subject.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23914517
fbshipit-source-id: 1c909e7d21b12326881990ecf855e814bf957f3c
* Fabric: Adding `#pragma once` to `ImageTelemetry.h`
Summary:
Without this thing some stuff does not compile.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: fkgozali
Differential Revision: D23948622
fbshipit-source-id: f066ada183c0fd6a7b5eec542395d44bbbfe80a3
* Make blocking people work in Dating Settings
Summary:
Blocking people didn't work in Dating Settings without the Bridge.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23904867
fbshipit-source-id: 4a68b9d99fcc812f6616783a06dc047a3bc64491
* Fix slider's initial value
Summary:
Changelog: [Internal]
value needs to be set after minimum and maximum, otherwise it gets pinned to previous minimum/maximum.
Default minimum is 0 and maximum is 1. If we set value to 20 and maximum to 50, previously the value would get pinned to 1 (maximum value).
See [Apple Docs](https://developer.apple.com/documentation/uikit/uislider/1621346-value?language=objc) for more.
Reviewed By: JoshuaGross
Differential Revision: D23903545
fbshipit-source-id: 8e9dd49ced79d43b9591c7d24de59b9eaff5bdfd
* Do not attach root view until size is available
Summary:
Changelog: [internal]
# Why is text laid out twice in Fabric?
Layout constraints (min and max size) change during startup of Fabric surface.
1. `Scheduler::startSurface` is called with max size being {inf, inf}.
2. `Scheduler::constraintSurfaceLayout` is called with max size equal to viewport.
These are two operations that don't happen one after the other and on Android, CompleteRoot is called from JS before second operation is called. This triggers layout with max size {inf, inf} and later when second operation is called. Layout happens again now with correct size.
# Fix
Make sure `Scheduler::startSurface` is called with proper values and not {inf, inf}.
Reviewed By: JoshuaGross, yungsters
Differential Revision: D23866735
fbshipit-source-id: b16307543cc75c689d0c1f0a16aa581458f7417d
* RNTester: Add TextInput example to RTL tester
Summary:
Add a TextInput to RTL screen in RNTester, to test RTL languages with TextInput.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23914627
fbshipit-source-id: 84c62efe7034c0dfa2ef21be3f085880292c3930
* Update PerformanceLogger to nullable timespans, points, extras
Summary: Changelog: [Internal][Fixed] - When we close performance loggers (D23845307 (https://github.com/facebook/react-native/commit/aebb97b9c64a8d84cf852ae8efc5ef28b36da610)) we cannot rely that a timespan/point/extra will be in perf logger. Update types to reflect that.
Reviewed By: rubennorte
Differential Revision: D23907741
fbshipit-source-id: 63673aa69cd8c76253e4fee3463e37c86265cf7b
* Make the Instagram app compile again
Summary:
Wrap iOS 14 SDK code in a `#if/#endif` so that the Instagram app compiles again
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23948336
fbshipit-source-id: 67e6ee48d1951ae405c12b4ad39cf8c9817df627
* Pressability: Support Lazy Hook Initialization
Summary:
Changes `usePressability` so that it accepts a nullable `config` argument.
This makes it possible for a component to use `usePressability` and lazily allocate the `config` and subsequent instance of `Pressability`. This can be useful for components that are commonly allocated but seldom pressed because it lets many usages of `usePressability` avoid allocating many extraneous objects.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D23708206
fbshipit-source-id: 4a5063067131ce8c957fb16c49a2045e8c0b19fa
* Text: Cleanup Native Component Configuration
Summary:
Cleans up the native component configuration for `RCTText` and `RCTVirtualText`.
This //does// lead to a breaking change because `Text.viewConfig` will no longer exist. However, I think this is acceptable because `viewConfig` has already long stopped being an exported prop on other core components (e.g. `View`).
Changelog:
[General][Removed] - `Text.viewConfig` is no longer exported.
Reviewed By: shergin
Differential Revision: D23708205
fbshipit-source-id: 1ad0b0772735834d9162a65d9434a9bbbd142416
* remove most of tvOS remnants from the code (#29407)
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
* **[Internal] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
* chore: deduplicate lock, update packages repository fields (#30044)
Summary:
This small PR includes the following changes:
* deduplicate yarn lock file using [`yarn-deduplicate`](https://github.com/atlassian/yarn-deduplicate) package
* deduplicate script has been added as `update-lock`, let me know if you would like also to see this in [`postinstall`](https://docs.npmjs.com/misc/scripts) (to automatically optimize lock on every dependency change)
* according to the [npm docs](https://docs.npmjs.com/files/package.json#repository):
* main `package.json` repository field has been replaced with shorthand
* monorepo packages repository field has been extended by `directory`
The main goal of introducing deduplication script was to optimize the dependencies footprint while developing and speed up the initial installation process. Running `yarn-deduplicate` also increase the security in some way, because it enforces usage only of the latest version of the package. You can read more about the benefits in the deduplicate script [repository](https://github.com/atlassian/yarn-deduplicate#duplicated-packages).
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Added] - add yarn lock deduplication script
Pull Request resolved: https://github.com/facebook/react-native/pull/30044
Test Plan: `yarn install` was successful, this also should not affect yarn workspaces in any way.
Reviewed By: GijsWeterings
Differential Revision: D23959812
Pulled By: cpojer
fbshipit-source-id: e2455e3718378e1ce6206e79463d4083f8fe5d47
* Daily `arc lint --take CLANGFORMAT`
Reviewed By: zertosh
Differential Revision: D23986055
fbshipit-source-id: 7bfe9f06f236f8866e812db060edf3d089fe253c
* Convert AndroidDialogPicker to JS view configs
Summary:
Convert AndroidDialogPicker to JS view configs
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23911673
fbshipit-source-id: d5fefa997432f0096308ab5593ba74c2c07b71e1
* Fix dismissal animation of Modal Component
Summary:
Changelog: [Internal]
Fabric removes components bottom up (from leafs to the root).
This means that by the time Fabric hides Modal, it has no content and therefore it appears as if Modal disappears without Animation.
To fix this, we snapshot contents of the Modal before any of its contents are removed.
Reviewed By: shergin
Differential Revision: D23976244
fbshipit-source-id: 01c13b74e97f82816e8946fd9d1add1db10340b1
* Allow Java classes to hook into ScrollView scroll and layout events
Summary:
For advanced interop cases.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23984345
fbshipit-source-id: f5c2a43a1bf5937f9974bcc5c66c36ec35e679c5
* Remove unuse…
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The current calculation on versionCodeOverride is not human-readable.
Imagine if we have an android app with versionName
4.0and version code4.In the current implementation, the result of versionCode
4forarmeabi-v7awill be the seemingly arbitrary 1048580. This makes the version code to be seemingly arbitrary and hard to read for humans. This PR proposes to change this calculation closer to google implementation of build number in Flutter (abiVersionCode * 1000 + variant.versionCode).https://github.com/flutter/flutter/blob/39d7a019c150ca421b980426e85b254a0ec63ebd/packages/flutter_tools/gradle/flutter.gradle#L643-L647
With this change, our app with
versionCode 4 versionName "4.0"forarmeabi-v7awill have 1004 as the version code instead of the seemingly arbitrary 1048580. As you can see adopting the flutter style implementation make the version code easier to read and debug.1004
1 - The ABI Type
["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]004 - Our versionCode.
Hopefully, this can prevent future issues like this #29790.
Changelog
[Android] [Changed] - Making Android versionCodeOverride for new apps using the template human-readable
Test Plan