Closed lifenautjoe closed 4 years ago
Hi @lifenautjoe, this is a no-issue and actually what is happening is that the picker is working as it should by allowing users to pick files from wherever they are allowed to (and that's why it works). What you can't do tho, is writing files from directories that you don't have permissions, such as that one '/storage/emulated/0/WhatsApp/Media/WhatsApp
which is from WhatsApp app.
Even though you are free to pick the files you want and use it to display some data, for example, as a developer, if you are going to write some file, you need to make sure that you write/move the files to your app's content folder or some cache directory.
Regarding the WRITE_EXTERNAL_STORAGE
being deprecated on Q, the plugin doesn't have it at all. It's on the wiki because older SDK Android versions may actually need that, but it won't hurt if you have it as well. 🙂
I'm closing this as it doesn't represents an issue, but feel free to keep the discussion here if you still have any question.
Thank you.
Hmm we're not trying to write to the file nor the directory it's in, we're actually just trying to read it with pickedImage.readAsBytesSync()
as seen here
https://github.com/OkunaOrg/okuna-app/blob/release/0.0.55/lib/services/media.dart#L64
this library is used on the showImagePicker
just before this. It shows a bottom sheet asking to select source, and returns the picked file
I'll try copying the file somewhere else before even trying to read it (?)
@lifenautjoe that's probably because that ImageConverter
is writing on the same directory from which is picked and it can't. It's up to the developer to decide where to write the files and since you are creating a copy (converted), you should place it in a temp directory or your own app content directory.
Like I said, FilePicker
gives you the file as it is, this is, from its original directory (whenever possible) but that doesn't mean that you can actually write on it and you shouldn't assume that because there are a lot of folders on Android that can be accessible to read but not write.
In iOS you won't have this issue because the native picker delegate already forces a cache copy to the app's content.
hah, didn't think about that one, will give it a try :-)
You should get a buymeacoffee page Miguel, we'd be happy to send some coffees for your time and help!
No need to thank me @lifenautjoe, always glad to help! 🙂 Just because of you, I've created one here ☕️ 😄
Thank you!
Cool! I've sent some coffee's your way ☕️ .
In regards to the issue we're having, we've changed the code to intermediately copy the file to a directory we have permissions with getApplicationDocumentsDirectory()
, still seeing the same issues.
FileSystemException: FileSystemException: Cannot copy file to '/data/user/0/social.openbook.app/cache/mediaCache/fd3e9541-7ef2-40b9-85af-18373f02e208VID_20191102_164450.mp4', path = '/storage/emulated/0/DCIM/Camera/VID_20191102_164450.mp4' (OS Error: Permission denied, errno = 13)
File "create_post.dart", line 609, in OBSavePostModalState._onError
File "async_patch.dart", line 43, in _AsyncAwaitCompleter.start
File "create_post.dart", line 593, in OBSavePostModalState._onError
File "create_post.dart", line 410, in OBSavePostModalState._getImagePostActions.<fn>
File "async_patch.dart", line 78, in _asyncErrorWrapperHelper.<fn>
File "zone.dart", line 1144, in _rootRunBinary
File "zone.dart", line 1037, in _CustomZone.runBinary
File "future_impl.dart", line 151, in _FutureListener.handleError
File "future_impl.dart", line 690, in Future._propagateToListeners.handleError
File "future_impl.dart", line 711, in Future._propagateToListeners
File "future_impl.dart", line 530, in Future._completeError
File "async_patch.dart", line 36, in _AsyncAwaitCompleter.completeError
File "media.dart", line 0, in MediaService.pickVideo
File "async_patch.dart", line 71, in _asyncThenWrapperHelper.<fn>
File "zone.dart", line 1132, in _rootRunUnary
File "zone.dart", line 1029, in _CustomZone.runUnary
File "future_impl.dart", line 137, in _FutureListener.handleValue
File "future_impl.dart", line 678, in Future._propagateToListeners.handleValueCallback
File "future_impl.dart", line 707, in Future._propagateToListeners
File "future_impl.dart", line 522, in Future._completeWithValue
File "async_patch.dart", line 30, in _AsyncAwaitCompleter.complete
File "async_patch.dart", line 288, in _completeOnAsyncReturn
File "media.dart", line 0, in MediaService._getTempPath
File "async_patch.dart", line 71, in _asyncThenWrapperHelper.<fn>
File "zone.dart", line 1132, in _rootRunUnary
File "zone.dart", line 1029, in _CustomZone.runUnary
File "future_impl.dart", line 137, in _FutureListener.handleValue
File "future_impl.dart", line 678, in Future._propagateToListeners.handleValueCallback
File "future_impl.dart", line 707, in Future._propagateToListeners
File "future_impl.dart", line 522, in Future._completeWithValue
File "future_impl.dart", line 552, in Future._asyncComplete.<fn>
File "zone.dart", line 1124, in _rootRun
File "zone.dart", line 1021, in _CustomZone.run
File "zone.dart", line 923, in _CustomZone.runGuarded
File "zone.dart", line 963, in _CustomZone.bindCallbackGuarded.<fn>
File "schedule_microtask.dart", line 41, in _microtaskLoop
File "schedule_microtask.dart", line 50, in _startMicrotaskLoop
With the code
final tempPath = await _getTempPath();
final String processedImageUuid = _uuid.v4();
String imageExtension = basename(pickedImage.path);
// The image picker gives us the real image, lets copy it into a temp path
pickedImage =
pickedImage.copySync('$tempPath/$processedImageUuid$imageExtension');
I've found this issue on the image picker package which might be related https://github.com/flutter/flutter/issues/41459
People suggest removing some legacy flag as seen here https://github.com/flutter/flutter/issues/41459#issuecomment-536323793 or downgrading to target sdk 28 instead of the latest 29 as a workaround.
If it's really a bug, perhaps an interesting thread to follow for the fix on this library too.
Hi, thank you @lifenautjoe 🙌
This is really weird, there must be something missing there, if this was really an issue with the plugin, it should have affected a lot of other users already. 🤔
Could you provide the full steps and details to replicate? I’ll try to make it happen on my machine. Also, does it happens in the emulator or only in some real devices? If you could make it happen on any emulator, please, give me the details/steps of it as well.
Thank you!
Hi Miguel, it'll happen if you're on Android Q | 10.
And it will be solved by adding the following on the manifest file.
<application
android:requestLegacyExternalStorage="true"
Reading a bit more, looks like read external storage and write external storage permissions are being deprecated.
https://commonsware.com/blog/2019/06/07/death-external-storage-end-saga.html
And instead, there's scoped external storage with its respective methods : getExternalFilesDir(), getExternalCacheDir(), getExternalMediaDirs(), getExternalCacheDirs(), and getExternalFilesDirs() for storing files instead of the getTemporaryDirectory
and getApplicationDocumentsDir
There's a new release of the path_provider
plugin which chooses between the old and new directories but for some reason its breaking people's apps as well...
@lifenautjoe yes, I'm familiar with it being deprecated because they want us to always handle files using URI instead of real paths, and in a way, that's safer and much more easier that just covering all file path possibilities between SDK [16, 29]. However, for Flutter users, that's not very convenient as they need a lot of times real paths to display content on Flutter's side, that's why I've been keeping it.
If this is a thing, I don't bother add that flag to the File Picker package as well by leaving the developer with another thing to not miss. However, I'd like to replicate it here first. Could you make it happen on an emulator and provide me with the full steps?
Thank you once more.
@lifenautjoe ok, after digging a bit more around this, it seems that the issue is indeed with the path_provider
package and not this one. So, I'll break it down for you for better understanding:
file_picker
which gives you the file path without any issue, right? So, file_picker
gets its job done.path_provider
or any other path utility plugin. file_picker
we are not writing anything here, right?)android:requestLegacyExternalStorage="true"
, which is required to use the SDK scope, and it works because it's picking the old path (without the social.openbook.app
). That flag is only affecting the path_provider
, thus, making it work.TL;DR: Sometimes is hard to delegate the issue to the right plugin, specially when you are using multiple plugins for one operation. However, like I said, if this was really an issue with file_picker
I would have probably found it already when testing on Android Q or other users reported it, because it's a very common use case.
Again, after further investigation, I'm closing this, but it's always good to keep on track of this issues. If there's still anything that you didn't get, just let me know.
Thank you, I guess I'll get some coffee now before they cool down! 👀 ☕️
Thank you for the nice breakdown of the issue and help as usual Miguel!
Good rest of the weekend! ☕️ ☀️
Guys, I'm not convinced that you have found any long-term solution to the real problem here.
After doing a lot of reading on what Android 10's new scoped storage implies, I came to the following conclusions:
getUriFromRemote
which copies the file to the scoped cache folder by using the remote file's Uri, before returning the path of the file within the scoped cache folder, which can safely be used!The app I'm working on has 2 use cases that require refactoring for scoped storage compatibility:
I would recommend the following to make file_picker compliant with scoped storage:
getUriFromRemote
. This way Flutter devs can continue to use file paths across Android and iOS and not have to deal with Android Uris. You could also add a flag that skips this step for those that want to use the legacy storage for the next year, although I wouldn't do this - if Google and Flutter are deprecating it, you should too.@ovidiu-anghelina thank you for the huge feedback. I agree with both of your suggestions and I may added those in a near future, just need to have the time. 🙂
Is it maybe worth reopening this issue in order to improve its visibility and make it easier to keep track of it?
Sure. I’m already wiring up some solution for this @ovidiu-anghelina.
Hi Miguel, it'll happen if you're on Android Q | 10.
And it will be solved by adding the following on the manifest file.
... <application android:requestLegacyExternalStorage="true"
Can confirm. Had the exact same issue and the suggested (temporary) solution worked perfectly. It was really surprising to see that I could pick a file, query about it's existence but exception (Error 13) )was thrown as soon as I tried to actually read the contents of the file. (Android 10. OnePlus 7Pro).
BTW: Miguel, thx for great plugin! It rocks!
One additional comment from my observations: Within your plugin you use the method "Environment.getExternalStorageDirectory()". According to the [docs](https://developer.android.com/reference/android/os/Environment.html#getExternalStorageDirectory()), the method is depcreacted and the path returned by this method is not accessible by apps. Thus, even reading files from this folder using Flutter/Dart file methods will fail.
In case an image from the Camera folder is selected via file_picker, the internally resolved URI is 'content://media/external/images/media' (via MediaStore.Images.Media.EXTERNAL_CONTENT_URI) and the actually returned path is '/storage/emulated/0/DCIM/Camera/
It is really a big pain now to use files access in Flutter in combination with the scoped storage changes. I hope, you'll be able to update your plugin to help cover these issues. Thanks in advance.
Does this still happen with V2 embedded support? (file_picker: 1.5.0+2)
Thank you.
@miguelpruivo It still happen on my Android10 device (pixel3) with file_picker 1.5.0+2 java.io.FileNotFoundException: /storage/emulated/0/SendAnywhere/Square_LDAC_v1.1.8_DFU_1068.HEX: open failed: EACCES (Permission denied)
@dokinkon ok, might have forgot something that should fix your issue. Please, add the following
android:requestLegacyExternalStorage="true"
to your <application>
of your Android manifest file.
It should look like this:
<application
android:name="your app bundle"
android:label="your app name"
android:requestLegacyExternalStorage="true"
And let me know if it worked for you. If so, this should be added onto the Wiki.
This happens because Android 10 (Q) or above, require new scoped file system and won't work with legacy unless this flag is added.
Anyway, don't forget to flutter clean
before running after adding this.
Expecting to hear a feedback from you soon.
Thanks!
@dokinkon have you already tried? Nevertheless, added it to the docs.
Let me know so we can further close this issue. Thank you!
@miguelpruivo Sorry but how does adding the legacy flag help with closing this issue? As mentioned before, the legacy flag is only a temporary workaround, which will stop working as soon as Android 11 is released, regardless of the target SDK version. Any solution relying on the legacy flag is just a temporary solution.
@ovideozn no one knows if it will be deprecated on Android 11 or not, sometimes deprecated API's work until later versions. However, a problem at a time. Flutter needs absolute paths to handle Files, there's no way a Dart File
will use Android URI's.
I've been drafting a solution for it by wrapping it in a custom class that could manage both absolute paths and URI's, but iOS will always behave differently and that's one more thing for the dev to handle a less abstraction.
For now, having the flag will solve this issue as it offers a concrete solution or temporary workaround, if you prefer. I'll soon open a new issue regarding this with the motivation for scoped storage handling.
@miguelpruivo Fair enough.
Would the solution I mentioned above not work though?
Copy all selected files to the scoped cache dir before returning the paths of the copied files, in the same way you currently do for remote Uris using getUriFromRemote. This way Flutter devs can continue to use file paths across Android and iOS and not have to deal with Android Uris.
and
Offer an alternative of returning Uris instead of paths for those that don't want the files to be automatically copied to the cache folder.
I still think this is better than creating a custom class that wraps everything, as it would either have to extend File
, which would require long term maintenance, or it wouldn't extend File
in which case it will be difficult to work with in projects that already use File
s extensively.
@ovideozn first one will work, however, I'm not sure if some devs will starting open issues because the paths are not real but copies instead — which already happened when URI can't be resolved to a path and a temporary copy has to be made.
Second one, will match my purposed solution and that's probably the way to go. But I can agree that having files through a URI only and an optional method, such as getAndroidLegacyPath()
or so, can be more verbose.
Thanks for the input!
Closing in favor of #234.
FAILURE: Build failed with an exception.
Android resource linking failed /Users/mac/Documents/FlutterProjects/droopy/build/app/intermediates/merged_manifests/debug/AndroidManifest.xml:34: AAPT: error: attribute android:requestLegacyExternalStorage not found.
@braysonjohn148 you are using requestLegscyStorage
flag for a project that probably isn't targeting sdk 29.
Either change your target to it or remove the flag from your manifest file.
Describe the bug
We've received and seen several crashes related to permission denied trying to open a file that was picked on Android Q devices.
Looking for solutions, came across this https://github.com/flutter/flutter/issues/31122#issuecomment-485429597
where it's claimed that
and might the cause for issues.
Perhaps something to update in regards to how permissions are asked to the user on Android devices?
The strange thing is that users CAN pick the file with the modal, it's after we programatically try to access it's contents, we get the exception.
Issue details
Error Log
Flutter Version details