commcare-android
commcare-android copied to clipboard
Add tests to show document media provider crashes
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
- [x] If the PR is high risk, "High Risk" label is set
- [x] I have confidence that this PR will not introduce a regression for the reasons below
- [x] Do we need to enhance manual QA test coverage ? If yes, "QA Note" label is set correctly
Automated test coverage
Safety story
1 Warning | |
---|---|
:warning: | This PR does not contain any JIRA issue keys in the PR title or commit messages (e.g. KEY-123) |
Generated by :no_entry_sign: Danger
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^.
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.
One other thought, if it's a content://
URI, can we check if this code successfully handles it ?
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
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.
@damagatchi retest this please
Can one of the admins verify this patch?