Develop Reference

java.lang.IllegalArgumentException Volume external_primary not found in Android 10 devices

Crash : java.lang.IllegalArgumentException Volume external_primary not found
When querying for tracks from media store, I am getting this crash in some Android 10 devices (Most of them are from Xiaomi Mi A2 Lite, Motorola, HMD Global Nokia).
Cursor cursor = getContentResolver().query(MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, null, null, null, null);
Should I be passing a different URI for Android 10 devices ?. (However it is working fine in most of the devices )
Stack trace :
Caused by java.lang.IllegalArgumentException: Volume external_primary not found
at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:170)
at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:140)
at android.content.ContentProviderProxy.query(ContentProviderProxy.java:423)
at android.content.ContentResolver.query(ContentResolver.java:946)
at android.content.ContentResolver.query(ContentResolver.java:881)
at android.content.ContentResolver.query(ContentResolver.java:837)
at com.example.musicplayer.CursorFactory.getAllSongsCursor(CursorFactory.java:164)
Edit : Based on this issue reported, Suspect it could be an issue with sdcard in those devices with Android 10 OS.

Post Android 10, API 28, there are some changes when accessing the media content from other sources.
Google mentioned it in this link https://developer.android.com/training/data-storage/shared/media#storage-volume
You can get more information on how to resolve this issue with more information given by google with the below code:
// Add a specific media item.
ContentResolver resolver = getApplicationContext()
.getContentResolver();
// Find all audio files on the primary external storage device.
// On API <= 28, use VOLUME_EXTERNAL instead.
Uri audioCollection = MediaStore.Audio.Media.getContentUri(
MediaStore.VOLUME_EXTERNAL_PRIMARY);
// Publish a new song.
ContentValues newSongDetails = new ContentValues();
newSongDetails.put(MediaStore.Audio.Media.DISPLAY_NAME,
"My Song.mp3");
// Keeps a handle to the new song's URI in case we need to modify it
// later.
Uri myFavoriteSongUri = resolver
.insert(audioCollection, newSongDetails);
Hope this works for you!

Google added a thing called Scoped Storage which changes the File operation a bit. so you should use VOLUME_EXTERNAL/VOLUME_EXTERNAL_PRIMARY instead of EXTERNAL_CONTENT_URI
val uri =
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
MediaStore.Video.Media.getContentUri(MediaStore.VOLUME_EXTERNAL)
} else {
MediaStore.Video.Media.EXTERNAL_CONTENT_URI
}
Going with VOLUME_EXTERNAL/VOLUME_EXTERNAL_PRIMARY is the right direction but there is a really rare case that the user stores their audio file on SD card but the phone doesn't recognize it which leads to the crash. This is a device error and there is nothing you can do about it.
From the doc of https://developer.android.com/reference/android/provider/MediaStore#VOLUME_EXTERNAL_PRIMARY
you could use getExternalVolumeNames to check is there any external storage available before making the query.
https://developer.android.com/reference/android/provider/MediaStore#getExternalVolumeNames(android.content.Context)

You need to ask read permission for Android Q and above to access files outside of your application scope.
As per documentation mention as below and here is the documention link
If scoped storage is enabled, the collection shows only the photos, videos, and audio files that your app has created. Most developers won't need to use MediaStore.Files to view media files from other apps, but if you have a specific requirement to do so, you can declare the READ_EXTERNAL_STORAGE permission. It's recommended, however, that you use the MediaStore APIs to open files that your app hasn't created.
Here is the common code to ask permission for all version,
Declare the request launcher object
private val requestReadResult = registerForActivityResult(ActivityResultContracts.RequestPermission()) { result ->
if (result) {
queryData()
} else {
AlertDialog.Builder(this)
.setMessage(R.string.app_permission_required)
.setPositiveButton(R.string.exit) { _, _ -> finish() }.setCancelable(false).create().show()
}
}
Check permission granted or not before query
if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_EXTERNAL_STORAGE) == PackageManager.PERMISSION_DENIED) {
requestReadResult.launch(Manifest.permission.READ_EXTERNAL_STORAGE)
return
}
queryData()
Now check for the Android SDK version and as per that initialize your Uri
val uri= if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q)
MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)
else
MediaStore.Images.Media.EXTERNAL_CONTENT_URI
// Here you will getting all the Images from device.
val mediaCursor = contentResolver.query(uri, null, null, null, null)
As per your media requirement change MediaStore.yourmediatype and use it.
Thanks

Android 10: How to delete MediaStore item and it's associated data on file system programmatically?

I am updating my app to use Scoped Storage feature introduced in Android 10.
My app works with MediaStore and displays images, videos and audio files and provides ability for user to delete item.
What I did earlier to delete file:
Got path from MediaStore.MediaColumns.DATA
Used new File(path).delete() to delete that file
Manually updating MediaStore
Now that MediaStore.MediaColumns.DATA is not available I migrated to deleting items from MediaStore using ContentResolver.delete()
For example I have uri of the item: content://media/external/images/media/502 (its valid uri, I display it's thumbnail in grid). It doesnt matter whether I inserted this item in MediaStore or some other app did.
I use context.getContentResolver().delete(uri, null, null). It either succeeds in deletion (returns 1 row) or catching RecoverableSecurityException to use startIntentSenderForResult() to get access to current uri and then using the same getContentResolver().delete() to delete it in onActivityResult() and then getting successful deletion.
Either way that item is removed from MediaStore and is neither showing in result when I query MediaStore for images, nor in other applications.
BUT this file exists on file system (checked using SAF and various file managers (Google Files, Total Commander))
Sometimes (depends on Android version and media type) these items are brought back to MediaStore after phone reboot (or after opening Google Photos - it scans file system)
For example: Android 10 on my Google Pixel and Google Pixel 3a XL behaves as described above for Images/Video/Audio, but Android 9 on Xiaomi Mi A2 Lite behaves like this only with Audio files, while deleting Images/Video fine.
I have android:requestLegacyExternalStorage="false" in manifest.
Is there a way to force MediaStore to delete data on file system as well? Why is file on file system left behind?

Yes, as you have pointed out that's how we had to delete media files. We have to delete the physical copy of the file by forming a File object and also delete the indexed file in MediaStore using ContentResolver.delete() (or) do a media scan on the deleted file which would remove it's entry in MediaStore.
This is how it used to work in below Android 10 os. And would still work the same in Android 10 as well if you had opted out of scoped storage by specifying it in manifest android:requestLegacyExternalStorage="true"
Now in Android 11 you are forced to use scoped storage. If you want to delete any media file which is not created by you, you have to get the permission from the user. You can get the permission using MediaStore.createDeleteRequest(). This will show a dialog by description what operation users are about to perform, once the permission is granted, android has an internal code to take care of deleting both the physical file and the entry in MediaStore.
private void requestDeletePermission(List<Uri> uriList){
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.R) {
PendingIntent pi = MediaStore.createDeleteRequest(mActivity.getContentResolver(), uriList);
try {
startIntentSenderForResult(pi.getIntentSender(), REQUEST_PERM_DELETE, null, 0, 0,
0);
} catch (SendIntentException e) { }
}
}
The above code would do both, requesting the permission to delete, and once permission granted delete the files as well.
And the callback result you would get it in onActivityResult()

Use this function to delete file using display name of the file:
This func will delete MediaStore item and it's associated data on file system in Android-10 or Android-Q
Note: In my case I am working with files like MediaStore.Files.FileColumns..
public static boolean deleteFileUsingDisplayName(Context context, String displayName) {
Uri uri = getUriFromDisplayName(context, displayName);
if (uri != null) {
final ContentResolver resolver = context.getContentResolver();
String[] selectionArgsPdf = new String[]{displayName};
try {
resolver.delete(uri, MediaStore.Files.FileColumns.DISPLAY_NAME + "=?", selectionArgsPdf);
return true;
} catch (Exception ex) {
ex.printStackTrace();
// show some alert message
}
}
return false;
}
Use this function to get Uri from DisplayName
public static Uri getUriFromDisplayName(Context context, String displayName) {
String[] projection;
projection = new String[]{MediaStore.Files.FileColumns._ID};
// TODO This will break if we have no matching item in the MediaStore.
Cursor cursor = context.getContentResolver().query(extUri, projection,
MediaStore.Files.FileColumns.DISPLAY_NAME + " LIKE ?", new String[]{displayName}, null);
assert cursor != null;
cursor.moveToFirst();
if (cursor.getCount() > 0) {
int columnIndex = cursor.getColumnIndex(projection[0]);
long fileId = cursor.getLong(columnIndex);
cursor.close();
return Uri.parse(extUri.toString() + "/" + fileId);
} else {
return null;
}
}

According to my observations there is no force delete.
I usually add several checks if a file has really been deleted
on Android Q it is also not possible to delete an entire album without the user manually confirming each file. this makes deleting files on the device uninteresting for me

I'm also experiencing the same issue, but with Huawei models where it fails with image & video files.
I've found that there are some reported bugs about it, although Google have discarded 2 of them because they can't reproduce it.
I would advice that you star them and add some more details.
https://issuetracker.google.com/issues/157714528
https://issuetracker.google.com/issues/142270549
https://issuetracker.google.com/issues/145348304
Update:
I've created a new issue ticket, as some of the above have been discarded by google as not reproducible:
https://issuetracker.google.com/issues/184355104

I fixed this problem in my app for Android 10 by opting out of scoped storage (android:requestLegacyExternalStorage="true") and requesting WRITE_EXTERNAL_STORAGE for Android 10 as well:
<uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE"
android:maxSdkVersion="29"
tools:ignore="ScopedStorage" />
Then ContentResolver.delete will not trigger RecoverableSecurityException and will also delete the file from disk. Given you requested and was granted Manifest.permission.WRITE_EXTERNAL_STORAGE permission.
Note: If you don't care about deleting files not created by your app or created by previous installations of your app, then you don't need to request that permission.

API 29 Mediastore Access

My app creates playlists in the android mediastore. All is well for api's including 28 however, api 29 seems to require additional permissions.
Inserting a new playlist name and id works without issue. When it comes to inserting track id and play order, an access permission exception is thrown.
In verifying the Uri, i found that when resolver.insert for API 29 the exception error is:
java.lang.SecurityException: myapp_name has no access to content://media/external_primary/audio/media/146
The code:
Uri exturi = MediaStore.Audio.Playlists.Members.getContentUri("external", playlist_id);
// exturi : content://media/external/audio/playlists/227/members
// values : audio_id=146 play_order=0
values.put(MediaStore.Audio.Playlists.Members.PLAY_ORDER, play_order);
values.put(MediaStore.Audio.Playlists.Members.AUDIO_ID, audio_id);
try {
resolver.insert(exturi, values);
} catch (Exception e) {
e.printStackTrace();
}
Strange thing is that although inserting a new playlist into Mediastore works but adding tracks (track_id, play order) gives an access permission error
How to resolve this exception error for API 29?
Update Feb 2021:
a small step forward, I am pretty sure I need to get Documenturi for the original uri but still gives me the access error. So the issue does not lie with accessing the tracks but with the uri itself.
doc_uri = MediaStore.getDocumentUri(context,playlist_members_uri);
java.lang.SecurityException: com.flyingdutchman.newplaylistmanager has no access to content://media/external/audio/playlists/130/members

I think this is an Android 10 bug, so I've filed a report here: https://issuetracker.google.com/issues/147619577 (includes instructions for an emulator test case to reproduce it if that interests you). Please consider starring it to let the Android team know that it affects you.
From what I can tell, it only affects files on 'external' storage, like sdcards mounted on /storage/XXXX-XXXX
In the meantime, the only fix that some of my users were able to successfully apply is to move their music files to the internal storage (reboot and wait for the media scan to finish to be sure that MediaStore is up-to-date).

in my further research for the answer, I came across this;
All about the media database (Mediastore) with android 11

Create playlist with uri "MediaStore.Audio.Playlists.EXTERNAL_CONTENT_URI", and the date row in external.db for the playlist is:
_id
_display_name
volume_name
308
New playlist.m3u
external_primary
The playlist's volume name is "external_primary".
2.
Music file is under flash card
Music file's id in external.db is 278
The volume name of flash card is "1EDD-DDE0"
When add this music file to playlist, got below exception:
Exception message: java.lang.SecurityException: has no access to content://media/external_primary/audio/media/278
If I create playlist with uri MediaStore.Audio.Playlists.getContentUri("1edd-dde0"), then music can be successfully added to the playlist.
It seems that the reason is the mismatch of volume name between playlist and the music file to be added. Only when playlist's volume name is same to music file's, inserting operation can be complete.

Update for android 11.
Worth noting that the media database has moved from
/data/data/com.android.providers.media
to
/data/data/com.google.android.providers.media.module
also the structures have changes significantly
and

