Android ReactActivity Destroy Prevents Successful OnActivityResult Calls
Description
If a native module opens an activity that redirects out of the application and the application is killed in the background by the Android OS, the react context is lost and the native module's activity is unable to call onActivityResult.
If the redirect from the third party app is back to the activity in the native module, the ReactActivity is not created at this point. When the native activity then sets result and finishes to return back to the ReactActivity the ReactActivity has to start up.
The React Native startup flow is:
ReactActivity#onCreateReactActivityDelegate#onCreateReactActivityDelegate#loadAppReactDelegate#loadAppReactRootView#startReactApplicationReactInstanceManager#createReactContextInBackgroundReactInstanceManager#recreateReactContextInBackgroundInnerReactInstanceManager#recreateReactContextInBackgroundFromBundleLoaderReactInstanceManager#recreateReactContextInBackgroundReactInstanceManager#runCreateReactContextOnNewThread
At this point ReactInstanceManager#setupReactContext is called on a background thread.
Meanwhile, ReactActivity#onActivityResult is called. In the Android activity lifecycle onActivityResult is called even before onResume (for reference. The calls from ReactActivity#onActivityResult pass through a few layers and end up at ReactInstanceManager#onActivityResult which checks if the ReactContext is null
@ThreadConfined(UI)
public void onActivityResult(Activity activity, int requestCode, int resultCode, Intent data) {
ReactContext currentContext = getCurrentReactContext();
if (currentContext != null) {
currentContext.onActivityResult(activity, requestCode, resultCode, data);
}
}
Because the context is being built on a background thread there is no guarantee that currentContext will be initialized at this point. Furthermore ReactInstanceManager#createReactContext is a fairly intensive function so it is actually very likely that currentContext is null.
This means that ReactContext#onActivityResult is not called and therefore, the data cannot be passed back to the ActivityEventListener which in my sample is the ReactContextBaseJavaModule.
React Native version:
System:
OS: macOS 10.15.7
CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
Memory: 118.90 MB / 32.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 13.14.0 - ~/.nvm/versions/node/v13.14.0/bin/node
Yarn: 1.22.5 - /usr/local/bin/yarn
npm: 6.14.4 - ~/.nvm/versions/node/v13.14.0/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.9.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: iOS 13.6, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
Android SDK:
API Levels: 19, 23, 26, 27, 28, 29
Build Tools: 27.0.3, 28.0.3, 29.0.0, 29.0.1, 29.0.2
System Images: android-21 | Google APIs Intel x86 Atom, android-23 | Google APIs Intel x86 Atom, android-26 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom, android-Q | Android TV Intel x86 Atom
Android NDK: Not Found
IDEs:
Android Studio: 4.0 AI-193.6911.18.40.6626763
Xcode: 11.6/11E708 - /usr/bin/xcodebuild
Languages:
Java: 1.8.0_265 - /usr/bin/javac
Python: 2.7.16 - /usr/bin/python
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: 0.63.3 => 0.63.3
react-native-macos: Not Found
npmGlobalPackages:
*react-native*: Not Found
Steps To Reproduce
- Clone
- https://github.com/zsweigart/react-native-crash
- cd into the directory and run
react-native run-android - On your device or emulator go to developer options
- Turn
Do Not Keep ActivitiestoOn - Set
Background Process LimittoNo background processes - Click
Open Activity - Click
Go to Web-> This should kill the original process in the background due to your developer settings; however, on some emulators I have noticed it does not. One way to guarantee this is to runadb shell am kill com.react_native_crashwhich will simulate a system process kill. Note you cannot kill the process by swiping it away because the OS will lose the information about the backstack. - Next run
adb shell am start -n com.react_native_crash/.RedirectActivity -d "redirect://crash" - Click
Return Result
Expected Results
After these steps in the console you should see
LOG RESULT
LOG Completed
which would indicate the onActivityResult was called properly and the callback to the js code was executed.
Snack, code example, screenshot, or link to a repository:
https://github.com/zsweigart/react-native-crash
Are there any updates on this issue? This is a problem with low memory devices as well when the main application launches other activities (like launching camera) and then the Android OS kills the activity that launched the camera along with the ReactContext.
@zsweigart Did you find any workaround for this issue? Maybe provide an own ReactInstanceManager implementation?
We have not worked on finding a work around and are currently accepting the rate errors until this is fixed
For the sake of cross-referencing most related issues from other modules and working on a workaround, I've created a repo: https://github.com/HugoGresse/react-native-issue-30277/blob/main/README.md
Workaround for react-native-image-crop-picker here
What changed to cause this? Is it a ReactNative change or an Android SDK update?
I can't believe there is no update on this issue.
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.
This issue needs attention, it impact a lot of apps through many libraries.
Same problem (image-crop-picker).
Facing the same issue... I think this issue needs attention.
This issue needs attention, facing the same thing!
Any one with a solution?
Currently facing the same issue with react-native-app-auth https://github.com/FormidableLabs/react-native-app-auth/issues/773
As a workaround, I can imagine one would use a Handler on the main thread (which is guaranteed here anyway), poll whether reactContext is still null and give up after a few retries (trying to cover as many crashes as possible but not waiting too long).
Obviously, one would need to patch react-native using patch-package to achieve that, but it would work across libraries.
It would be good to only keep a WeakReference to the activity to not leak it, unless this would be the last reference to it, in which case it'd be necessary to keep it around for those few seconds until the React context initializes.
Facing the same issue... I think this issue needs attention.
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue needs attention!
any solutions?