fennifith / Alarmio

A simple alarm clock focused on design, readability, and internet radio.
https://play.google.com/store/apps/details?id=me.jfenn.alarmio
Apache License 2.0
332 stars 95 forks source link

Background image does not work #135

Open gary-host-laptop opened 3 years ago

gary-host-laptop commented 3 years ago

Device Info

Steps to Reproduce

Marmo commented 3 years ago

I think the error lies in the ImageUtils class. At least in my testing (Pixel 2 API 27 emulator) I got the following values: backgroundUrl (as in line 21): content://com.android.providers.downloads.documents/document/raw%3A%2Fstorage%2Femulated%2F0%2FDownload%2Fbackground.jpg path (as in line 28): raw:/storage/emulated/0/Download/background.jpg path (as in line 30): storage/raw//storage/emulated/0/Download/background.jpg

So that path (from which further down below the File object is created) does not exist, resulting in a black background.

I could fix the missing background by changing line 30 to: path = path.replaceFirst(".*:", "");

N.B.: I really have no idea, how the backgroundUrl from preferences or Uri.parse().getLastPathSegment() might behave differently on other devices/API versions. Does anyone around here know better than me?

fennifith commented 3 years ago

What I've gleaned from catching up on the documentation is that file paths should not be a requirement for media files, and what Alarmio is doing (trying to morph a content:// URI into a storage path) is not going to work for everything that can be returned by the file chooser.

The MediaStore documentation mentions that the DATA column (which is what Alarmio currently uses) should provide access to "an existing media file" - which may or may not remain available indefinitely. I believe the expected behavior is for applications to copy the returned files to their own storage directory - but it has been a while since I looked at any of this, and I don't exactly have a source for that (probably some obscure StackOverflow comment I'm recalling).

If anyone wants to try messing with the ContentResolver APIs in FileChooserActivity and checking what values they return from different sources, be my guest. Otherwise, I'll plan to reimplement it (in Kotlin) the next time I work on this.

Animyos commented 2 years ago

I think I found a workaround for this issue: Using the official Google files app (which opens automatically) picking an image does work.

See https://youtube.com/shorts/SXs-ljfjiMA?feature=share

Kind regards Animyos Fox