In a form with metadata tapping on the device back button when the app settings are opened results in the form being in loading state

[dbemke]

Software and hardware versions

Collect v2022.3.3, Android probably all

Problem description

In a form with metadata, after denying ODK Collect to make and manage phone calls, then in next dialog choosing „open settings” and tapping on device back button, the form is in a loading form state. The user is unable to complete the form.

Steps to reproduce the problem

1. Go to Metadata form. metadata.xml.txt
2. Deny ODK Collect to make and manage phone calls.
3. In the next dialog „Read phone state permission” click „open settings”.
4. Click the device back button.

Expected behavior

Another dialog should appear.

Other information

If in device settings don’t keep activities is on, the issue doesn’t occur. If the user rotates the screen (after actions from steps to reproduce), the dialog appears. In Collect v2022.2.0 if the user denies access to phone, the form closes.

[grzesiek2010]

To reduce complexity maybe we should close form filling not only if a user clicks OK in that dialog (that displays additional info about required permissions) but also after clicking Open Settings. Then even if a user goes to settings and grants required permissions they would need to open the form again (not a big problem to me). Thanks to that we would be able to avoid such tricky scenarios when someone goes to settings and navigates back without changing anything. The described case is not the only one. Now for example I see that if you use a form with background audio recording you can bypass that permission and fill it after denying it:

1. Download Collect v1.30 Background audio recording form the demo server
2. Start the form and deny the audio permission
3. Click Open Setting
4. Go back to the form

@lognaturel @seadowg what do you think?

[seadowg]

To reduce complexity maybe we should close form filling not only if a user clicks OK in that dialog (that displays additional info about required permissions) but also after clicking Open Settings.

This might actually be a better approach for all our permission flows, not just form entry. The way we use PermissionListener currently assumes that the user grants the permission in settings: as you point out we never call PermissionListener#denied if the user hits "Open settings".

I vote we try calling denied when in the "Open settings" flow as well. That would change all our flows so that they perform the "back out" or "clean up" assuming that the user is not going to give permission (and the user can just do the thing they were trying to do again if they do grant it).

[grzesiek2010]

It turns out in different parts of the app we need different behaviors. Sometimes we want a callback immediately when a permission is denied and sometimes only after closing that additional explanation dialog. Please take a look at https://github.com/getodk/collect/pull/5270 where I introduced a new third callback additionalExplanationClosed so that we can do different things after granting a permission, denying it or closing the dialog. I think we should merge it first and then get back to this issue. Then we could use that additionalExplanationClosed method and close form filling.