Creating an M3U file with Avalonia cross-platform (Windows and Android)


I cannot get my head around this and Google hasn't given me the right answer either (or it is so plain obvious that I keep missing it).

I'm trying to create an M3U file of music files on the system in an Avalonia cross-platform app. On desktop (Windows) that's easy enough, write the paths to the files into an M3U file and open it in for example VLC to play it. On Android however, I get the content:// URIs, which don't work in M3U on Android. Checking how VLC does it when saving a playlist, it actually stores ///storage/emulated/0/... files (the actual paths to the files), which VLC is happy to play (as long as the files exist and VLC has the permissions to read of course).

I have tried every method of IStorageItem, IStorageProvider, IStorageBookmarkItem, but no conversion exists from one to the other.

How to go about this, do I need to somehow convert the content:// URIs to ///storage URIs? Using native Android functions maybe? Or am I thinking in the wrong direction?

So:

var files = await storageProvider.OpenFilePickerAsync(new FilePickerOpenOptions {
    Title = title,
    AllowMultiple = false,
    FileTypeFilter = fileTypes,
    SuggestedFileType = suggestedFileType,
    SuggestedFileName = suggestedFilename,
    SuggestedStartLocation = storageFolder,
});

gives me files[0], which is an IStorageFile instance, which on Android is a content:// URI when I pick a music file. That I like to convert to an actual file path on Android, if that is the correct way to do this.

0
Apr 26 at 5:30 PM
User AvatarDaap
#c##android#avalonia

Accepted Answer

> it does if the user picks the existing music file with a file picker first

I do not know what you consider the "file picker" to be. If you are referring to something like ACTION_OPEN_DOCUMENT / ActivityResultContracts.OpenDocument, that is not limited to files on the device, let alone files that you can access via the filesystem. Various cloud providers support having their documents available via this system, for example, as do various encrypted document stores.

If you want to limit yourself to files that arbitrary apps like yours should be able to access on the filesystem, build yourself an actual file picker. In that case, you will not encounter Uri objects.

User AvatarCommonsWare
Apr 26 at 11:02 PM
1