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:
This will fix a crash on Motorola devices on Android 7, where WebView fails to load due to initialisation issues in the WebViewChromiumFactoryProvider (Caused by org.chromium.base.library_loader.ProcessInitException).
## Changelog
[Android][Fix] - Exception with `Cannot load WebView` message will initialising WebView (along with existing checks)
Pull Request resolved: https://github.com/facebook/react-native/pull/33867
Test Plan: <img width="1368" alt="Screenshot 2022-05-19 at 02 21 57" src="https://user-images.githubusercontent.com/933314/169154293-c442a54f-96f5-4309-a6ce-c8f9c4beeb17.png">
Reviewed By: javache
Differential Revision: D36517673
Pulled By: cortinico
fbshipit-source-id: 4fa5b903529eb04d01ed8fa540cbd883224e8e62
Summary:
Changelog:
[Android][Fixed] - Fix Extras usage in Android implementation of Linking.sendIntent()
The implementation of sendIntent() has a bug in a way it uses extras map.
From JS layer the API sends and array of map, where each map contains exactly 2 entries: {"key" -> "name_of_extra_to_use", "value" -> value_of_extra_to_use}
However Java parsing was just picking a random pair out of this map and was sending it as extra.
Most frequently the result was "value" -> value_of_extra_to_use in Intent instead of name_of_extra_to_use -> value_of_extra_to_use
This diff fixes the problem
Reviewed By: lunaleaps
Differential Revision: D35516496
fbshipit-source-id: 7da0a1cb3b8aa30463004dbb47008c83d8e95bd1
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:
ModuleDataCleaner.cleanDataFromModules(**ReactContext**) is just like ModuleDataCleaner.cleanDataFromModules(**CatalystInstance**). However, one key difference is that this new method is bridgeless mode compatible. CatalystInstance doesn't exist in bridgeless mode.
Changelog: [Android][Added] Introduce ModuleDataCleaner.cleanDataFromModules(ReactContext)
Reviewed By: sshic
Differential Revision: D35286939
fbshipit-source-id: 1c09a3b34add88f848eab43b42b39ab624f0818b
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:
The check implemented in PR https://github.com/facebook/react-native/issues/29089 is flawed as the exception class name and message depends on the OS version as well as the OEM. In OxygenOS running android 11, it comes out as RuntimeException and the check fails and hence the crash occurs again. But on observing closely, its clear that the exception message is consistent across OEMs with similar strings appearing in them that have been included in the if check.
Hence there is a simple fix to this issue, by checking the message instead of the exception class.
Here is the snippet:
```
private Nullable CookieManager getCookieManager() {
if (mCookieManager == null) {
possiblyWorkaroundSyncManager(mContext);
try {
mCookieManager = CookieManager.getInstance();
} catch (IllegalArgumentException ex) {
// https://bugs.chromium.org/p/chromium/issues/detail?id=559720
return null;
} catch (Exception exception) {
String message = exception.getMessage();
// We cannot catch MissingWebViewPackageException as it is in a private / system API
// class. This validates the exception's message to ensure we are only handling this
// specific exception.
// The exception class doesn't always contain the correct name as it depends on the OEM
// and OS version. It is better to check the message for clues regarding the exception
// as that is somewhat consistent across OEMs.
// For instance, the Exception thrown on OxygenOS 11 is a RuntimeException but the message contains the required strings.
// https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/WebViewFactory.java#348
if (exception.getClass().getCanonicalName().contains("MissingWebViewPackageException") ||
(message!=null && (message.contains("WebView provider") ||
message.contains("No WebView installed")))){
return null;
} else {
throw exception;
}
}
}
return mCookieManager;
}
```
## Changelog
[General] [Added] - A fail proof check to catch any crash involving webview:
if (exception.getClass().getCanonicalName().contains("MissingWebViewPackageException") || (message!=null && (message.contains("WebView provider") || message.contains("No WebView installed"))))
[General] [Removed] - Flawed check to catch WebViewProvider crash:
if (message != null && exception.getClass().getCanonicalName().contains("MissingWebViewPackageException"))
Pull Request resolved: https://github.com/facebook/react-native/pull/33088
Test Plan:
This code has been tested rigorously on OnePlus Nord CE 5G (Oxygen OS 11.0) and Realme X (Realme UI 2.0) both running on Android 11 and reproducing the crash on a hybrid (Native android + ReactNative) app that showed this crash in production being dependent on WebViews. I have implemented an entire patched fork of 0.67.2 to fix this issue in our app.
How to test:
Launch any app that has a webview.
Go to settings->apps->Android System Webview -> disable.
Resume/Restart the app.
In this fix:
Open a webview and notice that the app will not crash.
In current version:
App crashes on startup as the exception escapes the catch block.
Even if it survives startup (did on Realme X), it will crash once you try to open a webview.
Reviewed By: rh389
Differential Revision: D34240097
Pulled By: cortinico
fbshipit-source-id: 0f1f9a3b078c0ad3074c7841392892cb70b427eb
Summary:
In https://github.com/facebook/react-native/issues/32975 I implemented the new `insetsController#setSystemBarsAppearance` interface, but I found that on Android 11 (API 30) it doesn't appear to work which I missed in earlier testing. It works correctly on Android 12 and the deprecated `systemUiVisibility` interface still works fine on Android 11, so I'm having Android 11 use the deprecated mechanism.
## 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] [Fixed] - Fix StatusBar on Android API 30
Pull Request resolved: https://github.com/facebook/react-native/pull/33058
Test Plan: Tested in `rn-tester` on simulators using Android 9, 10, 11, 12, and on an Android 9 device.
Reviewed By: lunaleaps
Differential Revision: D34050025
Pulled By: ShikaSD
fbshipit-source-id: ad80fae1446aca368b09df810785a1cc38383450
Summary:
Not setting locale for language/country neutral operation may cause bug depending on the default locale.
See https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#ROOT
Note: I am just searching for toLowerCase() and toUppercase() in my project's dependencies and send the same PR, in order to just be considered. Although I've seen the lack of explicit locale has caused issues for us, I am not sure if react-native is actually affected. I haven't checked for `String.format()` yet.
Example related issue: joltup/rn-fetch-blob#573
## Changelog
[Android] [Fixed] - Use root locale when converting string case.
Pull Request resolved: https://github.com/facebook/react-native/pull/33028
Reviewed By: ShikaSD
Differential Revision: D33943446
Pulled By: cortinico
fbshipit-source-id: d5be9392ea7c21a33436acac5b5e8c50b7c7e31e
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
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:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## 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
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
We forgot to make ClipboardModule TurboModule compatible. I think this was most likely because our codemods targeted all Java classes that extended ReactContextBaseJavaModule. The ClipboardModule extends ContextBaseJavaModule instead.
There are no other NativeModules that extend ContextBaseJavaModule.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D31291293
fbshipit-source-id: cf5d21898101699f8c349b013a77e8329339a8d3
Summary:
Addresses https://github.com/facebook/react-native/issues/28934
## 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] [Fixed] - When sending OS intents, always set "FLAG_ACTIVITY_NEW_TASK" flag (required by OS).
Pull Request resolved: https://github.com/facebook/react-native/pull/29000
Test Plan:
1. Open RNTester on Android
2. Go to Linking section
3. Try opening "POWER_USAGE_SUMMARY" intent
4. App should open settings, instead of crashing
Reviewed By: cortinico
Differential Revision: D30876645
Pulled By: lunaleaps
fbshipit-source-id: e427bfeadf9fb1ae38bf05bfeafd88e6776d71de
Summary:
This JavaScriptTimerManager interface calls into JavaScript to execute timers. For that reason, I think JavaScriptTimerExecutor is a better name for the interface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D30851912
fbshipit-source-id: de282068d18693fd67331586e66847105ea16531
Summary:
I applied the changes requested in this PR: https://github.com/facebook/react-native/pull/29089
We upgraded to RN 0.62.2 on our latest release and started to see again the "Failed to load WebView provider: No WebView installed" (see below for Crashlytics screenshot)
This crash had been fixed by https://github.com/facebook/react-native/pull/24533 but https://github.com/facebook/react-native/pull/26189 (added in 0.62) reverted the fix
Indeed the exception raised in Crashlytics is actually a `AndroidRuntimeException` and `MissingWebViewPackageException` is only part of the message.
For instance, in the screenshot above, the exception message is `android.webkit.WebViewFactory$MissingWebViewPackageException: Failed to load WebView provider: No WebView installed`
Now these crashes are quite tricky to reproduce, so to be on the safe side, I'm filtering out all exceptions containing `WebView` as suggested by thorbenprimke on the original fix.
If my reasoning is correct, it should fix siddhantsoni 's issue as well, since `WebView` is included in `MissingWebViewPackageException`
But following that reasoning, I am not sure https://github.com/facebook/react-native/pull/26189 fixed siddhantsoni 's issue, so siddhantsoni if you could check that this PR also fixes your issue, that would be great!
## Changelog
[Android] [Fixed] - Fix missing WebView provider crash in ForwardingCookieHandler
<!-- 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/32165
Test Plan:
I created a version of react native with this patch applied
```
"react-native": "almouro/react-native#release/062-2-fix-missing-webview-provider"
```
Before the fix ~0.1% of our users were impacted on Android, no new crashes have occurred after the update.
This is putting back what was already in place and working for us, but making the check wider to catch more errors.
Reviewed By: lunaleaps
Differential Revision: D30847404
Pulled By: sota000
fbshipit-source-id: fe3b5fa2c9ebde5bedd17a9d6394a52ccdbdf0d0
Summary:
This change migrates fetching locale information from the deprecated Android locale api to the new locale api on sdk version 30+. The old api was deprecated some time ago and should not be used.
https://developer.android.com/reference/android/content/res/Configuration#locale
## Changelog
[Android] [Changed] - Use new Locale API on Android 11 (API 30)+
Pull Request resolved: https://github.com/facebook/react-native/pull/30701
Test Plan:
```js
if (Platform.OS === 'android') {
locale = NativeModules.I18nManager.localeIdentifier; // returns ex. 'EN_us'
}
```
Reviewed By: mdvacca
Differential Revision: D30821396
Pulled By: lunaleaps
fbshipit-source-id: 31622cd9c71c6057ff98ab5245898bc687b5ac60
Summary:
Ship libjsi as a standalone dynamic library. This prevents problems
with exception handling caused by duplicate typeinfo across multiple
shared libs, and reduces bundle size by removing duplicate copies of
JSI.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30599215
fbshipit-source-id: abad1398342a5328daa825f3f684e0067cad7a96
Summary:
When retrieving the device dimensions through the JS `Dimensions` utility, the result of `Dimensions.get` can be incorrect on Android.
### Related issues
- https://github.com/facebook/react-native/issues/29105
- https://github.com/facebook/react-native/issues/29451
- https://github.com/facebook/react-native/issues/29323
The issue is caused by the Android `DeviceInfoModule` that provides initial screen dimensions and then subsequently updates those by emitting `didUpdateDimensions` events. The assumption in that implementation is that the initial display metrics will not have changed prior to the first check for updated metrics. However that is not the case as the device may be rotated (as shown in the attached video).
The solution in this PR is to keep track of the initial dimensions for comparison at the first check for updated metrics.
## Changelog
[Android] [Fixed] - Fix Dimensions not updating
Pull Request resolved: https://github.com/facebook/react-native/pull/31973
Test Plan:
### Steps to reproduce
1. Install the RNTester app on Android from the `main` branch.
2. Set the device auto-rotation to ON
3. Start the RNTester app
4. While the app is loading, rotate the device
5. Navigate to the `Dimensions` screen
6. Either
a. Observe the screen width and height are reversed, or
b. Quit the app and return to step 3.
### Verifying the fix
#### Manually
Using the above steps, the issue should no longer be reproducible.
#### Automatically
See unit tests in `ReactAndroid/src/test/java/com/facebook/react/modules/deviceinfo/DeviceInfoModuleTest.java`
### Video
https://user-images.githubusercontent.com/4940864/128485453-2ae04724-4ac5-4267-a59a-140cc3af626b.mp4
Reviewed By: JoshuaGross
Differential Revision: D30319919
Pulled By: lunaleaps
fbshipit-source-id: 52a2faeafc522b1c2a196ca40357027eafa1a84b
Summary:
ReactSoftException makes it seem like the class is an Exception, when it's actually a logger. This rename I think is more appropriate.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30251735
fbshipit-source-id: 550bd543388e698774ec31753200bd3f722d8c17
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
Fixes https://github.com/facebook/react-native/issues/31774.
This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load.
This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe.
The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer.
https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95
This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written.
## 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] [Fixed] - Fix support for blobs larger than 64 KB
Pull Request resolved: https://github.com/facebook/react-native/pull/31789
Test Plan:
A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source.
<img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" />
Reviewed By: ShikaSD
Differential Revision: D29674273
Pulled By: yungsters
fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db
Summary:
Extends https://github.com/facebook/react-native/pull/30694 to fix tests.
OkHttp v4 was released almost a year ago. Even though v3 is still receiving security and bug fixes, most of the new improvements and features are landing in v4. This PR bumps OkHttp from v3 to v4 and addresses backward-incompatible changes.
Side effects of this upgrade:
- OkHttp v4 depends on Kotlin's standard library, so react-native will have a transitive dependency on it.
- The dex method count of test apk has exceeded the maximum, so multidexing had to be enabled for android tests.
## 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] [Changed] - Bumping OkHttp from v3 to v4.
Pull Request resolved: https://github.com/facebook/react-native/pull/31084
Test Plan: Automated (relying on the test suite) and manual testing.
Reviewed By: fkgozali
Differential Revision: D27597430
Pulled By: ShikaSD
fbshipit-source-id: 967379b41c2bcd7cfd4083f65059f5da467b8a91
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:
Sometimes ```hasActiveCatalystInstance()``` is used to check if it's safe to access the CatalystInstance, which will still crash in Venice.
Previously we mitigate this by changing ```reactContext.hasActiveCatalystInstance()``` to ```reactContext.hasActiveCatalystInstance() || reactContext.isBridgeless()```.
To solve this for all and good the plan is:
1, Rename ```hasActiveCatalystInstance()``` to ```hasActiveReactInstance()``` so it won't sounds like CatalystInstance-only.
2, Implement hasActiveReactInstance() for Venice. D27343867
3, Remove previous mitigation. D27343952
This diff is the first step, by xbgs there are **58** non-generated callsites of ```hasActiveCatalystInstance()``` in code base which are all renamed in this diff.
Changelog:
[Android][Changed] - Rename "hasActiveCatalystInstance" to "hasActiveReactInstance"
Reviewed By: mdvacca
Differential Revision: D27335055
fbshipit-source-id: 5b8ff5e09b79a492e910bb8f197e70fa1360bcef
Summary:
This NativeModule will now be type-safe, and TurboModule-compatible.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26956332
fbshipit-source-id: 6651a003c70819934869dd6a8c664ef984d0efcb
Summary:
This diff migrates all NativeModules away from onCatalystInstanceDestroy() to the invalidate() method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26871595
fbshipit-source-id: 132f6b75e485361835769a2b53bc742eefa47b59
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859161
fbshipit-source-id: 654c055c53c0e420c6d9f2b0135055aec34269c9
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859157
fbshipit-source-id: 754a5b4ede8defa8b7742cc42e09cc7cbfe4e18d
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859160
fbshipit-source-id: ce84deafd1f20d1680d333d1a176b0493623a4ee
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859205
fbshipit-source-id: 5398d24d2592de3fbb80ca59192b5b46543aa5c5
Nicola Corti
Rachit Mishra
Hetan Thakkar
Vladyslav Stepanov
Chris Olszewski
Ramanpreet Nara
CodemodService Bot
Andrei Shikov
caioagiani
skychx
Kunal Farmah
Kuba Holuj
Hamid
Andres Suarez
Luna Wei
grgr-dkrk
Joshua Gross
Lulu Wu
Brent Kelly
Krzysztof Borowy
Rodolfo
Aaron Grider
Neil Dhar
Andres Riveros Moya
Jonathan Andrew
Moti Zilberman
Tomek Zawadzki
Araz Abishov
grgr-dkrk
Samuel Susla
