Android IllegalArgumentException in 3.1.7 #132
Comments
|
Hi @ashfurrow, thanks for your input here - we've actually had one other similar report and are actively looking into this one. So far, it has been challenging to reproduce. The other report indicated that it seemed likely tied to a scenario where the app was cold launched from a push notification (not already running). Perhaps your app has a similar possible use case? The The Fragment gets set up and added to the SupportFragmentManager in a Transaction here. I'm wondering if there is some sort of timing issue with the way RN is doing layout and how the native Views are getting created. At this line of code, the current This fragment transaction commit runs asynchronously, as described in the developer docs. One thing I'm wondering about is trying commitNow instead, to see if it would change any behavior around async timing that we're seeing with RN applications. So far, I've not been able to reproduce this issue exactly. I've tried some different sample app configs, and techniques to cold launch the app from a deep link to try to simulate what might be happening. If you have any leads on steps to repro that might help pinpoint, that would certainly help us to narrow in on a solution. |
|
After some further debugging, I believe we may have a potential fix for this issue in #133, available for any feedback. |
|
@ashfurrow - the version 3.1.8 update just released contains the change in #133 to try out - hopefully this will resolve it! |
|
Hello, and thank you for the quick response!
That is the case. From what I can tell, the user received a push notification, opened it, logged in, and then our app navigated to the screen with the notification content. That screen didn't have any Appcues components rendered on it, but the I'll update and get that deployed, thank you! |
|
@ashfurrow a heads up that an additional proposed update is in #134, to address an observed issue. While no longer crashing, there could be scenarios where the embed content would not load as expected on the first render of the screen - requiring navigating away and back to see the embed content. We believe this update should resolve that part, and ensure fully expected behavior for embeds in React Native Android applications. Once testing completes successfully, we'll release an updated version with that change as well. |
|
Understood, thanks for the transparency 👍 That shouldn't affect our current use case anyway, but it's good to know. |
|
Our 3.1.9 update has been released, containing the updated fix to handle the first render of embed content on the screen. We believe all issues here are resolved at this point, so going ahead and closing this issue. Please let us know if you have any additional feedback or notice any thing else not working as expected. |
|
I think this might be related; we just got a crash in 3.1.8 of the SDK: This was on a Galaxy S22 running Android 34. 600ms before the exception, the user had navigated to a new screen. Let me know if I should open a new issue or if I can provider further details. |
|
Hi @ashfurrow, thanks for letting us know! I am curious if you have seen this in 3.1.9 or later versions as well? (if you had released any of those). This fix in 3.1.9 hopefully fixed the underlying issue that could lead to this "not attached to a window" situation (fragment not getting attached). However, while analyzing this particular error, it seems like it might still be possible that this line could be executed (in the We will look into adding this extra check, but again hopefully this situation would not occur with the 3.1.9 update included as well. Thanks! |
|
Gotcha. We haven't upgraded past 3.1.8 yet but I'll get a new release with the latest version and let you know 👍 |
|
We have seen just the one Android exception since upgrading, to 3.1.11. |
|
@ashfurrow intersting, the |
|
Interesting! We've seen this (on |
|
Hey there 👋 Any update on this? We're seeing this crash about 10 times per day currently. |
|
Hi @ashfurrow , apologies, we are continuing to work on this one but we have yet to find a solution to pass along. From the stack, it looks like something in how we are managing the fragment for an embed frame is conflicting in behavior with how the react-native-screens backstack management is working, but this is a bit of a tricky one. We will keep investigating. If you have any further ideas or details please let us know! I'm re-opening this issue to keep it clearly active. |
|
@ashfurrow I'm curious if the issue we are seeing here is related at all to this one react-navigation/react-navigation#11384 . Our particular case here doesn't look like it is the exact same as the Bottom Tabs issue noted there, but it ends up with the same underlying exception due to the Android fragment state management. Do you have a way to consistently repro this one or a minimal reproducible sample? I'd be interested if the workaround mentioned in the other issue using |
|
Hi and sorry for the delayed response – something came up last week. I took a look at that issue and we haven't seen that issue yet. I haven't been able to find a way to reproduce this, unfortunately. Based on breadcrumbs, this problem seems to happen either when the user taps back to go to the root screen in a stack navigator, or directly after Our app navigation structure is a little unusual because we need to hide the bottom tabs when navigating to certain screens. Here's a simplified view: const App = createNativeStackNavigator()
const TabNavigator = () => {
<Tab.Navigator /* ... */>
{/* Five of these: */}
<Tab.Screen name={/* */} component={/* */} />
</Tab.Navigator>
}
// ...
<App.Group>
<App.Screen
name={IDENTIFIERS.stacks.home}
component={TabNavigator}
/>
{/* Several other native stack navigators (required due to design constraints) */}
</App.Group>Happy to provide any other details on this. In the meantime, we've disabled initializing the Appcues SDK for our Android users, which seems to have resolved the crash. |
Hello 👋 Following up on #128 (where I mentioned an Android crash I was seeing) and #129 (where the crashing code was wrapped in a try/catch), I'm still seeing the following crash:
For context, an issue prevented me from releasing the update with 3.1.7 in it until last week and I've only seen this crash happen once so far on that version. But both the Play Console and Bugsnag are reporting this as an unhandled exception/error. It could be that they are grouping this together with the previous crash, but judging by the stack trace, it's not a problem that would be handled by the try/catch from #129.
Any advice would be appreciated, thanks again!
The text was updated successfully, but these errors were encountered: