The FileProvider documentation lists these locations as places where it can serve files from:
the files/ subdirectory of an app's internal storage area
the cache subdirectory of an app's internal storage area
the root of the external storage area
the root of an app's external storage area
the root of an app's external cache area
There are FileProvider descendants, such as Commonsware's CWAC Provider, which also allow files to be served from:
an app's raw resources folder
an app's assets folder
the folder returned by getDir()
the folder returned by Environment.getExternalStoragePublicDirectory()
But (if it doesn't have some fatal drawback) how would one write a FileProvider that grants access to an app's existing drawables (without first making copies of those drawables in another folder)?
There is no downside, but this might be pointless (see explanation below).
To implement such access fork source code of CWAC Provider and replace it's use of raw resources folder with drawables folder. Commonly used drawable formats (png and jpg) are stored uncompressed by aapt, so there is no difference between raw resources and drawables in that aspect. Note, that since drawables are usually prepared for multiple configuration buckets, you will need caller to specify, which dimension/resolution they need (for example via additional custom query parameters in Uri).
That said, depending on your goals, using ContentProvider to access application resources might be unnecessary. If your app is not DRM-protected, it's apk and resources are going to be stored unencrypted on device. Any installed application can easily access those resources without going via ContentProvider: to do so just call createPackageContext and use the Resources object of returned Context as if those were ordinary local Resources of your own.