Develop Reference

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.

Media scanner for secondary storage on Android Q

With the newer Android Q many things changed, especially with scoped storage and gradual deprecation of file:/// URIs. The problem is the lack of documentation on how to handle media files correctly on Android Q devices.
I have a media file (audio) management application and I could not find yet a reliable way to tell to the OS that I performed a change to a file so that it can update its MediaStore record.
Option #1: MediaScannerService
MediaScannerConnection.scanFile(context, new String[]{ filePath }, new String[]{"audio/*"}, new MediaScannerConnection.OnScanCompletedListener() {
#Override
public void onScanCompleted(String s, Uri uri) {
}
});
Works with file:// URIs from primary storage
Not works with file:// URIs from secondary storage (such as removable storage)
Not works with any content:// URI
Option #2: broadcast
context.sendBroadcast(new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE, uri));
Not working at all
Soon deprecated
Option #3: manual MediaStore insertion
AudioFileContentValues are some column values from MediaStore.Audio.AudioColumns.
Old method based on file:// URI:
Uri uri = MediaStore.Audio.Media.getContentUriForPath(file_path);
newUri = context.getContentResolver().insert(uri, AudioFileContentValues);
MediaStore.Audio.Media.getContentUriForPath is deprecated
Still not working
Newer method based on what I could put together from documentation:
Uri collection = MediaStore.Audio.Media.getContentUri(correctVolume);
newUri = context.getContentResolver().insert(collection, AudioFileContentValues);
Where correctVolume would be external from primary storage, while it would be something like 0000-0000 for secondary storage, depending on where the file is located.
Insertion returns a content URI such as content://media/external/audio/media/125 but then no record is persisted inside MediaStore for files located in primary storage
Insertion fails with no URI returned and no record in MediaStore
These are more or less all the methods available in previous Android versions but none of them now allow me to notify the system that I changed some audio file metadata and to get Android to update MediaStore records. Event though option #1 is partially working, this could never be a valuable solution because it's clearly not supporting content URIs.
Is there any reliable way to trigger media scan on Android Q, despite where the file is located? We shouldn't even care about file location, according to Google, since we will soon only use content URIs. MediaStore has always been a little frustrating in my opinion, but now the situation is pretty worse.

I'm also currently struggling with that.
I think what you want to do you cannot do any longer once you are on Android Q, because you are not allowed to access the Music directory on Q. You are only allowed to create and access files in directories you created. You did not create the music directory.
Now every change to the Media has to happen threw the MediaStore. So you insert your Music file beforehand and then get an outputstream from the MediaStore to write to it. All the changes on Q on Media should be done threw the MediaStore hence you informing the MediaStore of changes cannot even occur anymore, because you never directly access the File.
This has one giant caviat in that all the new things in MediaStore that make that possible do not exist in older versions of Android. So I do currently believe that you will need to implement everything twice, sadly. At least if you want to actively influences where your music is saved to that is.
Those two MediaStore columns are new in Q and do not exist before Q, witch you'll probably need to use in Q
MediaStore.Audio.Media.RELATIVE_PATH with that you can influence the path where it's saved. So I put "Music/MyAppName/MyLibraryName" there and that will end up saving "song.mp3" into "Music/MyAppName/MyLibraryName/song.mp3"
MediaStore.Audio.Media.IS_PENDING this you should be setting to 1 while the song is still being written and then afterwards you can update it to 0.
I've also now started to implement things twice with if checks for Android versions. It's annoying. I don't want to do it. But it seems like that's the only way.
I'm just gonna put a bit of code here on how I managed inserting music on Android.Q and below. It's not perfect. I have to specify the MIME type for Q, because flacs would now become .flac.mp3 somehow, because it does not quite seem to get that.
So, anyways this is a part that I have updated already to work with Q and before, it downloads a Music file from a music player on my NAS. The app is written in kotlin, not sure if that's a problem for you.
override fun execute(library : Library, remoteApi: RemoteApi, ctx: Context) : Boolean {
var success = false
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
val values = ContentValues().apply {
put(MediaStore.Audio.Media.RELATIVE_PATH, library.rootFolderRelativePath)
put(MediaStore.Audio.Media.DISPLAY_NAME, remoteLibraryEntry.getFilename())
put(MediaStore.Audio.Media.IS_PENDING, 1)
}
val collection = MediaStore.Audio.Media
.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)
val uri = ctx.contentResolver.insert(collection, values)
ctx.contentResolver.openOutputStream(uri!!).use {
success = remoteApi.downloadMusic(remoteLibraryEntry, it!!)
}
if(success) {
values.clear()
val songId = JDrop.mediaHelper.getSongId(uri)
JDrop.db.music.insert(Music(mediaStoreId = songId, remoteId = remoteLibraryEntry.remoteId, libraryId = library.id))
values.put(MediaStore.Audio.Media.IS_PENDING, 0)
ctx.contentResolver.update(uri, values, null, null)
} else {
ctx.contentResolver.delete(uri, null, null)
}
} else {
val file = File("${library.rootFolderPublicDirectory}/${remoteLibraryEntry.getFilename()}")
if(file.exists()) file.delete()
success = remoteApi.downloadMusic(remoteLibraryEntry, file.outputStream())
if (success) {
MediaScannerConnection.scanFile(ctx, arrayOf(file.path), arrayOf("audio/*")) { _, uri ->
val songId = JDrop.mediaHelper.getSongId(uri)
JDrop.db.music.insert(Music(mediaStoreId = songId, remoteId = remoteLibraryEntry.remoteId, libraryId = library.id))
}
}
}
return success
}
And the MediaStoreHelper Method being this here
fun getSongId(uri : Uri) : Long {
val cursor = resolver.query(uri, arrayOf(Media._ID), null, null, null)
return if(cursor != null && cursor.moveToNext()) {
val idIndex = cursor.getColumnIndex(Media._ID)
val id = cursor.getLong(idIndex)
cursor.close()
id
} else {
cursor?.close()
-1
}
}
One thing when you do not specify the MIME type it seems to assume mp3 is the MIME type. So .flac files would get saved as name.flac.mp3, because it adds the mp3 file type if there is none and it thinks it's a mp3. It does not add another .mp3 for mp3 files. I don't currently have the MIME type anywhere... so I'm gonna go ahead and do this now, I guess.
There is also a helpful google IO talk about scoped/shared storage https://youtu.be/3EtBw5s9iRY
That probably won't answer all of your questions. It sure enough didn't for me. But it was a helpful start to have a rough idea what they even did change to begin with.
For deleting and updating files its kinda the same on Q if you call delete on a mediastore entry, the file will be deleted. Before, Q you have to manually delete the file also. But if you do that on Q your app will crash. So again you have to check wether or not youre on Q or an older version of android and take appropriate actions.

