Where was my received file saved to? It wasn't in downloads, and browsing around I couldn't find it. If you're not going to put it in Downloads, it would be great if a configuration option was available to specify the download location. Otherwise, great app!

I've reported this issue also using "send feedback" on my Android phone. It's a Sony Xperia F5321 phone with Android 8.0.0. Version 1.0.6 works, but 1.0.7 crashes as soon as you launch it. I will try to send the "adb logcat" output once I figure out how to do that.

I was trying to use this Android tool to send a file to my Linux laptop and I'm pretty sure it's corrupting the transfer.

I have a 2,693,769 byte binary file (tgz file) that on the other side of the wormhole ends up with an extra 375 bytes of seeming garbage at the end. I tried slicing that suffix off and passing it to the Linux "file" command and it doesn't have a detected structure.

I'm wondering if there's a uninitialized buffer read or incorrectly sized buffer involved?

Currently the application is inaccessible to screen readers like TalkBack.

I believe this is a current limitation with Gio. I'll check with them on where accessibility features fall on their roadmap.

Every time I receive a transferred file the app crashes and I see the following error in the logs:

java.lang.SecurityException: Unsupported path /storage/emulated/0/Download/<redacted filename>

Environment: v1.0.3 from the GitHub release on LineageOS 17.1 (Android 10) on a Sony Xperia XZ1C

I've also seen the app crash in the same way on a Pixel 2 running stock Android 10 but can't check the logs to verify it's the same crash (but it looks like it).

On both devices the app didn't ask for any permissions. Newer Android versions have locked down writing to the SD card more tightly so the app might need to request the storage permission in order to work. See https://developer.android.com/training/data-storage

I think two small changes would greatly improve usability of receiving files:

1. Make the code field a regular text box to allow swipe-typing and autocomplete. The words are all dictionary words, so this would greatly speed up entry. Even if making the change would get rid of the number bar, I think it would still be a net improvement since there's only one digit but two full words to type in the default codes.
2. Allow typing spaces instead of dashes, and just replace spaces by dashes before using the code. Typing a space is much easier than a dash on the android keyboard (in fact with swipe-typing you don't even need to explicitly type a space), and there's no reason to strictly require dashes.

https://github.com/psanford/wormhole-william/pull/37 adds support to generate QR Codes when sending a file. Add support for scanning a QR Code in the mobile app.

The format for the encoded string in that branch is wormhole:${RendezvousURL}?code=${code}

Thank you for making the app, very cool!

It would be lovely to have the app as a share target. So, you can for example share an image from a reddit app or the files app straight into this to send to another device without having to open it and browse to the file manually.

For android 10 we need requestLegacyExternalStorage and we need WRITE_EXTERNAL_STORAGE.

We now will prompt for WRITE_EXTERNAL_STORAGE after you click accept (if we don't already have it).

I'm not really sure why this works on android 11 but fails on android 10.

QR Codes can be generated from the wormwhole-william cli tool via the --qr flag.

The code embeds the relay url, but currently we are ignoring that and just using the relay set in the config.

This adds initial support for android the share intent. Instead of opening the app and choosing a file, you can share the file from a different app.

The implementation is a little awkward. Normally you would receive this intent in the main application activity. Gio owns that so we can't do that in this case. So instead we make a new activity that receives the event and then switches to the main activity.

Currently nothing prevents you from sharing from the UI and from a share intent concurrently. The UI doesn't support this at all so the first action will just disappear (although the messages will probably get messed up).

We should add proper state management for this.

Fixes: #2

If i see it correctly, you use another uri-scheme than and you asked for the uri-scheme to be standardized https://github.com/magic-wormhole/magic-wormhole-protocols/issues/3. And it got standardized in https://github.com/magic-wormhole/magic-wormhole-protocols/pull/21.

Is there a specific reason, that your uri is different than the standard?

This implements #28. I've done no testing on mobile, but:

1. It uses a QR library from rsc, which has no C dependencies
2. It works running the patched app on my laptop, generating QR codes, and receiving (by scannang the codes) from the wormhole-william-mobile app on my phone
3. I have no reason to expect -- given the simplicity of my changes, and of rsc's QR library -- that it won't work once it's on a mobile device

The QR codes are small, but they scan, and it works as-is. I don't have the Android SDK currently installed on my laptop because it's enormous.

Anyhoo, you said you'd be happy to have a patch for #28, so here it is.

Firstly: wonderful tool—thank you!

I ran into an issue wherein the Android (Pixel 2 XL, Android 11) app. will crash when receiving a file with a : in the filename.

• using magic-wormhole==0.12.0 on a Linux machine.
• run wormhole send <filename_with_colon> and copy the code.
• enter code into the Android app. and acknowledge receipt.
• download progresses for the full duration but the app. crashes (no errors, just closes) on completion.

My assumption is that it's something to do with the restricted range of characters on the Android end.

Removing the : from the filename and retrying fixes the issue and it can be received without issue.

Wormhole William mobile can scan a QR code to receive a file; the complimentary function is to render a QR code for a share that another instance of Wormhole William can scan to receive.

All of the text input fields in the app seem to break when I try to input a string matching [0-9]+-[a-z]+. For instance, if i start typing 1-a, the a never appears in the text box, all I can type is 1-. This is obviously especially problematic for the recv code field, but the send text field has the same issue.

I'm using version 1.0.8 on a Pixel 3a running LineageOS 18.1.

IME support has been added to gio for android: https://lists.sr.ht/~eliasnaur/gio/%3CCAFcc3FSWbqzHkWpzsOBLD9J3GmDgD5S6wO6ZqVoRKLq41GkObQ%40mail.gmail.com%3E

We should be able to use this to auto-complete words from the standard wormhole dictionary.