I came across the same issue. As the MediaProvider changes to Google's MediaProvider, the Scoped Storage feature is activated. When you try to modify a playlist file, but it's not created by your app (or it did be created by your app, but after OTA to new Android version, which changes to use Google's MediaProvider, it scans your playlist file and put a record to its database, but leaves the owner_package_name colume empty, it's a new colume, the old MediaProvider database has no owner_package_name colume, so no one could tell this playlist file was created by you), you will get a SecurityException says you have no access to this file.
You can check if the playlist file was owned by your app before doing the 'insert' operation:
Uri uri = MediaStore.Audio.Playlists.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY);
String[] projection = new String[] {
MediaStore.Audio.Playlists._ID,
MediaStore.Audio.Playlists.NAME,
MediaStore.Audio.Playlists.OWNER_PACKAGE_NAME,
};
String where = MediaStore.Audio.Playlists._ID + "=?";
String[] args = new String[] {playlistFileId};
Cursor cursor = resolver.query(uri, projection, where, args, null);
if (cursor != null) {
cursor.moveToFirst();
if (!cursor.isAfterLast()) {
String ownerPkg = cursor.getString(
cursor.getColumnIndex(MediaStore.Audio.Playlists.OWNER_PACKAGE_NAME));
// print ownerPkg here
}
}
If the owner package name of this playlist file is empty or other app's package name, that you probably have no access to write this playlist file due to the scoped storage feature limit.
According to this document, we can consider using MediaStore.createWriteRequest() method to prompt user to grant write permission to playlist file for our own app, but this request only available to certain kind of files, like images, audios, videos etc, but not for some other kinds like playlist files which ends in .m3u suffix.
Also, according to this, when you try to operate some image or audio files that's not created by your app in public storage, you will get a RecoverableSecurityException and you can use this exception to prompt user to get user consent to modify the file, but for playlist kind files, you will just get SecurityException instead of RecoverableSecurityException.
So the result is, you may never be able to access to that playlist file again, you can not modify it, and you can not delete it too. My solution is just create a new playlist file, so it's owned by my app, now I finally have full access to it. You may need to migrate your old playlist data to the new one.

AND FINALLY I FIND THIS
MediaStore.Audio.Playlists
This class was deprecated in API level 31.
Android playlists are now deprecated. We (Google) will keep the current functionality for compatibility resons, but we will no longer take feature request. We do not advise adding new usages of Android Playlists. M3U files can be used as an alternative.
In conclusion, no longer a relevant post

I have implemented the SAF so do not use scopedStorage and have access once the user accepts.
The fact that I can insert new playlist entries clearly shows access to MediaStore, I can also delete these. However trying to add tracks to these playlists does not work for api29. Inserting/deleting a new playlist does not involve any files located on internal or external sdcards as it is simply adding values.
the permissions for both internal and external sdcard:
2020-07-12 14:39:04.435 11858-11858/com.flyingdutchman.newplaylistmanager E/onCreate:: uriPermission: UriPermission {uri=content://com.android.externalstorage.documents/tree/17F5-240A%3A, modeFlags=3, persistedTime=1594551961263}
2020-07-12 14:39:04.435 11858-11858/com.flyingdutchman.newplaylistmanager E/onCreate:: uriPermission: UriPermission {uri=content://com.android.externalstorage.documents/tree/primary%3A, modeFlags=3, persistedTime=1594551926876}
The question now becomes
How do I ensure saf permissions are recognised by the resolver.insert method when inserting/modify tracks into the Media database

Update May 2020
Stepping through the resolver code with debug F7
Scenario 1 results in permission error (incorrect MediaStore.VOLUME_EXTERNAL).
playlist_uri = MediaStore.Audio.Playlists.getContentUri(MediaStore.VOLUME_EXTERNAL);
playlist_members_uri = MediaStore.Audio.Playlists.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)
.buildUpon()
.appendEncodedPath(Long.toString(playlist_id))
.appendEncodedPath("members")
.build();
acquireProvider(mContext, auth); = media
Uri createdRow = provider.insert(mPackageName, mAttributionTag, url, values, extras); = null
mPackageName=com.flyingdutchman.newplaylistmanager
mAttributionTag=null
values[0] = 206
values[1]=69
values[2]=1
extras=null
DatabaseUtils.java
public static final void readExceptionFromParcel(Parcel reply) {
int code = reply.readExceptionCode();
if (code == 0) return;
String msg = reply.readString();
DatabaseUtils.readExceptionFromParcel(reply, msg, code);
}
msg = com.flyingdutchman.newplaylistmanager has no access to content://media/external_primary/audio/playlists/206
Scenario 2 results in NO permission error BUT no tracks added to audio_playlists_map table.
playlist_uri = MediaStore.Audio.Playlists.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY);
url=content://media/external_primary/audio/playlists/206/members

How to request file deletion in Android Q for Not-Owned files