How to write file into DCIM directory exactly where camera does?

Suppose I am writing an alternative Camera application and wish to write images exactly into the same place as Camera does and name them exactly in the same name Camera does.
How would I accomplish this?
How to know the location of camera files?
How to know current naming convention?
How to gain permissions to that directory?
Any of answer would be appreciated.
Okay, suppose it is not really camera alternative. Suppose I would like to write formats other than images, like audio, video, or something else.

How would I accomplish this?
Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DCIM) + File.separator + "You Dir. Name";
if you append any string to end this
Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DCIM)
it will create dir inside the folder
How to know the location of camera files?
By default camera uses this location
Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DCIM)
How to know current naming convention?
IMG_yyyyMMDD_timeStamp
How to gain permissions to that directory?
Using permission manager for Camera and External Storage permissions

You cannot write exactly into the same folder as the default camera app does. But you can make use of Environment.getExternalStoragePublicDirectory(Environment.DI‌​‌RECTORY_DCIM)
mediaStorageDir = new File(Environment.getExternalStorageDirectory(), FOLDER_NAME);
Intent takePictureFromCameraIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
takePictureFromCameraIntent.putExtra(android.provider.MediaStore.EXTRA_OUTPUT,
Uri.fromFile(mediaStorageDir));
startActivityForResult(takePictureFromCameraIntent, 100);
But, please note that this will create only a sub-folder in the DCIM directory and will not store exactly where the default camera does. But you can always create sub-folders with your required folder name.

Things to keep in mind for this answer:
Every phone producer creates it's own Camera App, tailored to their hardware.
With the right permissions, App's can write (almost) everywhere they want...
Now to your question(s):
First, we don't know where the photo's are stored, and what the naming convention is. Every one and their mother has a different idea about what is best. So no "Hey it's always there".
Those who seek will find: get read & write permissions for the whole device. With that search the whole device to find in what folders the images are in. Now subtract the folders that come from "social media". My guess would be that the folder with the most and or latest images is the one that you want. To be sure, you will need testers, that trust you.
All that are found were not unorganized: just find the pattern used. There may be a standard for this. The big companies will surely have one. You can ask the device what maker it has. Note, that that answer might not be correct.
Ain't that a picture, no, it's a photo: And then you get the fun part of accessing the camera. Good times. Remember: request picture => get location of picture in memory => save picture as file. Best part, there is no enforcement of all parts of this API, so different devices need different instructions...
Have fun & Good luck!
ps, the downvotes are probably for the lack of code

Try using this code you can save the image bitmap to the directory using insert query
String imgSaved = MediaStore.Images.Media.insertImage(
getContentResolver(), bitmap,
System.currentTimeMillis() + ".jpg", "DESCRIPTION HERE");
For more details see the link

I've found this code useful for choosing the last used DCIM/Camera folder.
String getDCIMCamera() {
try {
String[] projection = new String[]{
MediaStore.Images.ImageColumns._ID,
MediaStore.Images.ImageColumns.DATA,
MediaStore.Images.ImageColumns.BUCKET_DISPLAY_NAME,
MediaStore.Images.ImageColumns.DATE_TAKEN,
MediaStore.Images.ImageColumns.MIME_TYPE};
Cursor cursor = getContentResolver().query(
MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
projection,
null,
null,
MediaStore.Images.ImageColumns.DATE_TAKEN + " DESC");
if (cursor != null) {
cursor.moveToFirst();
do {
String path = cursor.getString(cursor.getColumnIndex(MediaStore.Images.Media.DATA));
if (path.contains("/DCIM/")) {
File file = new File(path);
path = file.getParent();
cursor.close();
return path;
}
} while (cursor.moveToNext());
cursor.close();
}
}
catch (Exception e) {
}
return "";
}

