You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Android support for content:// uri in the File class. #25659
Flutter does not support content:// uri in Android. I cannot use such a uri in the File class to read the attached file in Gmail (for example, when opening an attached file from an email through a flutter application via deep linking).
You can write a plugin that will read files at such a URI, but this will not be a cross-platform code, since you will have to remember that in Android, content:// uri files must be read through the plugin, and in iOS via File class.
It would be nice to support this type of uri in the File class on Android.
You can write a plugin that will read files at such a URI, but this will not be a cross-platform code,
That's common that the platform implementation between Android and iOS are different.
Why do you think that would be a problem in this case?
Because you have to check the platform in the dart-code, and read the file differently on different platforms. What is the advantage of Flutter then? After all, this difference can be hidden inside the file management classes.
@andyduke you can provide it the same way from native to Dart from iOS and Android so that you don't know the difference on the Dart side.
I still don't see the problem.
When a link to a file comes into my dart-code (via a deep link, from the document picker, etc), it is necessary to check if it is a content uri and read it either through the File class or through a plugin. Thus, it is necessary to think about how to read the link to the file in different ways, and only in Android. This kills all the benefits of Flutter as a cross-platform development tool.
There won't be a content:// uri on iOS, os is this even relevant, or would it?
You still can wrap different approaches behind a common API in Dart so that the user of a plugin doesn't need to know the difference.
Some special behavior from the underlying platform will always leak through though.
There is no content uri on iOS, there is an Android only. When you receive a link to a file, you need to check which link it is and write a lot of different code to process it. Since files are a fundamental thing, there will be many such places. Files can be used differently, converted from JSON, passed to the Image class, used when calling other libraries. It’s not always possible to do processing, for example, it’s difficult to pass such a link to the Image class.
Therefore, I think it would be correct to hide this Android feature inside the base classes for working with files, otherwise they are not needed at all (since they do not perform their task), let everyone write their own file plug-ins for all platforms - now it looks exactly like that. And it is all the more strange since Flutter and Dart are developed by Google, but for Android you need to use a dirty workaround.
A content URI allows you to grant read and write access using temporary access permissions... In comparison, to control access to a file:///Uri you have to modify the file system permissions of the underlying file.
The content:// uri's are also used to support temporary file permissions in Android. I feel like this should be bumped in priority. Personally, I'm trying to sync files from my flutter app to the local file storage but am unable to do so because of the file restrictions. I can solve this by requesting the MANAGE_EXTERNAL_STORAGE permission on android, but, my app isn't qualified for this permission.
I suspect it would be closed there as well though, since it's not at all clear how many of the APIs in File would work. content URIs aren't files, they are their own distinct concept; that's why they have a different scheme in the first place.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
zoechi commentedon Dec 21, 2018
That's common that the platform implementation between Android and iOS are different.
Why do you think that would be a problem in this case?
andyduke commentedon Dec 23, 2018
Because you have to check the platform in the dart-code, and read the file differently on different platforms. What is the advantage of Flutter then? After all, this difference can be hidden inside the file management classes.
zoechi commentedon Dec 24, 2018
@andyduke you can provide it the same way from native to Dart from iOS and Android so that you don't know the difference on the Dart side.
I still don't see the problem.
andyduke commentedon Dec 24, 2018
When a link to a file comes into my dart-code (via a deep link, from the document picker, etc), it is necessary to check if it is a content uri and read it either through the File class or through a plugin. Thus, it is necessary to think about how to read the link to the file in different ways, and only in Android. This kills all the benefits of Flutter as a cross-platform development tool.
zoechi commentedon Dec 24, 2018
There won't be a
content://uri on iOS, os is this even relevant, or would it?You still can wrap different approaches behind a common API in Dart so that the user of a plugin doesn't need to know the difference.
Some special behavior from the underlying platform will always leak through though.
andyduke commentedon Dec 24, 2018
There is no content uri on iOS, there is an Android only. When you receive a link to a file, you need to check which link it is and write a lot of different code to process it. Since files are a fundamental thing, there will be many such places. Files can be used differently, converted from JSON, passed to the Image class, used when calling other libraries. It’s not always possible to do processing, for example, it’s difficult to pass such a link to the Image class.
Therefore, I think it would be correct to hide this Android feature inside the base classes for working with files, otherwise they are not needed at all (since they do not perform their task), let everyone write their own file plug-ins for all platforms - now it looks exactly like that. And it is all the more strange since Flutter and Dart are developed by Google, but for Android you need to use a dirty workaround.
agnoam commentedon Jun 2, 2019
Someone has made this plugin ?
KasemJaffer commentedon Jun 19, 2019
You can use this library to get the absolute path that will work with the dart class File
https://pub.dev/packages/flutter_absolute_path
1 remaining item
KasemJaffer commentedon Jun 28, 2019
Yes, that was mainly added to support content URIs that are under the authority of other apps like google photos.
No, you will have to delete the file after you finish using it.
agnoam commentedon Jun 30, 2019
matheuscaldasrj commentedon Sep 25, 2019
Any suggestion on how to get WhatsApp file Audio having an URI like 'content://whatsapp.media.....' ?
I have opened this issue in
flutter_absolute_pathbut I am pretty sure there is another way to do it.matthewwong525 commentedon Dec 29, 2022
The
content://uri's are also used to support temporary file permissions in Android. I feel like this should be bumped in priority. Personally, I'm trying to sync files from my flutter app to the local file storage but am unable to do so because of the file restrictions. I can solve this by requesting theMANAGE_EXTERNAL_STORAGEpermission on android, but, my app isn't qualified for this permission.stuartmorgan-g commentedon Mar 9, 2023
Closing, since
Fileis part of Dart, not Flutter, so this would need to be filed at https://github.com/dart-lang/sdk/issues.I suspect it would be closed there as well though, since it's not at all clear how many of the APIs in
Filewould work.contentURIs aren't files, they are their own distinct concept; that's why they have a different scheme in the first place.github-actions commentedon Mar 23, 2023
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.