5 ms·

When referring to google drive, I meant whatever the app/service is that backs up your device to Google Drive. As you cant switch out the backend that uses (it

When referring to google drive, I meant whatever the app/service is that backs up your device to Google Drive. As you cant switch out the backend that uses (it is hard coded to use google drive), you would need the same permissions in order to replicate it.

nolist_policy 1y ago
On Samsung devices you can backup to a Samsung account also.
tadfisher 1y ago
Device backups are an entirely different system, not handled by the Drive app, that produces opaque backup archives which aren't accessible via the Drive UI. Nextcloud isn't complaining about lack of access to this system, but to the file-level APIs (e.g. java.io/java.nio classes) that allow for full backups of whatever the app has system-level permission to read.
- supermatt 1y ago
  According to the article they are complaining about not being granted the MANAGE_EXTERNAL_STORAGE permission. https://developer.android.com/reference/android/Manifest.permission#MANAGE_EXTERNAL_STORAGE https://developer.android.com/reference/android/Manifest.per... This permission still doesn’t have the same access as the backup utility, but that is another issue really. If they aren’t willing to open that up then they need to allow for pluggable 3rd party storage backends.
  - tadfisher 1y ago
    Define "storage backend". You can implement a FileProvider to plug into the Storage Access Framework as a provider, so other apps can browse and request permissions for all of your app's files. You can use the Storage Access Framework as a consumer and ask the user for permissions to read any directory on external storage that is not Downloads/ or Android/{data,obb}, and any files exposed by other apps. Google's own apps use these APIs and do not declare MANAGE_EXTERNAL_STORAGE.
    - supermatt 1y ago
      Maybe you need to actually read the article… this is the second rebuttal you have made that is covered there.
      - tadfisher 1y ago
        I have read the article, thoroughly, as well as Nextcloud's blog post. This is the extent they have to say about why they cannot use SAF: > SAF cannot be used, as it is for sharing/exposing our files to other apps What I am saying is absolutely not covered by this statement, which is factually incorrect.
        deleted 1y ago
        [deleted]
        supermatt 1y ago
        “some apps have a core use case that requires broad access to files on a device, but can't access them efficiently using the privacy-friendly storage best practices. Android provides a special app access called all-files access for these situations.” “For example… anti-virus apps… file manager apps, backup and restore apps, and document management apps“ https://developer.android.com/training/data-storage/manage-all-files https://developer.android.com/training/data-storage/manage-a... NextCloud provides backup, restore, and document management. I guess you may know more about this than the official android docs, but maybe you are just being blinkered by some incorrect assumption? Maybe we would be best to frame this another way. What permissions do NextCloud need to be able to replicate “Google One”? The complete replacement of Google drive (the service, not the app - you are consistently conflating the two) is what they aim to be. Is that something that can be done with SAF, or are Google using elevated permissions to lock competitors out?
        jospoortvliet 1y ago
        Hi folks, It's true some of our functionality can be rebuilt if we rewrite this functionality with SAF - even though it makes the user experience a bit worse. We have a file manager/document management app, which fits the use case for the full permission. There are some functions that are popular with some users like syncing a whole SD card, the download folder or the data of specific apps (in Android/data - some users use our app in a way as backup) that are just not possible with SAF. We get the security concerns from Google, but Box has this permission, so do quite some others, so our preferred solution is to re-gain the permission rather than bring back part of the functionality. The good news is that this morning Google got back to us and told us that on resubmission we will regain the permission we need and our users regain all functionality within a few days. So, this seems to have been resolved in a nice way. Thanks, all for the support!

nolist_policy 1y ago

On Samsung devices you can backup to a Samsung account also.

tadfisher 1y ago

Device backups are an entirely different system, not handled by the Drive app, that produces opaque backup archives which aren't accessible via the Drive UI. Nextcloud isn't complaining about lack of access to this system, but to the file-level APIs (e.g. java.io/java.nio classes) that allow for full backups of whatever the app has system-level permission to read.

supermatt 1y ago
According to the article they are complaining about not being granted the MANAGE_EXTERNAL_STORAGE permission. https://developer.android.com/reference/android/Manifest.permission#MANAGE_EXTERNAL_STORAGE https://developer.android.com/reference/android/Manifest.per... This permission still doesn’t have the same access as the backup utility, but that is another issue really. If they aren’t willing to open that up then they need to allow for pluggable 3rd party storage backends.
- tadfisher 1y ago
  Define "storage backend". You can implement a FileProvider to plug into the Storage Access Framework as a provider, so other apps can browse and request permissions for all of your app's files. You can use the Storage Access Framework as a consumer and ask the user for permissions to read any directory on external storage that is not Downloads/ or Android/{data,obb}, and any files exposed by other apps. Google's own apps use these APIs and do not declare MANAGE_EXTERNAL_STORAGE.
  - supermatt 1y ago
    Maybe you need to actually read the article… this is the second rebuttal you have made that is covered there.
    - tadfisher 1y ago
      I have read the article, thoroughly, as well as Nextcloud's blog post. This is the extent they have to say about why they cannot use SAF: > SAF cannot be used, as it is for sharing/exposing our files to other apps What I am saying is absolutely not covered by this statement, which is factually incorrect.
      - deleted 1y ago
        [deleted]
      - supermatt 1y ago
        “some apps have a core use case that requires broad access to files on a device, but can't access them efficiently using the privacy-friendly storage best practices. Android provides a special app access called all-files access for these situations.” “For example… anti-virus apps… file manager apps, backup and restore apps, and document management apps“ https://developer.android.com/training/data-storage/manage-all-files https://developer.android.com/training/data-storage/manage-a... NextCloud provides backup, restore, and document management. I guess you may know more about this than the official android docs, but maybe you are just being blinkered by some incorrect assumption? Maybe we would be best to frame this another way. What permissions do NextCloud need to be able to replicate “Google One”? The complete replacement of Google drive (the service, not the app - you are consistently conflating the two) is what they aim to be. Is that something that can be done with SAF, or are Google using elevated permissions to lock competitors out?
        jospoortvliet 1y ago
        Hi folks, It's true some of our functionality can be rebuilt if we rewrite this functionality with SAF - even though it makes the user experience a bit worse. We have a file manager/document management app, which fits the use case for the full permission. There are some functions that are popular with some users like syncing a whole SD card, the download folder or the data of specific apps (in Android/data - some users use our app in a way as backup) that are just not possible with SAF. We get the security concerns from Google, but Box has this permission, so do quite some others, so our preferred solution is to re-gain the permission rather than bring back part of the functionality. The good news is that this morning Google got back to us and told us that on resubmission we will regain the permission we need and our users regain all functionality within a few days. So, this seems to have been resolved in a nice way. Thanks, all for the support!