Fix external apps returning data when Collect is being restored

[seadowg]

Closes #5646
Potentially fixes this crash

As well as fixing the issue above, this fixes the problem discovered by @grzesiek2010:

1. Set "Background process limit" to "No background processes"
2. Open a form with an image widget
3. Click "Take picture"
4. Switch to another app and get back to the camera app
5. Take a picture in the camera app

What has been done to verify that this works as intended?

New (local) tests written to both replace and extend (the now deleted) ProcessRestoreTest. These tests use raw Robolectric rather than AndroidX as testing lifecycles like this requires features that AndroidX does not support. As part of writing these tests, I've pulled a few things out of androidTest to shared modules (such as testshared and androidtest for example) so as not to duplicate test support code in test. I also moved our test forms to a new module that allows local tests to access them (also to prevent duplication).

Why is this the best possible solution? Were any other approaches considered?

I've just made the minimum changes required to get the new tests passing. I think there's a lot we could do to make this nicer using the new save instance state/activity result APIs, removing reliance on static state etc, but most of the effort here was getting reliable testing in place which I think has given us a big enough PR.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

As well as the issues this fixes, I think testing form loading/entry in general and having a play with "Don't keep activities" and "Background process limit" would be good.

Before submitting this PR, please make sure you have:

• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

@getodk/testers I'm marking this as "needs testing" early as I'm currently not able to write tests for the fix for the issue or for the new one @grzesiek2010 found:

1. Set "Background process limit" to "No background processes"
2. Open a form with an image widget
3. Click "Take picture"
4. Switch to another app and get back to the camera app
5. Take a picture in the camera app

Please verify that both problems are fixed and also have a go at finding any other related problems around process restores and "external" data. I can look at working out automated testing once we know my fixes actually work!

[dbemke]

What would be the expected result now for the issue #5646?

[seadowg]

What would be the expected result now for the issue #5646?

I think ideally it should return to the hierarchy in the same place (same group) as it was in before. Do you think that makes sense? Is that currently how it's behaving?

[dbemke]

Yes, it returns to the hierarchy view - for me looks great as it's consistent with other cases of returning to a form

[seadowg]

@dbemke does it look like the issue that @grzesiek2010 reported is fixed as well? It is as far as I can tell!

[seadowg]

I wrote a post going deeper into how all testing works here which might be useful for @grzesiek2010: https://www.seadowg.com/2023/08/14/simulating-activity-recreation-with-robolectric.html.

[dbemke]

does it look like the issue that @grzesiek2010 reported is fixed as well?

Yes. The issue is fixed

[dbemke]

I don't know if the PR should influence also this case. In video widget minimizing the app while recording a video with no background processes settings, after going back the recording is stopped/disappears (no crash and possible to start a new recording, but the recording which was on is not saved).

[seadowg]

I don't know if the PR should influence also this case. In video widget minimizing the app while recording a video with no background processes settings, after going back the recording is stopped/disappears (no crash and possible to start a new recording, but the recording which was on is not saved).

I wouldn't expect it to fix this. Does that issue also occur on master/Play Store version?

[dbemke]

On master version after minimizing it's possible to start a new recording but after tapping "V" to confirm to upload the video, the user is moved to the first page of the form and none of the recordings is saved. In the PR the second recording (the one started after minimizing) is saved.

[seadowg]

On master version after minimizing it's possible to start a new recording but after tapping "V" to confirm to upload the video, the user is moved to the first page of the form and none of the recordings is saved. In the PR the second recording (the one started after minimizing) is saved.

So it's changed, but it's (arguably) better now? Sounds like there is still a bug around not being able to record a a video in the background though that we should file separately?

[dbemke]

So it's changed, but it's (arguably) better now? Sounds like there is still a bug around not being able to record a a video in the background though that we should file separately?

I think it's better. I'll file the issue after merging this PR.

[dbemke]

We finished testing for now so we'll remove the label "needs testing". As discussed in Slack, please let us know when/if we should continue testing in case of some changes.
Issues mentioned in the PR are fixed. The issue connected with video widget will be filed separately.