Open jangrewe opened 5 years ago
Happy to win the recognition of yours, @jangrewe.
They shouldn't change the style how we get the root of sdcard. :). And yes, we are late to migrate to Q. It is not finally released yet, after all. But yours req is the encouragement of ours. I'm working on review the changes of Q beta 1 to beta 6 and I hope the adaptive to Q can be released asap, if there's sth must have to be done. With the roadmap of Q, the final Public Release will be out at Q3 this year. Its privacy strategy might be violate, just off the top of my head.
As a workaround, you could always feed an exact starting filePath with withStartFile()
, this will ignore any internal defaults logic.
Thank you for the fast response!
I read somewhere that it should be possible to opt-out from "Scoped Storage" at least until Android R comes out with <application android:requestLegacyExternalStorage="true" ... />
, but it doesn't seem to work - maybe because i build with, target and run on SDK 29.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
Logger.d(Environment.isExternalStorageLegacy()); // output is always "false"
}
For now i'm trying to make my app at least somehow work on SDK 29 by using the mess that is DocumentProvider and ACTION_OPEN_DOCUMENT
, so it uses the system file picker, while using your library for anything <= 28.
Regarding withStartFile()
, i have been using that from the beginning, as i wasn't aware your library has a default that does pretty much the same if that option is not provided, but that's what breaks, because you can't reference a "raw" filesystem path to any storage location anymore, as the app gets sandboxed into its own data directory.
Here is a post that sums it up nicely: https://commonsware.com/blog/2019/06/07/death-external-storage-end-saga.html
Quick update: looks like i had to uninstall/reinstall the APK for requestLegacyExternalStorage
to work, so that's at least a small victory and will buy you & me some time. ;-)
It's quite a nice post. thanks. For new rule(s), it's quite complex.
requestLegacyExternalStorage
is good workaround.
I'm trying these on Q. We need make some decisions for the future. Media Store might be good choice, or break to new series such as 2.x.
And in another side, we could still use filesystem APIs inside app-specified filtered view, as document said. So, with this scenarios, afc ca n be update in a minimal scope, just for those default getters to /sdcard
....
An app that has a filtered view always has read/write access to the files that it creates, both inside and outside its app-specific directory trying...
Is this issue resolved? I tried in v1.2.final and still not working in Android Q.
@teoarjun On Android Q you can request requestLegacyExternalStorage
, however, begining from Android R (11) google is deprecating the Java File api which this library uses in favor of their SAF (which is slower but technically more secure).
More info here
Since there's not SAF on Android TV, MediaStore is the only way how to access files on external volumes. Therefore file chooser utilizing MediaStore is highly valued. (Especially when android-file-chooser works so well with non touch input) 👍
Hi, i migrated my app from a different library to yours yesterday, and i love how easy to use it is! Now i also wanted to prepare my app for Android Q (API 29), but already stumbled when trying to use
getExternalStorageDirectory()
to get the initial path for your dialog.According to the docs,
getExternalStorageDirectory()
is [deprecated in Q](https://developer.android.com/reference/android/os/Environment.html#getExternalStorageDirectory()) and apps don't have access to the path anymore. The recommended solution to useContext.getExternalFilesDir(String)
is kinda pointless, as it only allows you to access files underAndroid/data/data/your.package.name
, not/storage/emulated
.It looks like the best way forward is using MediaStore with a
Files
collection, but right now that would require a refactoring of your library.What are your thoughts?