In Android Q, apps that aren't the default file manager or gallery can only modify and/or delete image files which they own, so, which an app has created.
Granting the read/write permissions doesn’t allow to modify or to delete any file that isn’t owned by an app.
This implies that not only files created by other apps are out of reach, but also if an app gets uninstalled and then reinstalled, then this one loses the ownership over all the public files that the app previously created. So, after the re-installation it can’t modify or delete them anymore.
When wanting to modify 1 image file or to delete a bulk of multiple images files, which were previously owned by an app, but lost ownership due to a re-installation, then what is the procedure to achieve such actions (delete or modify)?
The preferable solution would be not to use the SAF file picker, in the sense of avoid requesting to the user to select and grant a location through SAF.
And if the only solution is to use the SAF file picker, then how can be triggered to directly prompt to delete a set of known specific files without requesting tree access, neither having to tell the user to browse, search, and do it himself?

My final conclusions.
For APIs >= 29 is not possible to delete non-owned files without user interaction, and there is no way around this fact.
In Android 10/Q (API 29), a RecoverableSecurityException must be caught, then request the user permission, and finally if granted perform the deletion.
In Android 11/R (API 30) is greatly improved. Can delete in bulk even combining already owned files in the same batch. No need to handle anything after the request, the system takes care of the deletion if granted by the user.
The limitation is that it only handles media files (images, videos, audio). For other file types an IllegalArgumentException is thrown with the message: "All requested items must be referenced by specific ID", (check this message in MediaStore source code).
Note that in API 30 there is a new MANAGE_EXTERNAL_STORAGE permission, but its usage requires extra steps in the developer's console, such as to explain why the permission is needed.
Example:
public static void delete(final Activity activity, final Uri[] uriList, final int requestCode)
throws SecurityException, IntentSender.SendIntentException, IllegalArgumentException
{
final ContentResolver resolver = activity.getContentResolver();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R)
{
// WARNING: if the URI isn't a MediaStore Uri and specifically
// only for media files (images, videos, audio) then the request
// will throw an IllegalArgumentException, with the message:
// 'All requested items must be referenced by specific ID'
// No need to handle 'onActivityResult' callback, when the system returns
// from the user permission prompt the files will be already deleted.
// Multiple 'owned' and 'not-owned' files can be combined in the
// same batch request. The system will automatically delete them
// using the same prompt dialog, making the experience homogeneous.
final List<Uri> list = new ArrayList<>();
Collections.addAll(list, uriList);
final PendingIntent pendingIntent = MediaStore.createDeleteRequest(resolver, list);
activity.startIntentSenderForResult(pendingIntent.getIntentSender(), requestCode, null, 0, 0, 0, null);
}
else if (Build.VERSION.SDK_INT == Build.VERSION_CODES.Q)
{
try
{
// In Android == Q a RecoverableSecurityException is thrown for not-owned.
// For a batch request the deletion will stop at the failed not-owned
// file, so you may want to restrict deletion in Android Q to only
// 1 file at a time, to make the experience less ugly.
// Fortunately this gets solved in Android R.
for (final Uri uri : uriList)
{
resolver.delete(uri, null, null);
}
}
catch (RecoverableSecurityException ex)
{
final IntentSender intent = ex.getUserAction()
.getActionIntent()
.getIntentSender();
// IMPORTANT: still need to perform the actual deletion
// as usual, so again getContentResolver().delete(...),
// in your 'onActivityResult' callback, as in Android Q
// all this extra code is necessary 'only' to get the permission,
// as the system doesn't perform any actual deletion at all.
// The onActivityResult doesn't have the target Uri, so you
// need to cache it somewhere.
activity.startIntentSenderForResult(intent, requestCode, null, 0, 0, 0, null);
}
}
else
{
// As usual for older APIs
for (final Uri uri : uriList)
{
resolver.delete(uri, null, null);
}
}
}

