nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Android ACTION_GET_CONTENT from Dropbox sources

Andhie W.

Device OS: Lollipop 5.0

When using the Intent ACTION_GET_CONTENT and selecting Dropbox from the Storage Provider, Dropbox prompts a file picker dialog to choose from. The result obtained in onActivityResult is something like

file:///storage/emulated/0/Android/data/com.dropbox.android/files/u6763728/scratch/Camera%20Uploads/2012-04-02%2012.34.44.jpg

The requesting app will not have read permission as its dropbox own private directory even with WRITE_EXTERNAL_STORAGE permission. In KitKat, it is recommended to use FileProvider to share a file via a content:// uri

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Thanks for the report! I'm sending this along to the right people.

Michael G.89

Any update on this? I've run into the same issue.

Greg-DB

Apologies, no update right now. I'll check in with the right people again.

Craig M.21

Has this been fixed recently? I did not run in to permission issues using the following code to initiate download...

Intent&nbsp;intent&nbsp;=&nbsp;new&nbsp;Intent(Intent.ACTION_GET_CONTENT);

intent.setType("*/*");

startActivityForResult(intent,&nbsp;PICKFILE_RESULT_CODE&nbsp;);&nbsp;&nbsp;

The uri returned in onActivityResult was this:

file:///storage/emulated/0/Android/data/com.dropbox.android/files/scratch/Kanji%20Sketch%20Pad/KanjiKnowledge.ks

Processing the data in onActivityResult required a bit of a workaround for Dropbox, which I'll mention in a separate thread, but my app read the file okay. Does the issue only appear under certain circumstances?

Craig M.21

I should add, I am using Android 5.0.2, device is HTCOne,

Greg-DB

Still no news on potentially using content:// instead yet, but I'll ask engineering if something changed about the existing behavior/any guidance.

Greg-DB

Thanks for your patience Craig. I heard back from engineering here with the following information:

FLAG_GRANT_READ_URI_PERMISSION seems to have no effect.
On Android API level 18 (and presumably probably below), specifying READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE does not matter. The calling app is able to read the file irrespective of these settings.
On Android API level 19 and above, the calling app needs the READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permission to be able to read the data provided by us.

Also, on Android API level 19 and above caller will need to read the data using the ContentResolver#openInputStream(fileUri) method to be able to read the files. While on API level 18 and below directly creating the file object to read the file works.

Craig M.21

Thanks for that. I have not had any problems with reading the file. I am therefore unsure what the problem was that the other posters met.

I have read and write permissions set.

I initially used code like this (based on suggestions found online):

ParcelFileDescriptor mInputPFD = null ;

           try {

                mInputPFD = getContentResolver().openFileDescriptor(returnUri, "r");

           } catch (FileNotFoundException e) {

                e.printStackTrace();

                System.out.println("File not found...");

                return;

           }

if(mInputPFD!=null){

   fd = mInputPFD.getFileDescriptor();

   FileInputStream fis = new FileInputStream(fd);

   //process the input stream

}

I tried the more direct method suggested above and it also worked:

FileInputStream fis = null ;

   try {

           fis = (FileInputStream) getContentResolver().openInputStream(returnUri);

   }

   catch (FileNotFoundException e1) {

           e1.printStackTrace();

           System.out.println("File not found...");

             return ;

   }

//process the input stream

I am using targeted Android API 19.

Can I assume that the ContentResolver#openInputStream(fileUri) method will also work on API 18 and lower?

Greg-DB

openInputStream was added in API level 1 and is documented to support both content and file schemes, so it looks like it should work.

Hi, thanks for useful Dropbox.

I have same problem.
So, does the future version of Dropbox support `content://` URI?
I hope that Dropbox returns `content://` URI that works fine without `READ_EXTERNAL_STORAGE` permission such as sharing files by `FileProvider`. I really hope so.
I don't want that the my apps require more permission that make users feel uneasy.
And then, I think that more users use Dropbox as the place to save files of more apps. Because since Kitkat many apps use `FileProvider` and they don't read/write the file by oneself.

Greg-DB

I don't have an update on the Dropbox for Android app potentially returning content:// links for ACTION_GET_CONTENT in the future, but I'll be sure to pass this along as feedback.

Evgeny B.

Same issue. My app does NOT has READ_EXTERNAL_STORAGE permission. I'm using ACTION_GET_CONTENT intent to pick file from any app that can handle it. The Dropbox returns URI starting with 'file://' and my app can not read file since there is no permission. Other apps (including Google Drive) returns URI starting with 'content://' and my app can read it without any issue. As a result, users of my app can not use Dropbox to pick file. It forces them to use different app. I think you better fix it to stop loosing users. Why you still don't have any plans regarding the issue?

Greg-DB

Thanks for the additional feedback Evgeny! I can't speak to why or why not particular changes are or aren't implemented, but we appreciate everyone taking the time to write, and I'm sending this along to the team.

Hello, Gregory. Thank you for your reply.
I have one more question.
When the Dropbox supports `content://` URI, can we get that notification?
e.g. a comment at here, your blog or a page such as the release-note.
(It seems that the update information in the Google Play page does not include the information about development.)

We need that notification because we will have to update our apps at that time.

Greg-DB

I'll be happy to update this thread if/when I have any news on this.

Thank you!

Marius V.

Hi Gregory,

I imagine the team is already aware of this, but in Android Marshmallow the READ_EXTERNAL_STORAGE permission is classified as "dangerous" and requires for the developer to request, and the user to grant, permission at runtime. As you can imagine, the experience is rather strange for a user:

User opens Dropbox
User clicks file
User chooses my app
My app launches and asks to access the SD card

The context isn't there for a user as to why my app suddenly needs to get access to the SD card.

One thing I noticed, is that using the export functionality in the Dropbox app does not require the READ_EXTERNAL_STORAGE permission, so I assume this does share a content:// uri.

Greg-DB

Thanks for the feedback Marius!

Josh Y.1

Hi Gregory,

Is there any update on this issue? Users of my app are unable to upload files from Dropbox at the moment, while other services like Google Drive working fine. The only way for me to fix this is to add a permission prompt to my app specifically for Dropbox.

One of the great benefits of using the file picker in Android Marshmallow is that you can share files safely between apps without having to grant permissions that would allow apps to have access to more files than are necessary. It would be great if Dropbox returned a URI using the content:// scheme so that users don't have to deal with unnecessary permission prompts.

Thanks!

Greg-DB

Thanks for the feedback Josh. I don't have an update on this unfortunately, but I'll send along your feedback as well.

Chun Yeen M.

I'm writing a new app and bump into the same issue here. Please support `content://` URI for the same reasons mentioned by posters above. It is an extra unnecessary unsafe permission viewed from user's perspective.

Fix this please?

Greg-DB

Thanks for the feedback! I'm sending it along to the team.

Anton S.7

+1, have the same issue. It was acceptable prior to Marshmallow (but not ideal of course) but now it looks like I just have to ask users my users for READ permissions just to be able to read files returned by Dropbox...

Andy H.31

+1 for supporting 'content://' since I'm getting mixed bug reports, where our import feature works on some devices but not others.

So this problem is bad especially because the results are inconsistent...

Chun Yeen M.

It has been half a year since... any updates on this?

Greg-DB

No, unfortunately I don't have an update on this.