ViewBinding NPE in Fragment onSaveInstanceState [245355409]

Assigned

Process

Status Update

No update yet.

Description

io...@gmail.com

created issue #1

Sep 7, 2022 09:25AM

Component used: Fragment

Version used: 1.2.5

Devices/Android versions reproduced on:

Android 12 (SDK 31) 27 42.9%
Android 11 (SDK 30) 14 22.2%
Android 10 (SDK 29) 10 15.9%
Android 9 (SDK 28) 7 11.1%
Android 8.0 (SDK 26) 3 4.8%
Android 8.1 (SDK 27) 2 3.2%

This issue is not reproducible 100% and was reported as Crash Reports on Google Play - on local devices and normal scenarios this does not happen (e.g. put Application in Foreground and Background).

Current exception:

Exception java.lang.NullPointerException:
  at my.package.MyCustomFragment.getBinding (MyCustomFragment.java)
  at my.package.MyCustomFragment.onSaveInstanceState (MyCustomFragment.java)
  at androidx.fragment.app.Fragment.performSaveInstanceState (Fragment.java)
  at androidx.fragment.app.FragmentStateManager.saveBasicState (FragmentStateManager.java)
  at androidx.fragment.app.FragmentStateManager.saveState (FragmentStateManager.java)
  at androidx.fragment.app.FragmentStore.saveActiveFragments (FragmentStore.java)
  at androidx.fragment.app.FragmentManager.saveAllState (FragmentManager.java)
  at androidx.fragment.app.FragmentController.saveAllState (FragmentController.java)
  at androidx.fragment.app.FragmentActivity.onSaveInstanceState (FragmentActivity.java)
  at androidx.appcompat.app.AppCompatActivity.onSaveInstanceState (AppCompatActivity.java)
  at my.package.MyMainMactivity.onSaveInstanceState (MyMainMactivity.java)
  at android.app.Activity.performSaveInstanceState (Activity.java:2203)
  at android.app.Instrumentation.callActivityOnSaveInstanceState (Instrumentation.java:1488)
  at android.app.ActivityThread.callActivityOnSaveInstanceState (ActivityThread.java:6072)
  at android.app.ActivityThread.callActivityOnStop (ActivityThread.java:5416)
  at android.app.ActivityThread.performStopActivityInner (ActivityThread.java:5345)
  at android.app.ActivityThread.handleStopActivity (ActivityThread.java:5455)
  at android.app.servertransaction.StopActivityItem.execute (StopActivityItem.java:40)
  at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2325)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loop (Looper.java:246)
  at android.app.ActivityThread.main (ActivityThread.java:8633)
  at java.lang.reflect.Method.invoke (Method.java)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:602)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1130)

The implementation and usage of view binding is very simple and follows Android guidelines:

    private var _binding: FragmentCustomBinding? = null
    private val binding get() = _binding!!

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View = FragmentCustomBinding.inflate(inflater, container, false).also {
        _binding = it
    }.root

    override fun onDestroyView() {
        _binding = null
        super.onDestroyView()
    }

    override fun onSaveInstanceState(outState: Bundle) {
        outState.apply {
            putString(BUNDLE_KEY_SOME_VALUE, binding.etSomeValue.text.toString())
        }
        super.onSaveInstanceState(outState)
    }

I'm getting a NullPointerException in onSaveInstanceState() as the binding is null as this was called after onDestroyView() (or before onCreateView()).

Comments

jb...@google.com <jb...@google.com> #2Sep 7, 2022 02:49PM

I'm marking this as "won't fix" as there's nothing Compose here can do, as this is a platform quirk that has been adjusted to be more predictable in recent API versions.

The crux of the issue here is the fitSystemWindows in the extra View, like you mentioned, and a platform change in API 30.

Prior to API 30, window insets were dispatched through the view hierarchy in a non-intuitive way: Rather than being a full breadth-first traversal, they would be dispatched in preorder. If the insets were consumed at any point (like if you use fitSystemWindows), then the preorder would prevent insets from being dispatched to the rest of the view hierarchy. This is very unintuitive: It meant that sibling views (or views deeper in the tree) could stop later views from receiving the dispatch of insets.

In API 30, this behavior was changed to be more intuitive: Now, insets are dispatched in a top-down manner, so they can't be consumed in this weird, cross-tree way.

There's a couple solutions here:

Avoid fitSystemWindows from views if you're handling insets manually
Override dispatchApplyWindowInsets in the view groups above where you have fitSystemWindows defined, and manually perform the new, non-broken dispatching behavior. You can see a comparison of the two methods here: https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/view/ViewGroup.java;l=7341-7371;drc=6411c81462e3594c38a1be5d7c27d67294139ab8

io...@gmail.com <io...@gmail.com> #3Sep 8, 2022 09:42AM

Using composable version 1.2.1, I could fix it using:

override fun onCreate(bundle: Bundle?) {
        WindowCompat.setDecorFitsSystemWindows(window, false)
        super.onCreate(bundle)
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.Q){
            window.setFlags(WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS, WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS)
        }
}

Then statusBarsPadding works as expected on Api 29

jb...@google.com <jb...@google.com> #4Sep 8, 2022 03:00PM

Status: New (reopened)

Is there a possibility that this bug is somehow impacting View based onApplyWindowInsetsListener s? I am seeing an issue when navigating from a compose based (non-edge-to-edge) fragment to a view based edge-to-edge fragment where the onApplyWindowInsetsListeners are not being called. This is fixed by simply calling requestApplyInsets() in an onLayoutChangedListener, but I am trying to get down to the root of the problem. Unfortunately I am unable to post any code, but have been digging for a while in to the windowInsets source code and can't find anything. This only happens when the proceeding fragment is Compose based.

jb...@google.com <jb...@google.com> #5Sep 8, 2022 03:08PM

Going to use this bug to track updating the view state documentation to be more clear.

io...@gmail.com <io...@gmail.com> #6Sep 9, 2022 05:30AM

Thank you for the detailed explaination, now it makes sense why onSavedInstanceState() is called and I don't have my binding ready.

Do you mind telling me what is the view's API that you are referring to, for saving the state? Is it the saving-state#view? I was thinking about using saving-states#savedstateregistry, but this can over-complicate the components I'm currently using as I will have to make them aware of this state.

Another option that I was thinking about was to ignore the entire saving in case the binding is invalid(to avoid the case you explained where the fragment is called when in the backstack), but can you please tell me if there is a guarantee I will still be getting onSavedInstanceState() called when the fragment goes in background or has a config change?

jb...@google.com <jb...@google.com> Mar 29, 2023 11:37PM

Assigned to ja...@google.com.

Issue 245355409