Read file from Camera roll (content:// path on android)

[nordved]

I am trying to get the base64 code for an image in the camera roll. The path for the image is something like

content://com.app.provider/app_images/Android/data/com.app/files/Pictures/image-a00a13f4-a24f-40ce-bb16-e56979b75692.jpg

And I am trying to read this file with

RNFetchBlob.fs.readFile(localPath, 'utf8')

and

RNFetchBlob.fs.readFile(localPath, 'base64')

The app simply crashes and in the logcat I can find the error

Column '_data' does not exist

I have also tried

RNFetchBlob.fs.readFile(RNFetchBlob.wrap(localPath), 'base64')

Which gives the error:

Error: Attempt to invoke virtual method 'boolean java.lang.String.startsWith(java.lang.String)' on a null object reference

In the FileSystem API you write that it is possible to read the files from content://, so I'd like to know if there is another way that I'm not seeing.

EDIT: I'm using RN 0.41 and RNFB 0.10.2

[tlvince]

I'm seeing the same thing for readFile calls to paths within DocumentDir.

Error: Attempt to invoke virtual method 'boolean java.lang.String.startsWith(java.lang.String)' on a null object reference
    at createErrorFromErrorData (NativeModules.js:116)
    at NativeModules.js:79
    at MessageQueue.__invokeCallback (MessageQueue.js:288)
    at MessageQueue.js:127
    at guard (MessageQueue.js:46)
    at MessageQueue.invokeCallbackAndReturnFlushedQueue (MessageQueue.js:126)
    at debuggerWorker.js:71

Android, RN 0.42.

[chris-pikul]

I just found this today. So that's a +1 from me.
Specifically, it's when sharing from Google Drive which give's a URI looking like...
content://com.google.android.apps.docs.storage.legacy/enc%3D2cnEPvlNW2uZUjq8h_w7hhNWmkRhsPqHum9gJTxeOrsaGiV3%0A

Same error pops up, and get's caught in the promise.
Error processing message Error: Attempt to invoke virtual method 'boolean java.lang.String.startsWith(java.lang.String)' on a null object reference

Should mention I'm using the readFile(uri, 'base64') version.
Also:
RN: 0.35.0
RNFetchBlob: 0.10.0

[wkh237]

Thanks for providing the information, will look into this issue ASAP 👍

[wkh237]

After some investigation, the problem is that our Android URI resolver couldn't get the absolute file path from the given URI. I will try to figure out if there's a better implementation.

[tlvince]

I'm experiencing this in Android 7.1 if that makes any difference. Lmk if you'd like me to test anything.

[wkh237]

@ChrisPikul510 @tlvince , is there any way to make a content provider URI like content://com.app.provider/app_images/Android/data/com.app/files/Pictures/image-a00a13f4-a24f-40ce-bb16-e56979b75692.jpg and content://com.google.android.apps.docs.storage.legacy/enc%3D2cnEPvlNW2uZUjq8h_w7hhNWmkRhsPqHum9gJTxeOrsaGiV3%0A ?

In my case, the URIs from camera roll look like this content://media/external/images/media/694, and there's no problem to resolve this kind of URI.

[tlvince]

Apologies. In my case I'd missed adding a content type prefix altogether; adding file:// to e.g. file://${RNFetchBlob.fs.dirs.DocumentDir}/${filename} works for me.

[nordved]

@wkh237 I was using https://github.com/marcshilling/react-native-image-picker to take a picture. It saves to the gallery of the phone or selects from the gallery. I can understand if you feel like 3rd party support is not on the top of your list though.

I solved it by storing the base64 directly from the callback instead of getting it from the filesystem.

[wkh237]

@nordved , thanks for the information. It'd be great to make this kind of URI supported since it's very common use case IMO 👍

[chris-pikul]

@wkh237 The uri I was attempting came directly from Google Drive app through a share intent. In which case from my end I'm not entirely sure exists as that looks like a hash/temp URI. Are you suggesting I modify the URI?

BTW, is there a way you can implement a function for grabbing N bytes from a file? I ask because I'm only reading this file to grab the first 16 bytes to cross-reference with my list. Which also if you want to integrate here would be cool too. It's just header signature negotiation...
https://github.com/ChrisPikul510/content-type-negotiation