I used below query to load all pictures or video from sd card and it works accordingly. But when I add some video or pictures manually into sd card at different folder then its not loading after query. Please suggest me regarding same.
final String[] columns = { MediaStore.Video.Media.DATA,
MediaStore.Video.Media._ID};
final String orderBy = MediaStore.Video.Media.DATE_TAKEN;
Uri videosuri = MediaStore.Video.Media.EXTERNAL_CONTENT_URI;
Cursor imagecursor = getContentResolver().query(videosuri, columns, null, null, orderBy);
if (imagecursor != null && imagecursor.getCount() > 0) {
while (imagecursor.moveToNext()) {
int video_id=imagecursor.getInt(imagecursor.getColumnIndex(MediaStore.Video.Media._ID));
int dataColumnIndex = imagecursor.getColumnIndex(MediaStore.Video.Media.DATA);
String path=imagecursor.getString(dataColumnIndex);
}
}
When you "add some video or pictures manually into sd card at different folder", the MediaStore has to be updated in order for them to be available to your query, as well as to other apps that use the MediaStore backend.
Adding them via MTP or apps like Gallery will invoke the MediaScanner (or some similar process) to add them to the MediaStore, but adding them via adb push or in your own code requires you to explicitly do so afterward.
In your code, after writing an image or video file to the SDCard, you can pass the path and MIME type of the file to the MediaScanner by implementing the MediaScannerConnectionClient interface in a class, instantiating it, then calling scan(). The MediaScanner will then open the file, collect/generate metadata, and add the file to the MediaStore
See android - dynamically add pictures to gallery widget for an example class using this approach.
Related
The main idea of the question is just same as the title - what is the difference between .getPath() vs cursor, when you get the real path of a file from uri in Android?
In case you don't get what I meant by using cursor, the example is here.
private String getRealPathFromURI(Uri contentURI) {
String result;
Cursor cursor = getContentResolver().query(contentURI, null, null, null, null);
if (cursor == null) { // Source is Dropbox or other similar local file path
result = contentURI.getPath();
} else {
cursor.moveToFirst();
int idx = cursor.getColumnIndex(MediaStore.Images.ImageColumns.DATA);
result = cursor.getString(idx);
cursor.close();
}
return result;
}
The two most frequent ways were these two, but it seems a bit too complicated using cursor, while you can get the same result with one simple method, .getPath(). So, I think there must be the reason I should use the cursor in some cases, but I can't get it.
Could you explain me what it would be?
what is the difference between .getPath() vs cursor, when you get the real path of a file from uri in Android?
A Uri is not a file. There is no "real path".
If the scheme of the Uri is file, then it represents a file on the filesystem that, in theory, your app should be able to access. Use getPath() to get the filesystem path.
If the scheme is anything else, it does not necessarily represent a file on the filesystem that your app can access. For example, if the scheme is http or https, the Uri represents something that would be downloaded from a Web server.
If the scheme is content, then it is backed by a ContentProvider. Use a ContentResolver and openInputStream() to get an InputStream on the content identified by the Uri.
If the scheme is content and you specifically obtained the Uri from the MediaStore, then perhaps your Cursor approach will give you a path. It also might give you null, and the path that you get may not be accessible to you (just because the system's MediaStore can index a file does not imply that your app has access to that same file). This is worse on Android 10, where you do not have read access to external storage by default. Hence, this technique is unreliable and should not be used.
Beyond that, though, you cannot make any assumptions about what data is used to support that content Uri. It could be:
A local file on external storage
A local file on internal storage for the other app (e.g., served by FileProvider)
A local file on removable storage
A local file that is encrypted and needs to be decrypted on the fly by the ContentProvider
A stream of bytes held in a BLOB column in a database that needs to be served by the ContentProvider
A piece of content that needs to be downloaded by the other app first (e.g., Dropbox)
...and so on
So, to recap: a Uri is not a file. There is no "real path".
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.
The main idea of the question is just same as the title - what is the difference between .getPath() vs cursor, when you get the real path of a file from uri in Android?
In case you don't get what I meant by using cursor, the example is here.
private String getRealPathFromURI(Uri contentURI) {
String result;
Cursor cursor = getContentResolver().query(contentURI, null, null, null, null);
if (cursor == null) { // Source is Dropbox or other similar local file path
result = contentURI.getPath();
} else {
cursor.moveToFirst();
int idx = cursor.getColumnIndex(MediaStore.Images.ImageColumns.DATA);
result = cursor.getString(idx);
cursor.close();
}
return result;
}
The two most frequent ways were these two, but it seems a bit too complicated using cursor, while you can get the same result with one simple method, .getPath(). So, I think there must be the reason I should use the cursor in some cases, but I can't get it.
Could you explain me what it would be?
what is the difference between .getPath() vs cursor, when you get the real path of a file from uri in Android?
A Uri is not a file. There is no "real path".
If the scheme of the Uri is file, then it represents a file on the filesystem that, in theory, your app should be able to access. Use getPath() to get the filesystem path.
If the scheme is anything else, it does not necessarily represent a file on the filesystem that your app can access. For example, if the scheme is http or https, the Uri represents something that would be downloaded from a Web server.
If the scheme is content, then it is backed by a ContentProvider. Use a ContentResolver and openInputStream() to get an InputStream on the content identified by the Uri.
If the scheme is content and you specifically obtained the Uri from the MediaStore, then perhaps your Cursor approach will give you a path. It also might give you null, and the path that you get may not be accessible to you (just because the system's MediaStore can index a file does not imply that your app has access to that same file). This is worse on Android 10, where you do not have read access to external storage by default. Hence, this technique is unreliable and should not be used.
Beyond that, though, you cannot make any assumptions about what data is used to support that content Uri. It could be:
A local file on external storage
A local file on internal storage for the other app (e.g., served by FileProvider)
A local file on removable storage
A local file that is encrypted and needs to be decrypted on the fly by the ContentProvider
A stream of bytes held in a BLOB column in a database that needs to be served by the ContentProvider
A piece of content that needs to be downloaded by the other app first (e.g., Dropbox)
...and so on
So, to recap: a Uri is not a file. There is no "real path".
I'm using the FileProvider pattern for creating content:// uri to files, with the
FileProvider.getUriForFile(this, "com.myapp.provider", file)
function. I have the manifest, provider_paths and everything set the standard way, It creates an uri like content://com.myapp.provider/external_files/music/mysong.mp3.
My issue is that if I try getting the real file path in another app, it doesn't work as the _data column doesn't exist (to be specific the error in logs is E/CursorWindow: Failed to read row 0, column -1 from a CursorWindow which has 1 rows, 0 columns.). For fetching the real path I'm using the also pretty much standard function
final String column = MediaStore.Files.FileColumns.DATA;
final String[] projection = { column };
try {
cursor = context.getContentResolver().query(uri, projection, null, null, null);
if (cursor != null && cursor.moveToFirst()) {
final int column_index = cursor.getColumnIndexOrThrow(column);
return cursor.getString(column_index);
}
} finally {
if (cursor != null)
cursor.close();
}
If I use a different app for sharing the same file it generates an uri like content://com.otherapp.provider/external_files/music/mysong.mp3, from which I can already retrieve the real file path. Any ideas what do I have to do to make sure that my app properly inserts the given uri to ContentResolver? Manual contentResolver.insert(...) functions are not allowed. I've tried different versions of provider_paths.xml and granting all possible read/write permissions to the given uri, but I could never retrieve the real path.
The uri itself generated by me works fine as I can read the file or play the song, my issue is just that I cannot retrieve the real file path that I need.
Thanks
My issue is that if I try getting the real file path in another app
The other app should not be trying to do this.
For fetching the real path I'm using the also pretty much standard function
That works for very few Uri values.
If I use a different app for sharing the same file it generates an uri like content://com.otherapp.provider/external_files/music/mysong.mp3, from which I can already retrieve the real file path.
That is not guaranteed.
Any ideas what do I have to do to make sure that my app properly inserts the given uri to ContentResolver?
You don't. You fix the client app, which should not be attempting to get a "real file path" from a Uri.
my issue is just that I cannot retrieve the real file path that I need.
Instead, for a Uri with a content scheme:
Step #1: Get a ContentResolver, by calling getContentResolver() on some Context (e.g., an activity)
Step #2: Call openInputStream() on the ContentResolver, passing in your Uri, to get an InputStream on that content
Step #3: Consume the content via that InputStream
If you are using some third-party library that can only work with files, copy the data from that InputStream to some FileOutputStream, then use the resulting file with that library.
This way, no matter where the content is coming from (a file that you could access, a file that you cannot access, a BLOB column in a database, etc.), you will have code that works.
See also:
Getting the Absolute File Path from Content URI for searched images
onActivityResult's intent.getPath() doesn't give me the correct filename
Android - Get real path of a .txt file selected from the file explorer
I am trying to display a list of albums (of music mp3s stored on the sd-card) along with the album art for each album. The album art is stored in the mp3s tag (it is not a separate image on the SD card)
I can get the album details fine using:
String[] projection = new String[] { Albums._ID, Albums.ALBUM, Albums.ARTIST, Albums.ALBUM_ART, Albums.NUMBER_OF_SONGS };
String rowsToReturn = null;
String[] selectionWhere = null;
String sortOrder = Media.ALBUM + " ASC";
Cursor cursor = contentResolver.query(Albums.EXTERNAL_CONTENT_URI, projection, rowsToReturn, selectionWhere, sortOrder);
String albumArtUri = cursor.getString(cursor.getColumnIndex(Albums.ALBUM_ART));
The URI is correct, but when I try to set the URi to the src of an ImageView, I get a silent error being thrown "resolveUri failed on bad bitmap uri".
imageview.setImageURI(Uri.parse(albumArtUri));
This only happens for some albums. Some are fine and display the album art correctly.
I took a look at the URI path and checked on the SD card for the thumbnail images and found them here: /mnt/sdcard/Android/data/com.android.providers.media/albumthumbs/
I found images that work and images that dont, so the image does exist, but just cannot be read correctly. I even tried copying the images off the sd card and adding .png extension to the files - the ones that show up on the phone work, but the ones that don't are 'corrupt'
Finally I copied the mp3 files themselves back to the PC and inspected the album art embedded in the tags and they all show correctly.
It's almost as if the thumbnails that the Android system is creating form the tags are invalid or corrupt, but this can't be right.
Or maybe I need to read them differently?
i think the issue could be with Media scanning. Delete the cache folder and open the music player app.It will create album cache again for all the songs. See if this helps.