Add tests to show document media provider crashes

[ShivamPokhriyal]

Summary

Adds a test to confirm this crash: https://console.firebase.google.com/u/0/project/commcare-a57e4/crashlytics/app/android:org.commcare.dalvik/issues/5ce2e2aaf8b88c2963706428?time=last-thirty-days&versions=2.52.1%20(464182)&sessionEventKey=6133BA63028B00010FB080C17D73CF8E_1582592414843474720

Caused by java.lang.NullPointerException: uri
       at java.util.Objects.requireNonNull(Objects.java:245)
       at android.content.ContentResolver.query(ContentResolver.java:1171)
       at android.content.ContentResolver.query(ContentResolver.java:1128)
       at android.content.ContentResolver.query(ContentResolver.java:1084)
       at org.commcare.utils.UriToFilePath.getDataColumn(UriToFilePath.java:120)
       at org.commcare.utils.UriToFilePath.getPathFromUri(UriToFilePath.java:83)
       at org.commcare.utils.FileUtil.getFileLocationFromIntent(FileUtil.java:775)
       at org.commcare.utils.FileUtil.updateFileLocationFromIntent(FileUtil.java:754)
       at org.commcare.activities.InstallArchiveActivity.onActivityResult(InstallArchiveActivity.java:105)
       at android.app.Activity.dispatchActivityResult(Activity.java:8460)
       at android.app.ActivityThread.deliverResults(ActivityThread.java:5091)
       at android.app.ActivityThread.handleSendResult(ActivityThread.java:5139)
       at android.app.servertransaction.ActivityResultItem.execute(ActivityResultItem.java:51)
       at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
       at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2104)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loop(Looper.java:236)
       at android.app.ActivityThread.main(ActivityThread.java:7861)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:600)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)

I initially wanted to add it as a unit test, but I couldn't get it work with the content resolver queries.

Details about the crash:
ACTION_GET_CONTENT has an option for documents provider just like it has options for image, audio or video providers. When you select a pdf document from a document provider, it gives a uri like this:
content://com.android.providers.media.documents/document/document:59845.
https://github.com/dimagi/commcare-android/blob/master/app/src/org/commcare/utils/UriToFilePath.java#L64-L83 Our code here correctly identifies it as a media provider uri, and then it checks the type. In our case the type is document, but the checks only exists for image, audio and video types.
So the call to getDataColumn happens with a null contentUri and it fails.

The only thing that I'm concerned here is that https://android.googlesource.com/platform/packages/providers/MediaProvider/+/5d36def/src/com/android/providers/media/MediaDocumentsProvider.java#123 the official MediaDocumentProvider class also only checks the types to be one of image, audio or video. So I'm not sure if this should be handled here or not.

Addtionally, the crash happens when users are installing the offline ccz but rather than providing a path to valid ccz file, they're selecting any random path.
So perhaps we should first check the file extension before doing any processing maybe?
But also, we should be able to support getting paths for document file types using UriToFilePath.

This is just a test PR. Will create a follow up PR for the fix.

Feature Flag

Product Description

Safety Assurance

• If the PR is high risk, "High Risk" label is set
• I have confidence that this PR will not introduce a regression for the reasons below
• Do we need to enhance manual QA test coverage ? If yes, "QA Note" label is set correctly

Automated test coverage

Safety story

[dimagimon]

	1 Warning
⚠️	This PR does not contain any JIRA issue keys in the PR title or commit messages (e.g. KEY-123)

Generated by 🚫 Danger

[ShivamPokhriyal]

The only thing that I'm concerned here is that https://android.googlesource.com/platform/packages/providers/MediaProvider/+/5d36def/src/com/android/providers/media/MediaDocumentsProvider.java#123 the official MediaDocumentProvider class also only checks the types to be one of image, audio or video. So I'm not sure if this should be handled here or not.

I was wrong here. The code I linked was for 8 years old commit.

I looked at the latest code for MediaDocumentProvider and it indeed has a check for document type https://android.googlesource.com/platform/packages/providers/MediaProvider/+/refs/heads/master/src/com/android/providers/media/MediaDocumentsProvider.java#423.
I tried using content://media/external/file content URI(Files.EXTERNAL_CONTENT_URI was not resolved for me), but it returned null or more precisely, the cursor was empty. So can't really get file path using this approach^.

[shubham1g5]

Addtionally, the crash happens when users are installing the offline ccz but rather than providing a path to valid ccz file, they're selecting any random path.
So perhaps we should first check the file extension before doing any processing maybe?

yeah if that's possible it would be great.

Though we should not merge this test without the fix as it's an anti-pattern in the code to have tests for failing behaviours. It formalizes an expectation that we are supposed to crash in such a case which is not true.

[ShivamPokhriyal]

Though we should not merge this test without the fix as it's an anti-pattern in the code to have tests for failing behaviours. It formalizes an expectation that we are supposed to crash in such a case which is not true.

Agreed, I was looking into https://android.googlesource.com/platform/packages/providers/MediaProvider/+/refs/heads/master/src/com/android/providers/media/MediaDocumentsProvider.java#423 to figure out how to get the path from a DocumentsProvider but haven't been successful so far.

So I'm thinking about this approach:

• Don't crash when the contentUri is null but simply return the uri(not sure if this would be helpful).
• Check the file extension first, before getting the path. This again isn't foolproof, because the code that we use to get filename using cursor might not always return the extension.

2nd point is why I'm still searching on possible ways to get file path from the documents provider uri.

[shubham1g5]

One other thought, if it's a content:// URI, can we check if this code successfully handles it ?

[ShivamPokhriyal]

One other thought, if it's a content:// URI, can we check if this code successfully handles it ?

already tried that, it returns the uri itself

[shubham1g5]

I see, I think returning URI is a valid response from here if we can't find a better solution to it. We do seem to handle for URI later in the code path.

[shubham1g5]

@damagatchi retest this please

[damagatchi]

Can one of the admins verify this patch?