Crash when restoring to Select One From Map map view

[seadowg]

Covers this crash report.

ODK Collect version

v2022.2.3+

Android version

Reproduced on Android 10, but likely a problem in all versions

Device used

Pixel 2 emulator

Problem description

The app crashes when "restoring" (being reopened after being kicked out of memory rather than closed by the user) if the user was last on the Select One From Map map view.

Steps to reproduce the problem

1. Set "Background process limit" to "No background processes" in Developer Options
2. Open a form with a Select One From Map question
3. Go to question and click "Select Place"
4. Switch to another app and then back again

The app crashes.

Expected behavior

The app should be able to restore from background. Looking at the Select One Minimal question, I'd expect the form to reopen in the hierarchy and then be able to press back and return to the question - not the map view. I'm not sure if that behaviour is ideal (we should probably return to the same place the user left), and I'm also not sure I understand why we don't open with the hierarchy over the select minimal dialog (something closes the dialog).

We should also look for other cases where this could happen when designing a fix.

Other information

Restoring from background is a flow we've mostly forgotten about. @getodk/testers this (enabling "No background processes" and then switching apps) is a good way to find bugs/crashes that we probably miss while developing features.

The stack trace for the crash is:

Caused by java.lang.NullPointerException: Attempt to invoke virtual method 'org.javarosa.form.api.FormEntryPrompt org.odk.collect.android.javarosawrapper.FormController.getQuestionPrompt(org.javarosa.core.model.FormIndex)' on a null object reference
       at org.odk.collect.android.formentry.FormEntryViewModel.getQuestionPrompt(FormEntryViewModel.java:237)
       at org.odk.collect.android.widgets.items.SelectOneFromMapDialogFragment.onAttach(SelectOneFromMapDialogFragment.kt:58)
       at androidx.fragment.app.Fragment.performAttach(Fragment.java:2954)
       at androidx.fragment.app.FragmentStateManager.attach(FragmentStateManager.java:463)
       at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:254)
       at androidx.fragment.app.FragmentStore.moveToExpectedState(FragmentStore.java:113)
       at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1374)
       at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:2841)
       at androidx.fragment.app.FragmentManager.dispatchCreate(FragmentManager.java:2773)
       at androidx.fragment.app.FragmentController.dispatchCreate(FragmentController.java:251)
       at androidx.fragment.app.FragmentActivity.onCreate(FragmentActivity.java:252)
       at org.odk.collect.android.activities.CollectAbstractActivity.onCreate(CollectAbstractActivity.java:42)
       at org.odk.collect.android.activities.FormEntryActivity.onCreate(FormEntryActivity.java:383)

[seadowg]

@lognaturel @grzesiek2010 I think we should definitely look at this for the next release and consider it as a hotfix if it fits into one.

[seadowg]

I've moved this into "Hotfix" as it feels like it has potential to disrupt people during form entry (if they're multi tasking).