what is the procedure to achieve such actions (delete or modify)?
AFAIK, your only option is to use the SAF and get rights that way.
The preferable solution would be not to use the SAF file picker, in the sense of avoid requesting to the user to select and grant a location through SAF.
That's not possible. It would be a security flaw if it were. Please understand that while you think that these are your files, from the OS' standpoint, they are just files on the device. If apps could get arbitrary modification access to arbitrary files, that would be a step backwards from the fairly insecure stuff we had previously.
how can be triggered to directly prompt to delete a set of known specific files
There is no delete-document or delete-tree UI option in SAF, though it's not a bad idea.
neither having to tell the user to browse, search, and do it himself?
That you might be able to work around. You can try this:
Step #1: Get a Uri for one of the MediaStore entries (e.g., use ContentUris and one of the IDs from a query() for your content)
Step #2: Use getDocumentUri() to transmogrify that MediaStore Uri into an SAF Uri pointing to the same content
Step #3: Put that SAF Uri as the EXTRA_INITIAL_URI value in an ACTION_OPEN_DOCUMENT_TREE Intent, and use that to try to pre-populate the tree picker to your content's directory
Step #4: Validate that the Uri you get back from ACTION_OPEN_DOCUMENT_TREE is the one you are expecting (it has your files, it matches the EXTRA_INITIAL_URI, or something along those lines)
At this point, you now can delete the files using DocumentFile.fromTreeUri() to get a DocumentFile for the tree, and from there list the files in the tree and delete them.
Whether the Uri that you get from Step #2 will work for EXTRA_INITIAL_URI in Step #3 is unclear, as I haven't tried this yet (though it's on my to-do list for early next week...).

To delete a Single file from the Media Store do something like this, if the file is not part of your app then an intent will start to get permission
val uri: String? = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI.toString()
val where = MediaStore.Audio.Media._ID + "=?"
val selectionArgs = arrayOf(mId)
try {
val deleted = mActivity.contentResolver.delete(Uri.parse(uri), where, selectionArgs)
return deleted >= 0
} catch (securityException: SecurityException) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
val recoverableSecurityException =
securityException as? RecoverableSecurityException
?: throw SecurityException()
val intentSender = recoverableSecurityException.userAction.actionIntent.intentSender
intentSender?.let {
mActivity.startIntentSenderForResult(intentSender, 0, null, 0, 0, 0, null)
}
} else {
throw SecurityException()
}
}
To add to the Media Store do something like this...
val values = ContentValues().apply {
put(MediaStore.Audio.Media.TITLE, song?.title)
put(MediaStore.MediaColumns.DISPLAY_NAME, song?.title)
put(MediaStore.Audio.Media.DATE_ADDED, System.currentTimeMillis())
put(MediaStore.Audio.Media.MIME_TYPE, song?.mimeType)
}
val resolver = mContext.contentResolver
val uri = resolver.insert(MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, values)
// Download file to Media Store
uri?.let { mUri ->
resolver.openOutputStream(mUri).use { mOutputStream ->
mOutputStream?.let {
// Download to output stream using the url we just created
}
}
}

How to force a MediaStore update for a file using only its Content Uri

In Android Q the field MediaStore.Files.FileColumns.DATA has been deprecated, and may be Null or apps have no rights to read it when targeting such OS version, so will be preferable to work using only a file’s content Uri.
Since the MediaScannerConnection only accepts file paths, I found that for Android Q this is no longer an option.
What would be the way to force an automatic MediaStore update/re-scan of a single file, without knowing its real path and using only its Uri? The intention is not to even try to find the real path and rely only in the Uri.
Consider that the Uri to force the update is a media content Uri (not a SAF Uri).
Example: content://media/external/images/media/123
The solution must not be to re-scan the entire storage or un-mount / mount the storage again, as this will have a high performance hit in our workflow and will make it completely unusable.
And because the intention is to use only the Uri, then to avoid forcing a scan of any specific directory of files, which would also have an impact if it contains lots of files, and implies that a real directory path must be resolved from the Uri, which is not an option.
UPDATE:
We have tried with unsuccessful results the ContentResolver.refresh method introduced in Android O, yet this method doesn't do any refresh at all when it comes to a media content Uri in a format such as: content://media/external/images/media/123
final ContentResolver resolver = context.getContentResolver();
resolver.refresh(uri, null, null);

I'm currently also trying to redesign my app to use just URIs rather than using all of the hacky solutions to convert them to filepaths (like guessing the path based on the uri authority, etc.) Previously, I used MediaScannerConnection.scanFile(...), which worked without a flaw, but as you've probably already tried, this doesn't work with URIs.
I am finding success by manually updating the MediaStore URI with my new data like this:
public void updateMediaStore(final Uri content, final String title) {
final ContentValues values = new ContentValues();
values.put(MediaStore.Audio.AudioColumns.TITLE, title);
// ... the rest of your data
cr.update(res, values, null, null);
}
Still, it seems like an oversight to not provide a way to rescan a specific file. For example, if this URI comes from somewhere else, such as on an sdcard via SAF, you will have to first search for it in the MediaStore before updating it.