[FEATURE REQUEST] Scoped Storage

[jesmrec]

Place to discussion about the necessary feature in the close future

Documentation:

https://developer.android.com/preview/privacy/storage?hl=en
https://developer.android.com/training/data-storage

Scoped storage will provide a way to enclose user data related to an app.

Research: #2894

TASKS

• Research (if needed) -> SPIKE [SPIKE] Scoped storage #2894
• Create branch feature/scoped_storage
• Development tasks
  • Recheck of the spike
  • Update target to 30 (Android 11 #2920)
  • Remove flag to opt-out the scoped storage
  • Select a new location inside the sandbox
  • Files downloaded stored in the scoped storage.
  • Taking a photo within ownCloud is uploaded properly
  • 'Open with' have enough permissions to open a file with other apps.
  • 'Share with' have enough permissions to share a file with other apps.
  • Camera uploads have enough permissions to access the camera folder and get pictures from there.
  • Sharing files with ownCloud works as expected.
  • Chunk uploads works as expected
  • 'Upload files from local storage' works as expected
  • Recheck permissions to access folders in setup, like camera folder in auto uploads... (check if native picker helps)
• Code review and apply changes requested
• Design test plan
• QA
• Merge branch feature/scoped_storage into master

PR

• App Scoped Storage #3269

This is part of Android 10 target: #2576

[jesmrec]

Needed: upload targeting to API 29. Should we do in advance and test separately? or... is it not a problem to do in the same PR/PRs as scoped storage? @abelgardep @davigonz

[abelgardep]

Needed: upload targeting to API 29. Should we do in advance and test separately? or... is it not a problem to do in the same PR/PRs as scoped storage? @abelgardep @davigonz

We could do it separately if we add the next attribute: requestLegacyExternalStorage.

[jesmrec]

Some regards with this, after discussing (from #2872 (comment) by @abelgardep ).

The initial question is: how must be stored a file in the device after downloading??. There will be three kinds of download (by @abelgardep)

• Previews: They could be downloaded to the app-specific storage and maybe to the cached one. This way we could free some space when needed

• Av. Offline: They could be downloaded to the app-specific storage and it may have sense to store them in the persisted one

• Select and download: This behavior could be changed and make it download to the downloads folder if the user considers it important to persist it.

What i think about it:

• Previews: i like the idea they can be removed from cache, manually, or automatically (feasible as future improvement? iOS app implements this). That means, file is downloaded only to be previewed

• Av. Offline: They must be persisted in scoped storage.

• Select and download: Would it make sense to get rid of this option? i mean, with Previews you can open and check a file by clicking on it. If this file is important for you, you will make it av. offline and will be always stored and synced in your device. Downloading a file and keep it in the device in a non-synced way does not offer advantages (doesn't it?). Indeed, we have to take care of the space limit. What do you think??

As @theScrabi , the "Download" option should have a different meaning (saving the file somewhere in the device storage, out of the scoped storage) and should have renamed to "Export" or something similar when it is implemented.

This discussion has some product and security concerns, that must be agreed before implementing.

CC @michaelstingl

[michaelstingl]

• Select and download: Would it make sense to get rid of this option? i mean, with Previews you can open and check a file by clicking on it. If this file is important for you, you will make it av. offline and will be always stored and synced in your device. Downloading a file and keep it in the device in a non-synced way does not offer advantages (doesn't it?). Indeed, we have to take care of the space limit. What do you think??

I think export and safe somewhere on the storage is already possible with native Android feature. Then "Select and download" is no longer needed. If users really need it, they can set ab. offline.

[abelgardep]

We could check this repo when we decide to work on Scoped Storage. It could have interesting information.

[abelgardep]

Migration from current storage to scoped storage.

For a common scenario: App installed and files are stored in external storage in the device.

Case 1: Device API<29 (before Android 10)
A device whose current API is lower than 29, could access the external storage after migrating to scoped storage. They keep read/write external storage permission. New files will be downloaded to scoped storage. Smooth transition.

Case 2: Device API>=29 (Android 10 and later)
A device whose current API is 29 or higher, will lose access to current downloaded files after moving to scoped storage.

It means that we will need to reset the field where the downloaded path is stored in the database. This way, files won't appear as downloaded and, sadly, they will need to be downloaded again. Additionally, we will need to ask the user for the removal of old files in the external storage.

EDIT: We could request preserveLegacyExternalStorage so we can migrate files by ourselves: https://developer.android.com/training/data-storage/use-cases?hl=en#migrate-legacy-storage

Fresh install

Files are stored in scoped storage location as expected. Nothing to do here.

[abelgardep]

I think that we should resume the work in #125 before moving to ScopedStorage.

Scoped storage is limited and we should free space after each account deletion.

As #125 (comment) states, there are 2 different cases:

• Removing the account from the app -> Probably the most common case. Should not be so complex to include. Would be enough for a first iteration. Will be done in Files remain if deleting account #125
• Removing the account from Device settings -> Not so common and harder to manage. (Future feature. Garbage collector worker?)