Add file path support for media URIs granted by createWriteRequest
This is an initial CL to setup feature flag and flow of file path
support for read/write operation for media URIs granted by
createWriteRequest.
This CL sets the ground for supporting multiple URI-formats check. Check
permission for other URI formats if the current checks fail/ throw
exception. If multiple URI-formats check fails, we throw the same error
and handle it in the same way as it is currently done.
Move file path checks before URI checks so that we do not have to call
them twice, after single URI check and after multi-URI check.
Call queryForSingleItemAsMediaPerovider instead of queryForSingleItem,
as that helps in easier code-readability for debugging and less code
duplication. This change will log "Access denied" instead of "File not
found" for apps that do not have read-access to a file, but that seems
okay as apps can anyway do a look up on a file to see if it exists or
not.
Resolve isSubtitleFile() as MediaProvideer. createWriteRequest grants
access to the passed URI even if the app does not have read access
for it. But a non-R_E_S app calling createWriteRequest for subtitles
file fails as it cannot query it to resolve its mediaType.
Important points to highlight:
* The new logic added in the CL to support other URI grants is executed
right before returning "Access denied" for the current workflow.
* If the file is accessible by the caller, new checks are a no-op.
* All new logic and extra checks are behind the feature flag.
TODO: rename and delete File APIs are not supported yet.
Bug: 173648980
Test: atest ExternalStorageHostTest#testMediaEscalation_RequestWriteFilePathSupport
Change-Id: If1b64e4f0ba98a18e33e5a850cc6a9e2c10c5637
Merged-In: If1b64e4f0ba98a18e33e5a850cc6a9e2c10c5637
(cherry picked from commit 79465e01490879cfdb7a06f81b5876d31c13ab49)
1 file changed