Collect: Buttons in android permission dialog don't cause any action if an activity has been recreated after showing the dialog.

[grzesiek2010]

Software and hardware versions

Collect v1.17.0

Problem description

Buttons in android permission dialog don't cause any action if an activity has been recreated after showing the dialog.

Steps to reproduce the problem

It's one of many possible ways to reproduce the issue:

1. Go to device settings -> Apps -> ODK Collect -> Permission and make sure that Microphone is turned off
2. Open any form which contains the AudioWidget (eg AllWidgets form)
3. Click on the Record Sound button
4. Rotate your device
5. Click any button (Deny or Allow)

Expected behavior

If you click Deny another dialog with an explanation should be displayed otherwise (allow) an external app (audio recorder) should be started.

Other information

It's caused because we pass activity https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/utilities/PermissionUtils.java#L160 and after activity recreation, there is no reference to a current activity . We could fix this issue using for example rxEvents but it would make the code complex and then I don know if using the library we use makes sense.

This problem doesn't exist using the approach from the doc https://developer.android.com/training/permissions/requesting

[grzesiek2010]

any other approaches @jd-alexander ?

[lognaturel]

Interesting. I think we’re probably not using the lib quite as it is intended. Have you maybe looked at some of the samples linked from https://github.com/Karumi/Dexter/issues/15?

[jd-alexander]

Interesting. I think we’re probably not using the lib quite as it is intended. Have you maybe looked at some of the samples linked from Karumi/Dexter#15?

The methods that were introduced there were depreciated and then removed. Will be investigating what was implemented in favour of them.

[grzesiek2010]

I think we’re probably not using the lib quite as it is intended

It was also my first idea but then I downloaded the sample app https://github.com/Karumi/Dexter/tree/master/sample and the behavior there is the same.

[lognaturel]

@grzesiek2010 how about filing a new issue on the Dexter repo asking what the latest strategy may be and referring to issues at https://github.com/Karumi/Dexter/search?q=rotation&type=Issues

I’m not optimistic we’ll get a response since there hasn’t been activity in a while but good to at least have it out there.

I’d say this is pretty low priority because it is recoverable and I doubt screen rotation is very common (maybe we should get analytics).

[grzesiek2010]

Here you are https://github.com/Karumi/Dexter/issues/216

[grzesiek2010]

https://github.com/Karumi/Dexter/issues/216#issuecomment-426629403

The short answer is that it was possible at some point but it was buggy so they decided to get rid of that functionality and they won't implement it again.

So now the question is. Is it acceptable for us or maybe we should use the traditional approach https://developer.android.com/training/permissions/requesting?

[lognaturel]

Great that you got a response!

I'm ok leaving it as-is. The permissions requests don't happen often anyway and even when they do, the odds of a user deciding to rotate at just that moment are low. So I think we can close this.

It sounds like #2571 is also explained by https://github.com/Karumi/Dexter/issues/216#issuecomment-426629403 and that we can close that one as well, right?

[grzesiek2010]

Since as you said:

1. The permissions requests don't happen often
2. even when they do, the odds of a user deciding to rotate at just that moment are low
3. even if it happens it doesn't cause any crash.

so I agree we can close this issue. When it comes to #2571 I think we can fix it and it's not the same, let me take another look to be sure.