Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I am seeing the following error on Crashlytics with a lot of incidences:

Caused by java.lang.ClassCastException: android.view.AbsSavedState$1 cannot be cast to android.widget.CompoundButton$SavedState
       at android.widget.CompoundButton.onRestoreInstanceState(CompoundButton.java)
       at android.view.View.dispatchRestoreInstanceState(View.java)
       at android.view.ViewGroup.dispatchRestoreInstanceState(ViewGroup.java)
       at android.view.ViewGroup.dispatchRestoreInstanceState(ViewGroup.java)
       at android.view.ViewGroup.dispatchRestoreInstanceState(ViewGroup.java)
       at android.view.ViewGroup.dispatchRestoreInstanceState(ViewGroup.java)
       at android.view.ViewGroup.dispatchRestoreInstanceState(ViewGroup.java)
       at android.view.ViewGroup.dispatchRestoreInstanceState(ViewGroup.java)
       at android.view.View.restoreHierarchyState(View.java)
       at android.support.v4.app.Fragment.restoreViewState(Fragment.java:494)
       at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1486)
       at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1784)
       at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1852)
       at android.support.v4.app.FragmentManagerImpl.dispatchStateChange(FragmentManager.java:3269)
       at android.support.v4.app.FragmentManagerImpl.dispatchActivityCreated(FragmentManager.java:3229)
       at android.support.v4.app.Fragment.performActivityCreated(Fragment.java:2466)
       at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1483)
       at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1784)
       at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1852)
       at android.support.v4.app.FragmentManagerImpl.dispatchStateChange(FragmentManager.java:3269)
       at android.support.v4.app.FragmentManagerImpl.dispatchActivityCreated(FragmentManager.java:3229)
       at android.support.v4.app.FragmentController.dispatchActivityCreated(FragmentController.java:201)
       at android.support.v4.app.FragmentActivity.onStart(FragmentActivity.java:620)
       at android.support.v7.app.AppCompatActivity.onStart(AppCompatActivity.java:178)
       at android.app.Instrumentation.callActivityOnStart(Instrumentation.java)
       at android.app.Activity.performStart(Activity.java)
       at android.app.ActivityThread.performLaunchActivity(ActivityThread.java)
       at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java)
       at android.app.ActivityThread.access$900(ActivityThread.java)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java)
       at android.os.Handler.dispatchMessage(Handler.java)
       at android.os.Looper.loop(Looper.java)
       at android.app.ActivityThread.main(ActivityThread.java)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java)
However this stack trace says nothing about my codebase, since the exception is thrown at the platform level.
From what I read this might have to do with duplicate ids, but I cant find any in my code, any ideas on how to debug this? 
I also tried to enable "Dont keep activities" on Developer options to force an instance restoration but I am unable to reproduce the crash manually.
                There is an activity which in onStart restores a fragment. Do You have any fragment containing RadioButton, Checkbox,Switch,ToggleButton? If so, try to put breakpoints there and check in Watches window if You are not casting them wrong.
– deadfish
                Oct 3, 2018 at 14:15
                Does your project have any custom View subclasses that derive from CompoundButton (or one of its subclasses)?
– Ben P.
                Oct 5, 2018 at 17:18
                If possible try to get the same device on which your issue was reproduced and try switching application in various moments when your app is in front (especially on views which use fragments with CompoundButton) and then switch back to your app. It looks like the issue is happening when restoring views from saved state, however reproduction may be device specific.
– LLL
                Oct 10, 2018 at 8:00
                It's possible this is happening due to structural changes in the layout between landscape and portrait modes.
– jpmcosta
                Oct 10, 2018 at 9:26
This is little difficult to get exact issue without seeing code and exact activity/fragment class but There might be below reason which can help you to debug more..
You might have duplicate name of your id or View which matching and creating memory leak when you are transforming.
There might be wrong import of CompoundButton, might be you are using custom view or version impact.
Well turns out I am using the new Chip component (extending CompoundButton), and had one group with a chip without an id. 
And this somehow causes the app to crash on older phones (Android 6) because of the same id being assigned to multiple chips I can only guess.
I removed that Chip (which was not necessary anyway) and it does not crash anymore.
this can be caused by a view with the same resId, as the containing layout's name (main cause).
it could also be caused from view with duplicate resIds, but that's less likely the cause.
reviewing all the fragment's XML suggested (difficult to tell which one causes that).
but Edit > Find > Find in Path ...makes it easy to search for occurrences;
to search for one layout's name after the other; then to search for view's resId.
                Also it can happen if a custom view inherits from Layout class. When you use such a view, it's ID namespace merges into the namespace of the layout where you put it, creating conflicts that are not visible at compile time.
– Dmitry K
                May 17, 2022 at 9:41
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.