-
Notifications
You must be signed in to change notification settings - Fork 24.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MainActivity.onCreate(null) called more than once in release builds #10266
Comments
I think this'll happen when you set the activity:launchMode to standard (in AndroidManifest.xml). Might be related: #7079 |
Thanks @sbycrosz! I just tried that and unfortunately it made the problem worse, it happened even on the second try after swipe-killing the app. Tried the other |
We were observing the exact same issue on RN 0.35.0 on every Android version we tested (4.x - 6.x) in both release and debug modes. As implied by #7079 and #8570, what's happening here is that multiple You can see the multiple activities by dumping the activity stack. We also worked around this by setting Overall I think this is definitely a RN-level bug, as from the perspective of JS app code, you should be able to make a reasonable expectation that multiple instances of your app will not be launched inside the same Android task. At the very least I think the RN |
We also face the same problem on RN 0.32 and Android 5.1. However, the issue is reproduced only on Xiaomi and DOOGEE devices, but it seems OK on Samsung. If our app is built and run locally, the issue is not reproduced, despite debug or release mode. To reproduce the issue I have to deploy an apk to Google Play and install on a device. And after install on the first run the issue can be observed when switching between background and foreground modes. Setting P.S. Latest RN 0.37 has the issue. |
+1,RN v0.37 face the same porblem, even the empty project created by 'react-native init'. |
Basically echoing what has been said here, Would almost be interesting to submit a PR with Interesting note from the docs:
|
@cbrevik Yes, a PR is a good idea, although I'm still unclear as to whether |
@fadookie I've wondered about the same thing. I've tried to read up on it, but I can't find a definitive answer to that question. Since At the same time, we're probably masking an underlying problem with RN with this fix. It'd be nice to have the core contributors weigh in on this issue. |
Closing this issue because it has been inactive for a while. If you think it should still be opened let us know why. |
When I get time I might make a PR to change the template to one of the
defaults discussed above. Still not sure which one is better though.
…On Wed, Jun 14, 2017, 3:06 PM Facu Escobar ***@***.***> wrote:
@hramos <https://github.com/hramos> I've seen a few issues related to
this bug, and none of them has been fixed or taken by RN developers to fix
it.
can you guys stop closing issues by inactivity and start to fix them?
I am handling the same issue, I've tried all the options I've seen in all
closed issues, and different articles, but none of them fixed my problem.
This is a real issue, you guys should take a deeper look here.
Cheers.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10266 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGwrDKlOh6AifqnHkVMu-Zt5zrR23ryks5sEFlsgaJpZM4KPZcU>
.
|
Hello!
Issue Description
MainActivity.onCreate()
always seems to getnull
for itssavedInstanceState
parameter: firstly when the app starts, as expected, but then each time the app wakes after being backgrounded, every time thesavedInstanceState
parameter isnull
.null
forsavedInstanceState
, again, and subsequent calls are either passed a properBundle
of parcelled data, or aren't made at all.The post-launch
null
Bundle
s are problematic for us as we expect to be able to do initialisation work inonCreate()
- or at least to be able to use state data (saved inonSaveInstanceState()
and passed in viaonCreate
'ssavedInstanceState
parameter) to reconstruct our state in a newActivity
if the OS kills the previous one. However what's actually happening is that on the first run of an app, when it's backgrounded and then foregrounded again, theActivity
receivesonCreate(null)
a second time, so we have no chance to reconstruct any state as the passed-inBundle
isnull
, meaning the initialisation code overwrites any state, and our app-startup code gets properly tangled.I looked at
ReactActivity
but all I can see is that itsonCreate()
method just callssuper.onCreate()
inandroid.app.Activity
and thenmDelegate.onCreate()
, and I haven't been able to track this much further into RN so I don't know why this is happening, or the answer to any of these questions:savedInstanceState
'sBundle
null
in release mode?Any help or input would be very much appreciated, thanks!
Steps to Reproduce / Code Snippets
2a. Run app in debug mode via Android Studio.
2b. Hit the home button to background the app
2c. Restart the app by tapping its icon
2d. Check the logs
2e. Kill the app using the process manager
2f. Start the app by tapping its icon
2g. Repeat steps 2b-2d
3a. Run app in release mode via
react-native run-android --variant=release
.3b. Hit the home button to background the app
3c. Restart the app by tapping its icon
3d. Check the logs
3e. Kill the app using the process manager
3f. Start the app by tapping its icon
3g. Repeat steps 3b-3d
Expected Results
For each run, in debug and release mode respectively, I expect to see
MainActivity::onCreate() null
printed only once to the log, when the app is started and the activity in created, with any subsequent calls printing out a proper serializedBundle
value, passed in assavedInstanceState
.Actual Results
In debug mode, the results are as expected:
First run, immediately on being built & installed by Android Studio:
Second run, after killing the app process with a swipe and restarting the app:
(So far, so good.)
In release mode, the results are as described in the Issue Description:
First run:
Second run, after killing the app process with a swipe in the process manager and restarting the app:
Additional Information
The text was updated successfully, but these errors were encountered: