Android integration on Content Provider API

Feature requests
1

Use case or problem

Android provides a Content Provider API, which enables other apps to manipulate with app’s internal data.

Storage encryption apps like DroidFS or EDS Lite implement Content Provider API, so they can expose its decryptes volumes/containers to other apps, which can integrate on these “content providers”; for example, file manager app Material Files can attach “content provider” as an external storage and manage its content – any file action will be handled by content provider, which will encrypt all these file changes.

If Obsidian for Android will be able to work with Content Provider API, users will be able to keep their vaults in encrypted volumes.

Proposed solution

Similary as above mentioned Material Files is able to view, edit, create and delete files via Content Provider API, Obsidian can do the same to provide users more options in terms of notes storage.

Current workaround (optional)

Workaround could be using some app, which is able to mount its volume/container as external storage with file system structure (if you know such app, please let me know).

Related feature requests (optional)

Related problem Error: This path can not be resolved: contetn://sushi.hardcore.droidfs.volume_provider/tree

2

Another use case

Cloud storage apps for Android are probably also implementing Content Provider API – this opens a door for Obsidian to manage vaults directly in cloud.

3

What you are asking is more frequently asked on the iOS side. The problem with these APIs is that they are not good enough for Obsidian. They were designed for apps that request one file at time. Obsidian manages your whole vault. It monitors your whole vault for changes to keep its structures and the links correct.
These higher level APIs complitely lacks some features obsidian relies on. Moreover, they have terrible performance because they introduce a level of abstraction over the real files.

4

Performance can solved by building some cache with current changes so search and other operations could work with cached state.

Although I’m not sure if it is worth of time implementing this if the demand for such feature is low, but I still think it could be a nice addition.