Fatal Exception: java.lang.ClassCastException: android.widget.ImageView cannot be cast to android.view.ViewGroup

[hdjvieira]

Hi! 👋

Firstly, thanks for all your work on this project! 🙂

Today I used patch-package to patch react-native-screens@4.24.0 for the project I'm working on.

We are getting these error reports on Crashlytics:

Fatal Exception: java.lang.ClassCastException: android.widget.ImageView cannot be cast to android.view.ViewGroup
       at androidx.fragment.app.FragmentStateManager.createView(FragmentStateManager.java:557)
       at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:286)
       at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:2214)
       at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:2115)
       at androidx.fragment.app.FragmentManager.execSingleAction(FragmentManager.java:2002)
       at androidx.fragment.app.BackStackRecord.commitNowAllowingStateLoss(BackStackRecord.java:323)
       at com.swmansion.rnscreens.ScreenStack.onUpdate(ScreenStack.kt:303)
       at com.swmansion.rnscreens.ScreenContainer.performUpdates(ScreenContainer.kt:376)
       at com.swmansion.rnscreens.ScreenContainer.onScreenChanged$lambda$8(ScreenContainer.kt:359)
       at com.swmansion.rnscreens.ScreenContainer.$r8$lambda$_XN8QBWatVwLAw6wNpLgWT68aTo(ScreenContainer.kt)
       at com.swmansion.rnscreens.ScreenContainer$$ExternalSyntheticLambda0.run(D8$$SyntheticClass)
       at android.os.Handler.handleCallback(Handler.java:942)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.kt:21)
       at android.os.Looper.loopOnce(Looper.java:226)
       at android.os.Looper.loop(Looper.java:313)
       at android.app.ActivityThread.main(ActivityThread.java:8762)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:604)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

So I asked Claude to take a look 😄 this is what he found out

Root cause
This is a view-ID collision between React Native's Fabric tags and native views, detonated by how react-native-screens attaches fragments.

ScreenStack/ScreenContainer attach screen fragments with transaction.add(id, fragment) (ScreenContainer.kt:221), where id is the container's React tag.
When the transaction executes, androidx FragmentStateManager.createView resolves that ID with a hierarchy-wide findViewById and blindly casts the result: container = (ViewGroup) fragmentContainer.onFindViewById(mContainerId).
Fabric assigns React tags as small even integers (2, 4, 6, … — confirmed in ReactFabric-prod.js, nextReactTag = 2; += 2) and sets them as the Android view ID. Meanwhile native views use equally small programmatic IDs — the Google Maps SDK's compass/my-location buttons are ImageViews with hardcoded literal IDs (1, 2, 5…), and View.generateViewId() (used by e.g. react-native-pager-view) also counts from 1. In a map app, a collision is a matter of time: when a duplicate ID sits earlier in traversal order, findViewById returns the map's ImageView instead of the ScreenStack, and the cast crashes. That also explains why it's intermittent — it depends on which tag number the navigator happens to get.
Fix
Since fragment 1.5, FragmentTransaction.add(ViewGroup container, Fragment, tag) sets fragment.mContainer by reference, and createView uses that field first — the findViewById path is never taken. We ship fragment 1.8.9, so I patched all three attach sites in react-native-screens 4.24.0 to use it (upstream main still has the bug, so upgrading wouldn't help):

patches/react-native-screens+4.24.0.patch — ScreenContainer.attachScreen plus the two transaction.add(id, …) calls in ScreenStack.onUpdate now pass this instead of id.
Verified with :react-native-screens:compileDebugKotlin — builds clean. Behavior is otherwise identical: the overload delegates to the same add(container.getId(), …) bookkeeping, it just pins the container object up front.

Here is the diff that solved my problem:

diff --git a/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenContainer.kt b/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenContainer.kt
index 7055a0d..88d637a 100644
--- a/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenContainer.kt
+++ b/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenContainer.kt
@@ -218,7 +218,11 @@ open class ScreenContainer(
         transaction: FragmentTransaction,
         fragment: Fragment,
     ) {
-        transaction.add(id, fragment)
+        // Pass the container by reference instead of by id: resolving the container via
+        // findViewById can hit an unrelated view when a native view's id (e.g. the Google Maps
+        // compass/my-location ImageViews use small literal ids) collides with our React tag,
+        // crashing with "ImageView cannot be cast to ViewGroup" in FragmentStateManager.
+        transaction.add(this, fragment, null)
     }
 
     fun attachBelowTop() {
diff --git a/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenStack.kt b/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenStack.kt
index bffd9c7..95f5937 100644
--- a/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenStack.kt
+++ b/node_modules/react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenStack.kt
@@ -271,7 +271,7 @@ class ScreenStack(
                     .dropWhile { it !== visibleBottom } // ignore all screens beneath the visible bottom
                     .forEach { wrapper ->
                         // TODO: It should be enough to dispatch this on commit action once.
-                        transaction.add(id, wrapper.fragment).runOnCommit {
+                        transaction.add(this@ScreenStack, wrapper.fragment, null).runOnCommit {
                             top?.screen?.bringToFront()
                         }
                     }
@@ -279,7 +279,7 @@ class ScreenStack(
                 if (newTop.screen.requiresEnterTransitionPostponing()) {
                     newTop.fragment.postponeEnterTransition()
                 }
-                transaction.add(id, newTop.fragment)
+                transaction.add(this@ScreenStack, newTop.fragment, null)
             }
 
             topScreenWrapper = newTop as? ScreenStackFragmentWrapper

react-native-screens+4.24.0.patch

This issue body was partially generated by patch-package.

[github-actions]

Hey! 👋

It looks like you've omitted a few important sections from the issue template.

Please complete Description, Steps to reproduce, Snack or a link to a repository, Screens version, React Native version and Platforms sections.

[github-actions]

Hey! 👋

The issue doesn't seem to contain a minimal reproduction.

Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem?

[kkafar]

Hey @hdjvieira,

thank you for the patch suggestion. It is "mergable", shouldn't introduce any regressions and indeed might help resolve the problem you describe.

This is a "hack" however. It will stop working as soon as you use any other lib that adds a fragment (e.g. Expo happens to add some overlays this way), therefore it is not the proper solution of the problem.

The error mechanism seems to be simple:

1. We mount the first tab fragment to the fragment manager,
2. when the container is passed as id, it is queried from FragmentManager.mFragmentContainer, which in case of top-level FragmentManager is the FragmentActivity.
3. FragmentActivity delegates the search to getWindow().getDecorView().findViewById(...) -> which simply does pre-order DFS.
4. In case of id collision it can indeed find a wrong view and attempt to cast it to ViewGroup.

The proper solution here would be to enforce different view id for your native ImageView, one that does not collide with React's view id domain. I believe that should be the solution.

At the same time, you should take care of avoiding id collisions with other react-native-screens custom views. We have a mechanism for that, see the ViewIdGenerator. You can integrate with that object on the native side.

As per setting custom view id on particular views you use - I don't know what you use, therefore can not help here. Likely it's customisable, because ImageView is a simple View, therefore you can always call setId (e.g. use the ViewIdGenerator there).

What do you think?

[hdjvieira]

Hi @kkafar

Thank you very much for the detailed analysis — it's totally fair!

I've asked Claude again to analyze the problem in our specific context but taking into account what you said, and that code scoundrel actually came up with a reply for me to send you:

Reply

The description of the mechanism matches exactly what we traced (pre-order DFS from the decor view via FragmentActivity's FragmentContainer, wrong view found on id collision, ClassCastException on the ViewGroup cast).

A few thoughts on the proposed direction:

The colliding ImageView is not ours to id. In our case it comes from the Google Play Services Maps SDK (via react-native-maps): the compass / my-location / zoom controls are ImageViews created internally by the SDK with hardcoded literal ids (1, 2, 5 — the same ids the community has long abused to reposition the my-location button). We never get a chance to assign them an id at creation. The best we could do is remap ids post-hoc by walking the MapView subtree, but:

• the controls are created lazily (e.g. the my-location button only appears once enabled), so a one-shot remap misses late-created views and we'd need recursive hierarchy-change listeners;
• the SDK ships through the dynamite module, so whether it internally relies on findViewById for those controls can change with any Play Services update, silently breaking the remap.

So "enforce a different view id for the native ImageView" is only the proper solution when you own the view. For SDK-internal views it's strictly more fragile than what the patch does.

Id hygiene can't be enforced across the ecosystem, even with ViewIdGenerator. The generator's odd-numbers-from-3 scheme avoids Fabric's even tags, but it still collides with View.generateViewId(), which emits 1, 2, 3, … (both parities) and is used by other RN libraries today (react-native-pager-view, for one). It also collides with the Maps SDK ids above: the generator's second output is 5, which is the Google Maps compass ImageView's literal id — so a gamma StackContainer/TabsHost sharing a screen with a GoogleMap can hit this same crash class through ViewIdGenerator itself. And as the comment in ViewIdHelpers.kt itself notes, the scheme has to chase internal renderer behavior across RN versions. Every native library in the process is effectively playing musical chairs in the low integer range that Fabric occupies.

Why I'd still argue for reference-passing in rn-screens. FragmentTransaction.add(ViewGroup, Fragment, String) exists (fragment 1.5+) precisely because id-based container resolution is ambiguous; it pins Fragment.mContainer up front and FragmentStateManager.createView never runs the decor-wide findViewById. It's the only collision-proof behavior a fragment-owning library can adopt unilaterally — it keeps rn-screens' own transactions correct no matter what id any other SDK in the process uses, today or after an update. You're right that it doesn't protect other libraries' fragment adds (Expo overlays etc.) — but nothing rn-screens does can; those libraries can adopt the same one-line fix on their side.

So I'd frame the two approaches as complementary rather than competing: id hygiene where you own the views (and ViewIdGenerator integration makes sense there), reference-passing for the transactions you own.

What he said makes sense within our project context, and I hope it helps guide future improvements on rn-screens (if any are necessary at all regarding this issue).