Skip to content
This repository has been archived by the owner on Oct 26, 2023. It is now read-only.

Background image does not work #135

Open
gary-host-laptop opened this issue Jul 20, 2020 · 3 comments · Fixed by #152
Open

Background image does not work #135

gary-host-laptop opened this issue Jul 20, 2020 · 3 comments · Fixed by #152
Labels

Comments

@gary-host-laptop
Copy link

Device Info

  • Brand: Samsung
  • Model name: Galaxy J7 SM-J700M
  • Android version: Stock, 5.1.1.

Steps to Reproduce

  • Go to settings
  • Click on "Background Image"
  • Choose an image
  • Go to anywhere on the app where an image should be displayed
  • Image not visible
@fennifith fennifith added the bug label Dec 8, 2020
@Marmo
Copy link

Marmo commented Mar 7, 2021

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
Copy link
Owner

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
Copy link

Animyos commented Dec 8, 2021

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants