android
android copied to clipboard
owncloud
[BUG] Moving to scope storage made my other apps unusable
After updating to the newest version of owncloud app (2.19 26b246abd) the app moved all my OC synced files to some kind of safe scoped storage.
Actual behaviour
I use OC for music and images auto sync between multiple devices. From now on all the other apps can't access my files (e.g. alarm clock, music player, ..).
Expected behaviour
I would like to keep the option make some of my files "unsecurely" stored so the other apps can use it. Otherwise the app is unfortunately not usable for me any more.
Steps to reproduce
N/A
Environment data
I think the problem is general for new release. I can update it later if requested.
Android version: Device model: Stock or customized system: ownCloud app version: ownCloud server version:
Logs
Web server error log
I think the problem is general for new release. I can update it later if requested.
ownCloud log (data/owncloud.log)
I think the problem is general for new release. I can update it later if requested.
Same here, i used the app to download audiobooks to my device and listen to them with an audiobook player. Since the update the audiobook player can no longer access the audio files.
I would also be fine with a "Download this folder to the local filesystem" feature.
Implementing the feature is mandatory from 1st Nov for new apps and updates, pointing to newer SDK version.
We could add an option to save a copy to another location, that your apps could reach. But, the copy will be out of ownCloud (no longer synced with the server).
All the apps that manage files must implement SAF to avoid such issues.
Well, the copy is not the best solution but if it is the only option, I would be happy. I think that the copy still could be synced (at least in the server -> device direction).
The best benefit of the OC app on my phone is using this synchronization because doing these synces manually is a little bit old-fashioned and painfull :-).
I have the same issue, and I only use the app on the phone for the sync feature with other apps.
Not sure what the SAF demands from the app, OC can not access "not safe" folders anymore? @jesmrec can you give more details so we can help figure out an alternative solution?
Not sure what the SAF demands from the app, OC can not access "not safe" folders anymore? @jesmrec can you give more details so we can help figure out an alternative solution?
SAF is the best solution to access oC apps, but, not every app implements it. Our alternative is -> #3462 allowing to fetch a copy (not synced) onto the external storage.
This makes ownloud unusable for me. I want to sync a bunch of text files between my and my wife's computers and phones.
My previous workflow was: unlock phone, tap my editor app, which then opens the last used file, and I can add my notes.
Now I have to swipe up or all apps, scroll left or right to find owncloud, start it, navigate the folders to find my notes file, long tap it (careful, if I tap too shortly, owncloud wants to show me the contents and that takes a moment for a 500kb txt file), tap the context menu, select edit, and pick my editor app. I'm old enough to forget what I wanted to write down while I was doing this elaborate ritual.
Security is nice, but usefulness always needs to be first concern.
What about an option to exclude certain folders from the security enclave? #3462 would not work for me, as I still want the syncing. Seems like I either need to use e.g., Dropbox, which sucks cause then I cannot use my own owncloud instance, or manually sync via rsync over ssh, or side-load owncloud 2.18.
My use case is broken as well. I use the owncloud app to annotate PDFs and sync between mobile devices and desktops. With the new storage feature, the edited files are not in scope of owncloud and, hence, not synced.
I use the owncloud app to annotate PDF
@0ddc0de Which app do you use to annotate PDF?
Implementing the feature is mandatory from 1st Nov for new apps and updates, pointing to newer SDK version.
Mandatory per who? This new "feature" has broken my workflow and made the app completely useless for me. If this is just a Google policy, can a different version be released via something like F-droid that retains the previous functionality?
can a different version be released via something like F-droid that retains the previous functionality?
Previous 2.18 version should be available on F-droid.
I just tested: ezPDF Reader can access ownCloud files directly.
Tap "⋮" icon on the top right, then choose "Open from Document Provider".
@michaelstingl, yea, and now annotate a PDF and save it again. For me, a copy of the PDF is created in /sdcard/Documents which is not in scope of ownCloud's sync.
can a different version be released via something like F-droid that retains the previous functionality?
Previous 2.18 version should be available on F-droid.
@thetoivonen https://f-droid.org/repo/com.owncloud.android_21800300.apk
And yes, this is a Google policy that we must implement to keep the app published. More info here
I just tried a few apps ...
the android team uses https://play.google.com/store/apps/details?id=com.marc.files to test the Document Provider integration. When you open that file manager app it will show you the configured owncloud accounts in the sidebar. everything 🍑
Now I also tested https://play.google.com/store/apps/details?id=com.orgzly which allows you to open a folder ... and while it seems to open the same dialog/intent, I don't see the owncloud accounts ... but I do see termux.
https://play.google.com/store/apps/details?id=com.aimp.player uses the dialog but shows the same list as orgzly... In the sidebar I see 'Öffnen aus' which might be 'open from' in english. In the Files app it is just called 'Dateien'... which might be the translation of the dialog ...
furthermore, neither https://play.google.com/store/apps/details?id=com.rhmsoft.pulsar nor https://play.google.com/store/apps/details?id=com.rhmsoft.omnia seem to use the document provider
For the latter two, I'd say that the apps need to adopt the document provider / SAF.
But for orgzly and aimp I am at a loss. Any idea?
orgzly -> it does not seem to implement document provider. The browser to add media files (showing "Termux") does not show other services even when they are installed (Dropbox, Box, GDrive... i have many services and no one is there either). I'd say this is not a document provider implementation, only a native local browser with some implementation restriction/filter that only Termux is able to pass (others will, i'm only using our example).
aimp -> it uses the document provider to import/export settings as backup (side menu -> gear icon on the bottom -> Backup). Here, you will find ownCloud as well as other providers. In order to open media files, same as orgzly. That means, not a document provider.
pulsar && omnia -> you are right, not implementing document provider.
Nowadays, there are many many many apps in Google Play that don't implement document provider. This is a problem since all apps must move their data to Scoped Storage, making content not accesible from other apps.
@abelgardep @fesave tell me if i'm wrong somewhere!
hm, orgzly does seem to use the ACTION_OPEN_DOCUMENT_TREE intent: https://github.com/orgzly/orgzly-android/blob/3d5e036ac198515874f511b11715f088cc3fba45/app/src/main/java/com/orgzly/android/ui/repo/directory/DirectoryRepoActivity.kt#L91-L136
val intent = Intent(Intent.ACTION_OPEN_DOCUMENT_TREE)
// ...
startActivityForResult(intent, ACTIVITY_REQUEST_CODE_FOR_DIRECTORY_SELECTION)
afaict the difference is local document providers vs "cloud backed" document providers. Is there an option to indicate that you are a cloud backed document provider for apps like owncloud onedrive dropbox ... or is there an option to tell the ACTION_OPEN_DOCUMENT_TREE intent to only list local document providers ... eg sd cards?
gnucash (which does show owncloud accounts) uses ACTION_OPEN_DOCUMENT and adds a category https://github.com/codinguser/gnucash-android/blob/2ad44adf6dd846aabf8883d41be3719b723bf4f1/app/src/main/java/org/gnucash/android/ui/common/BaseDrawerActivity.java#L237-L238
Intent openDocument = new Intent(Intent.ACTION_OPEN_DOCUMENT);
openDocument.addCategory(Intent.CATEGORY_OPENABLE);
hm but it seems you should not add that category if you want to be able to access virtual files: https://developer.android.com/training/data-storage/shared/documents-files#open-virtual-file
Aha, this post explains the flags that need to be implemented to let apps use ACTION_OPEN_DOCUMENT_TREE:
ACTION_OPEN_DOCUMENT_TREE While ACTION_GET_CONTENT and ACTION_OPEN_DOCUMENT focus on providing access to one or more individual documents, ACTION_OPEN_DOCUMENT_TREE was added in API 21 to allow a user to select an entire directory, giving the other app persistent access to the entire directory. Supporting ACTION_OPEN_DOCUMENT_TREE involves adding FLAG_SUPPORTS_IS_CHILD to your root and implementing isChildDocument(). This allows the framework to confirm that the given document ID is part of a certain document tree: remember a document can be in multiple places in your hierarchy so this is checking ‘downward’ as it were from parent to potential descendant (child, grandchild, etc). Ideally, this request shouldn’t rely on the network as it can be called frequently and in rapid succession so if you want to support this use case, make sure you can handle this request locally.
I can neither find FLAG_SUPPORTS_IS_CHILD nor isChildDocument in the owncloud/android codebase.
and there are more we should check:
Each functionality has a flag you need to add to document’s COLUMN_FLAGS and an associated method you need to implement to perform the operation:
- FLAG_SUPPORTS_DELETE (API 19) to delete the document entirely. Implement deleteDocument().
- FLAG_SUPPORTS_RENAME (API 21) to rename the document (changing its COLUMN_DISPLAY_NAME and optionally its COLUMN_DOCUMENT_ID). Implement renameDocument().
- FLAG_SUPPORTS_COPY (API 24) to create a copy of the document under a new parent directory within your DocumentsProvider. Implement copyDocument().
- FLAG_SUPPORTS_MOVE (API 24) to move a document from an existing parent directory to a new parent directory within your DocumentsProvider. Implement moveDocument().
- FLAG_SUPPORTS_REMOVE (API 24) to remove a document from its parent directory. Implement removeDocument().
This seems to be what termux does: https://github.com/termux/termux-app/blob/b33b906784457cbb038eb75003c23e0c2565ad5e/app/src/main/java/com/termux/filepicker/TermuxDocumentsProvider.java#L71-L78
Thanks for posting it @butonic.
Related to ACTION_OPEN_DOCUMENT_TREE, already suggested here, it was added in API 21 to allow a user to select an entire directory, giving the other app persistent access to the entire directory.
To begin with, I'm not sure if we want to give other apps persistent access to the entire directory. But if so, if we keep reading, we will find this statement:
Ideally, this request shouldn’t rely on the network as it can be called frequently and in rapid succession so if you want to support this use case, make sure you can handle this request locally.
As you can imagine, any operation to any file in the ownCloud directory will rely on the network. Otherwise, we could lead to an inconsistent state of the folder. For any operation in that folder (create a new document, rename a document inside the folder, move, copy, remove), if we don't sync them immediately, we would potentially be generating conflicts with server files.
That's the main reason we have not implemented ACTION_OPEN_DOCUMENT_TREE yet.
About termux documents provider, we can see that it does not sync with any server anytime. For example, each time the file is edited in termux, it is only edited locally. But the the ownCloud App does sync with the server to avoid inconsistent states.
About the other Flags: DELETE, RENAME, REMOVE, COPY, MOVE: We already use them and all of them are synced with the server to avoid inconsistent states.
Every app has different use-cases and we need to differentiate between local providers and cloud providers. Anyway, we are open to explore new ways to satisfy new use cases.
well, reading files should always be possible. The use case for a music app of for pictures is mostly to read files ... and the owncloud app should cache them ... that should not rely on the network. If the files are written, yes we need to write to the server. Although we should be able to allow writing to the local version and then sync with the server in the background. Just like the desktop client does with the VFS.
So, I'm pretty sure we should grant access to entire directories. But I get that that means we may need to implement the full sync. We should at least be able to cache files. @michaelstingl @felix-schwarz how is that handled on ios?
Same with me as the guys posted in november
have professionally to play music from an "easy to access" folder which is not working any more with the update
I can't find previous version 2.18 on fdroid
sorry for my english christian
@butonic The iOS app implements a VFS via the File Provider with offline support:
- files that exist locally can be read even when offline
- files can be modified/renamed/moved/deleted, new folders and files can be created when offline, with the changes being synced the next time the device goes online again
Hi ownclouders,
since the introduction of the scoped storage, we at sciebo got dozens of questions about that new feature and users weren't too happy about it to keep it mildly. It is hard to say, if there is a special use case that the users have, since most of them have their own, special workflow not completely equal to that of others. Long story short, we don't really like it and I tried to find out, if this can be mitigated. Somebody in a ticket from the fork gave a summary about the permission models:
- The old "access external storage read-write" permission is no longer available.
- The old "READ_EXTERNAL_STORAGE" permission now only allows access to media collections (mostly photos and videos).
- There is a new "All files" permission, that requires approval by Google and allows similar access to what we had before. This is what we're currently using. Additionally we require this permission for the app to work now. It isn't optional, as some stuff was broken without it. The new "All files" permission grant UX is scarier for the user. They get taken to a system dialog where they have to manually flip a switch and read that the app will have access to all data. This is an intentional privacy-aware change on Google's part.
I'm not sure if this is the way to go, but at least users can access their files again from other apps.
Do you see this as an option?
Cheers, Holger
Or even better, please introduce a switch in setting to enable/disable access from outside
hi holger,
meanwhile I am using an app called "files" by marc apps & software which lets me access my owncloud files locally
for my workflow this is more or less ok, before it was better and more convenient
but I personally can live with the situation now
I am using e / os / 0.23-20220406176461 - fairphone 3
ps hope that I understood your email - my english is not the best ...
On 11/15/22 13:37, Holger wrote:
Hi ownclouders,
since the introduction of the scoped storage, we at sciebo got dozens of questions about that new feature and users weren't too happy about it to keep it mildly. It is hard to say, if there is a special use case that the users have, since most of them have their own, special workflow not completely equal to that of others. Long story short, we don't really like it and I tried to find out, if this can be mitigated. Somebody in a ticket from the fork gave a summary about the permission models:
- The old "access external storage read-write" permission is no longer available.
- The old "READ_EXTERNAL_STORAGE" permission now only allows access to media collections (mostly photos and videos).
- There is a new "All files" permission, that requires approval by Google and allows similar access to what we had before. This is what we're currently using. Additionally we require this permission for the app to work now. It isn't optional, as some stuff was broken without it. The new "All files" permission grant UX is scarier for the user. They get taken to a system dialog where they have to manually flip a switch and read that the app will have access to all data. This is an intentional privacy-aware change on Google's part.
I'm not sure if this is the way to go, but at least users can access their files again from other apps.
Do you see this as an option?
Cheers, Holger
— Reply to this email directly, view it on GitHub https://github.com/owncloud/android/issues/3455#issuecomment-1315252428, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX5U76ODQNRWDWC6D5DF5BDWIN7YRANCNFSM5IMIPKOQ. You are receiving this because you commented.Message ID: @.***>
Document provider (SAF) integration is available in the app, and is the recommended way to go. Through this feature, all files and folders are available for other apps that include same integration. One example above by @christian-dienste. The main problem is many apps do not integrate SAF yet (they should/must but...).
Anyway, will check that permission (to be approved by Google) and how it would work with the current implementation. Will do after 3.0 release.
Any news on this? As for many others, it killed 95% of my use-cases for OwnCloud. Might not be entirely the fault of OwnCloud, it's still a bummer. This was the perfect solution for file synchronization that I loved to use for years. And with one update, all gone to the gutters, from perfect solution to utterly useless. And the dev response is "it works as intended, you are just using it wrong".
What use is a sync solution if you have to do it manually all the time by sharing every single file from/to OwnCloud everytime I want to sync.
My current recommendation: Ditch OwnCloud and go SyncThing. It's not as nice UI-wise, but at least it does what it's supposed to do, it synchronizes folders automatically, all folders across my phone. Something that, according to the devs here, should no longer be possible. Wonder why it's still possible for this app, then.
