As noted by the app now when you choose a custom file as your alarm sound, this can cause a crash when it attempts to play audio if the user picks the wrong thing, specifically if they try to use a playlist file (.m3u
) as their custom file. You can probably detect this crash right as they pick the file rather when it is attempted to be played but I don't care to try to. Or figure out the mime type and try to exclude it that way - but I have been very frustrated by many apps that expect all audio files to be mp3
s and would rather allow the user to figure it out than restrict them artificially.
There is also a crash which I'm not exactly sure how to reproduce which happened when I selected the same file multiple times in a row to be the new alarm. But it doesn't always happen, and once it works once it shouldn't break as it was related to saving the file I think.
Personally, I would still merge this because it is still a very good feature to have, people who use F-droid are probably okay with some small amount of jank in order to get (imo critical) features implemented faster, but if you want to not merge I don't care I wrote this for me. I probably also won't spend too much extra time trying to fix it if you decide this isn't good and won't fix it yourself.
Works by duplicating a file to local app storage, I didn't want to have to do that but it seems android's security model also prevents me from knowing any file paths even with storage permissions when using content API and I don't care to spend too much more time fighting with Android's weird APIs.
Only tested on android 13 so far. I'm not sure what would happen on an older version. I think pre-11 is when they changed some file APIs significantly.