Thanks for the research @Doo_Rim
I find it hard to believe that the override is the problem here, so I did more research.
I don’t see the problem you mention about the manifest merger overriding any resource.
In the following screen you can see how both file providers are perfectly added to the final manifest, each with it’s own provider file paths.
However, what I do see, is that the SendBird SDK is using a basic authority for it’s provider. This accidentally clashes with the authority defined for my FileProvider subclass, as it’s my application package/id + “.provider”, basically the documentation recommendation.
This is the key issue.
If I change my authority to something different, everything works without me adding the root-path to my file provider paths.
This is SendBird miss using the application id (of which you should have no control or use) for configuring internal components.
As I said on the other report, as an SDK provider, you should have your own FileProvider subclass and authority to not interfere with the application in which your SDK is running.
The other report should still be a valid and all this should be documented somewhere.