java.io.File and new Lollipop SDCard Access API can't work together?

I've followed this How to use the new SD card access API presented for Android 5.0 (Lollipop)? but still not satisfy my problem.
My application is almost similar to ES Explorer, where it will display all files to edit. When user finish editing the file, it will save the changes through this call OtherPartyImageSaver.save(File f, Metadata updatedMetadata)
I tried the following, but failed:
Uri treeUri = resultData.getData();
DocumentFile pickedDir = DocumentFile.fromTreeUri(this, treeUri);
OtherPartyImageSaver.save(new File("/storage/sdcard/Download/hello.jpg"),
updatedMetadata);
This class doesn't work with OutputStream.
Do I have to give up on OtherPartyImageSaver or is there any way to achieve this?
If I have to give up with the library, can Uri from other provider be granted for modification?
Uri mediaUri = Uri.withAppendedPath(MediaStore.Audio.Media.EXTERNAL_CONTENT_URI,
"45");
Because the Uri _ID is retrieved by querying database.

Do I have to give up on OtherPartyImageSaver
If it only works with File, and you want to support removable storage, then either you will have to give up on OtherPartyImageSaver, or you will have to modify it to support streams (if the class is open source).

Retrieve file path from caught DownloadManager intent

Since Android 4.2 if a user downloads some file in the browser the DownloadManager is used. If the user clicks the 'download complete' notification an Intent is and was always launched. Before Android 4.2 the intent used to have the downloaded file's path in the content, such that:
intent.getData()
would return a String such as file:///storage/emulated/0/Download/some_file.ext. However, since Android 4.2 the download manager broadcasts and intent with a content scheme, such as content://downloads/all_downloads/2334.
How do I retrieve the local file path for a downloaded file?
I've tried the following:
public static String getRealPathFromURI(Uri contentUri, Activity activity) {
DownloadManager downloadManager = (DownloadManager) activity.getSystemService(Activity.DOWNLOAD_SERVICE);
String[] contentParts = contentUri.getEncodedPath().split("/");
Cursor q = downloadManager.query(new DownloadManager.Query().setFilterById(Integer.parseInt(contentParts[contentParts.length - 1])));
if (q == null) {
// Download no longer exists
return null;
}
q.moveToFirst();
return q.getString(q.getColumnIndex(DownloadManager.COLUMN_LOCAL_FILENAME));
}
But the cursor never returns any rows (so q.getCount() == 0 and therefor the last return statement throws an exception). Also, the hack by parsing the download file id from the Uri seems odd.
UPDATE: I have also tried:
input = getActivity().getContentResolver().openInputStream(contentUri);
but this returns an error stating
Permission Denial: reading com.android.providers.downloads.DownloadProvider uri content://downloads/all_downloads/2334 from pid=30950, uid=10064 requires android.permission.ACCESS_ALL_DOWNLOADS, or grantUriPermission()
Clearly I can't access the downloads (as my app did not initiate them - the browser did) through the ContentProvider.

Here's what worked. First, you can't (and shouldn't want to) get the file path as botteaap correctly pointed out. (Credits to him for setting me on the right path.) Instead you get a temporary permission automatically to access the file content, using:
InputStream input = getContentResolver().openInputStream(intent.getData());
You can read this InputStream like any other in Java. It seems there is no way to get the file name. If you need a file, first write the input stream to a (temporary) file.
The SecurityException is throw when your temporary access was revoked. This happend for me on some files that I tried to read incorrectly before and specifically when the Intent was picked up in my Acticity's onNewIntent.

Getting it through the content resolver is the right thing. Not every content url is going to be a file. For example, the Gallery app will give you uri's that translate to a network call or a local file depending on the source.
Even if you'd get to the real file path, you'll probably unable to read it, due to file permissions, although you can be lucky it it's on external storage. Have you tried adding android.permission.ACCESS_ALL_DOWNLOADS to your app like the exception suggests? That won't work, since the permission is at signature level :(

I just want to add to the answer from #erickok as it took me several hours to figure this out. As stated by #jcesarmobile, you are only guaranteed to be able to get the name and size of the file, not the full path.
You can get the name and size as follows, and then save to a temp file:
String filename = null;
Long filesize = null;
Cursor cursor = null;
try {
cursor = this.getContentResolver().query(intent.getData(), new String[] {
OpenableColumns.DISPLAY_NAME, OpenableColumns.SIZE}, null, null, null );
if (cursor != null && cursor.moveToFirst()) {
filename = cursor.getString(0);
filesize = cursor.getLong(1);
}
} finally {
if (cursor != null)
cursor.close();
}