#open/readfile outside app dir?

24 messages · Page 1 of 1 (latest)

supple kelp
#

Is dialog + readfile for files outside of the app dir supported in android?
Opening a file works on desktop, but when I try it in android (from the downloads folder), I get the error:

Uncaught (in promise) failed to read file at path: content://com.android.providers.media.documents/document/document%3A1000017026 with error: No such file or directory (os error 2)

the code in question:
https://github.com/bpevs/multireader/blob/main/src-www/index.ts#L22-L23

const file = await open({ multiple: false, directory: false })
const contents: Uint8Array = await readFile(file.path)

I have the following permissions. I don't have any additional :

"dialog:allow-open",
"fs:read-files",
{
  "identifier": "fs:scope",
  "allow": [
    { "path": "**" },
    { "path": "$DOCUMENT/.*" },
    { "path": "$DOCUMENT/**/.*" }
  ],
  "deny": [{ "path": "/root" }]
}
GitHub
multireader/src-www/index.ts at main · bpevs/multireader

Contribute to bpevs/multireader development by creating an account on GitHub.

fading forum
supple kelp
#

100% this looks like the same problem. Thanks for the lead!

fading forum
#

The more I look into this, the more I realise we might just have to re-implement the FS API for Rust as well PepeHands

supple kelp
#

o sorry mebbe I have linked that in the other support thread instead of here? this discussion is in a few different places now heh

hallow remnant
# supple kelp Took a quick look at <#986184094050316358> discussion as well, and it looks like...

Yeah that's the PR I sent and it turns the content URI into a path instead. I initially tried getPath(), but when I checked it inside an Android environment, it didn't give me what I wanted.

I didn't git add the Android environment I made to test this, since plugins-workspace isn't my repo and I want to respect the project-owner's boundaries, but if you want i can make a publicly available example of it in my personal repo

supple kelp
#

@hallow remnant I mean if you have the time, that'd be amazing! Or even if you could just lmk if you're doing anything different in your calling code; I just tried to load dialog from a copied-down version of your change, but I'm still getting the contentURI, so I'm prooooobably doing something wrong.

hallow remnant
#

Did you change the Kotlin files accordingly too?

#

Changing that and referring to a local copy of the changed dialog plugin in your Cargo.toml (instead of the stable version) should do the trick

supple kelp
#

owait jk it's not a contentURI; some of them are "null" (files in Documents). But it looks like some files are being returned (files in Downloads). But I don't have those scoped. gimme a sec.

#

owait.... uhhhh... failed to read file at path: /storage/emulated/0/Download/pg2000-images-3.epub with error: Permission denied (os error 13)

Is this what icb meant about changes to fs? 😬 Were you able to read these files? Or is that a separate issue to be looked into?

hallow remnant
#

No i haven't attempted it yet since i haven't implemented support for images yet in my personal app

#

So the permission is denied? At this point then we would need to find a way to grant permission access to the file. Okay that looks like something I'll try to figure out in the next few days

supple kelp
#

seems so. But it does look like getting the url is working! Great work! All I've tried thus far is:

const file = await open()
const contents: Uint8Array = await readFile(file.path)

I haven't tried any plugin/android stuff as of yet, so I'll prolly be way slower than you. But I'll try and dabble a bit and see if I can't figure it out a bit as well.

hallow remnant
#

Ahaha thanks! Also I really appreciate it if another person's willing to help me solve this for us too regardless of anyone's ability or anything, thanks a lot!

dense gulch
#

there's a thread in here where someone was able to return a file descriptor from the dialog plugin back to the Rust side, so the file could actually be read

#

I still didn't have time to investigate it though

hallow remnant
#

I have a bit of progress, although I can't confirm whether I'm correct yet or not.

So, according to this reference, you need to declare the following in AndroidManifest.xml:

<!-- Required only if your app needs to access images or photos
     that other apps created. -->
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />

<!-- Required only if your app needs to access videos
     that other apps created. -->
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />

<!-- Required only if your app needs to access audio files
     that other apps created. -->
<uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />

<!-- For Android versions 9 or lower -->
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
                 android:maxSdkVersion="29" />

After having a look around, I found that the AndroidManifest.xml is in:

src-tauri\gen\android\app\build\intermediates\packaged_manifests\x86_64Debug\

for me, which means it's part of the auto-generated content.

I was trying to add these two, since they seem to be the main ones:

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
                 android:maxSdkVersion="29" />

But running pnpm tauri android dev re-generates this file, which means those permissions that I added just go away

Android Developers
Access media files from shared storage  |  Android Developers
#

Is there any way I can tinker with the gen/android autogeneration to see if this solves the issue? Should I ask in #contributing ?

fading forum
hallow remnant
#

I think I found the file that might need to be changed. I'm unsure how the WG would want to change it though. Should I submit a pull request with this file modified, or would TWG prefer handling it another way?

fading forum
#

Feel free to create a PR. If it's not ready to be merged, mark it as a draft.