Closed ghost closed 3 years ago
StickyDigit
commented
3 years ago I concur. Attempting to share from other apps (e.g. Gallery) via Warpinator-android leads to these clues on android 7:- Permission Denial reading ..blah blah.. Requires android permission.READ_EXTERNAL_STORAGE, or grantUriPermission() Similar on 10 and 11. Will drag out specific debug if helpful, but I'm sure the dev know what the above means, and how to fix it :)
slowscript
commented
3 years ago I have fixed all the issues with sharing I could find in ef32c4c. Let me know if it resolved your problem.
StickyDigit
commented
3 years ago Oddly. I couldn't get this to completely fail again on 1.0.2 or yesterdays build. I did find some problems though.
Perhaps something gets initiated after a few uses and the relevant Android magic slots into place. It absolutely failed as previously described on at least three devices I'd checked soon after first installation. I'm testing with the same devices (and more) today, using the same installs.
When I share from other apps, as warpinator gets focus it shows an overlaid text of "No available devices to share with", over the top of the functioning list of devices which are happy to function.
Across various Android versions, I found that Simple Gallery share button would lead to breakage at something over > 512KiB. They'd break at a 512KiB boundary, inconsistently. Sometimes at 512KiB, sometimes maybe 1.5MiB. The most recent file in my camera roll would send fine on it's own, but all other files would fail. Crazy!
Sending the same files via Ghost Commander seemed to work fine regardless. Ghost seems to use a slightly different share dialogue.
I've rolled a version from git just now. I'll throw some large files at my test Android 7 phone and check it fails in the same way before I upgrade, and then let you know if that fixes anything. I'll also check to see if I can find another app that uses the same sharing dialogue as Simple Gallery. I'll check some other share methods with Simple Gallery in case it's that which is b0rked too.
Building the new version throw these warnings, which may be from the recent language pulls. Will install as-is as these don't affect me, I've just included them for info.
app/build/intermediates/incremental/mergeReleaseResources/merged.dir/values-de/values-de.xml:110:
warn: multiple substitutions specified in non-positional format; did you mean to add the formatted="false" attribute?.
app/build/intermediates/incremental/mergeReleaseResources/merged.dir/values-pt-rBR/values-pt-rBR.xml:113:
warn: multiple substitutions specified in non-positional format; did you mean to add the formatted="false" attribute?.
app/build/intermediates/incremental/mergeReleaseResources/merged.dir/values-cs/values-cs.xml:106:
warn: multiple substitutions specified in non-positional format; did you mean to add the formatted="false" attribute?.
app/build/intermediates/incremental/mergeReleaseResources/merged.dir/values-ro/values-ro.xml:110:
warn: multiple substitutions specified in non-positional format; did you mean to add the formatted="false" attribute?.
app/build/intermediates/incremental/mergeReleaseResources/merged.dir/values/values.xml:1132:
warn: multiple substitutions specified in non-positional format; did you mean to add the formatted="false" attribute?.And these which I guess shouldn't worry me right now...
...
Task :app:compileReleaseJavaWithJavac Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details.
Task :app:stripReleaseDebugSymbols Unable to strip the following libraries, packaging them as they are: libconscrypt_jni.so. ...
Have to do some skin-side things. Will be back in about half an hour and test the version I just built.
StickyDigit
commented
3 years ago I checked my test droid... it's running android 7 (LineageOS). It failed in Simple Gallery. I updated Simple Gallery to the same version as my other droids and it still failed. The failed files appear to be broken at 512KiB boundaries. Some chunks of random data appear in numbered files sometimes too.
Ghost Commander batches were fine. So.. not all share dialogues are the same.
Installed the new build... It works. The files sent ok, and the overlay text is gone.
I'll check on a couple of other version droids after I've checked this with some larger things. At least I can just warp the package to them :)
One glitch that remains.. if you double tap the host to send, it appears to be sending two loads at once, slightly out of sync. Everything arrived ok the one time I did that.
StickyDigit
commented
3 years ago On my android 11, sending 5 files from Simple Gallery locked up after the first three. The Linux RX shows transfer failed and finished. The three files which sent are ok.
The sending notification shows 80.4% at the droid. It is not dismissible. The app shows the transfer as "Waiting for permission"
I'll FC it. This has happened on this droid 11 phone a few times. I can't seem to nail a cause.
Tried again and it worked. Sent another 7 images... all OK. Sent some to the app on Android 10, again OK.
Nice work. It's good on 7 and 11. If this resurfaces, or if you really want me to, I'll test on 5,7,9,10 and 11
StickyDigit
commented
3 years ago Caught that issue on the 11 again.
I re-opened the app and checked into the host that it had failed to send to before the FC. The previous files must have been queued still, as they tried to send again. There was a brief glitch in the Wi-Fi signal. The phone dropped to 4G and back to Wi-Fi again in about a second.
The send dialogue got stuck and another FC was needed. Perhaps some thought could be applied to how to better handle disconnects. I'd quite like to see it offer 'retry', perhaps optionally only when the original or preferred connection comes back. This could be an excuse to tie it to a specific interface, or SSID (or SSIDs).. just a thought. That may not be possible given the RX had called the transfer broken. Certainly the need to FC should be averted somehow.
After the FC I closed the shared from app, and Warpinator showed a clear list for the host it had been sending to.
StickyDigit
commented
3 years ago "Double tap sends as two lots at once thing" is repeatable. It may not actually be doing it, but it is disconcerting.
From e.g. Simple Gallery, tag a few images to make the transfer take a few seconds. Share to Warpinator. Double tap the target host.. enjoy watching it all happen in duplicate. I couldn't get a triple click to launch three.
StickyDigit
commented
3 years ago Ok.. so after watching the files seem to send twice and be RX'd once.. I zapped them from the RX end and hit "back" in the app. Clicked into the same host again, and it transferred the files again. Fun!!! Then.. I zapped the files the the RX again. Hit "back" in the app to return to the host list. Hit the host again. I started to send again. Ths time I was docmenting and put the phone down and it lost the WiFi for a moment so I'll have to FC. Seems there's some pathological behaviour there. Will attempt to reproduce on the Android 7.
StickyDigit
commented
3 years ago Ok. That's solid on Android 7 too. Open warpinator and let the hosts settle. Open Simple Gallery and tag a few megs of files. Share to Warpinator. Select host to send to. Wait for files to finish sending, go back to host list and back into the host.. files try to send again. Repeat as many times as you like. If you decline at the desktop, you can still go back to the hos tlist and into the host again for an unexpected retry.
This is with the current source. I'll check one of the 1.0.2 officials .on Android 9 and 10.. right.. that one doesn't go back to the host list. This is a new problem.
Doing this, I noticed that with both old and new versions, the host list loses some hosts over time... Quit and re-opening seems not to fix it, at least not in the time I've allowed it, whereas an FC then re-opening the app gets the full host list very quickly.
slowscript
commented
3 years ago Thanks for your time and investigation :) A possible cause of it failing after a few files is that the "Share with" activity dies and Android revokes access to the files. Showing "Waiting for permission" even after a few files is strange though and I have never had it lock up the UI before.
Unfortunately there is no way to resume after disconnects because the protocol does not support it. Sometimes the underlying TCP connection survives, sometimes it does not. This is something the Linux Mint guys would need to implement first. I can add a retry button quite easily so that shouldn't be a problem. I have no idea why it would lock up though.. will have to try disconnecting WiFi when transferring to see it for myself.
About the last issue, there is a difference between the host list on the main activity and on the "Share" activity. Every time you tap on a host on the Share activity, a new transfer with the files the activity has received is initiated. When you go back from the transfer list you end up on this activity which looks similar to the main activity but serves a different purpose. I used to close it once you tap on the device you want to share with but this had caused the very issue I have just fixed. The activity must remain open until the transfer finishes or Android will deny access to the files being shared and it fails. I'm aware of this regression and am thinking about ways to fix this without breaking the user experience. It will probably require some major changes.
StickyDigit
commented
3 years ago I'm enjoying the thrill of the chase. I rarely get my teeth into anything these days.
The phone with the weak WiFi allowed me to test the disconnect by putting it in a metal box for a moment.. I didn't know whether a manual disconnect would appear the same. How does the Linux host decide the transfer has failed? Can the Android app do similar? I've set up some Linux VM's with a proper bridge net so Warpinator works over WiFi from them too. I'll have to see what happens when I cause mischief with their connections.
Backing right out from the host list seems to cure the madness. Perhaps when using the app to share, once a host is selected and transfer is initiated, a flag could be set to cause the host list to hit its own 'back' button :) This would prevent the adventurous user from returning directly to the host.
clefebvre
commented
3 years ago I experience the same issue as @pleiozc, i.e. sharing a picture from the app to the computer works fine if browsed from within the app, but fails if browsed via gallery and then using "share" to share via the android app.
I observe the following:
I could reproduce the issue reliably for a while. Since I tried to "refuse" the transfer I could no longer do, it just works. Moving the gallery to a different picture allows me to reproduce the issue again.
Note: I have both gallery and warpinator open for these tests, I have background service setting disabled.
clefebvre
commented
3 years ago I forgot to mention: I'm using 1.0.2 on Android and 1.1.2 on the computer.
I just noticed each share started a different instance of the app (I see multiple ones in the multiview, where you see all opened apps). Closing all of them and re-running Warpinator leads to "No other devices found" and no computer host being found anymore... that's probably not related though.
slowscript
commented
3 years ago Most of the problems in this issue should be already fixed in master. I just haven't got to making a new release.
If I accept the transfer on the computer, I see "Stopped" as the transfer status in the app.
There is a bug that sometimes it shows "Stopped" even though the correct status is "Failed". The reason most shares fail was likely fixed in ef32c4c.
Closing all of them and re-running Warpinator leads to "No other devices found"
Closing all activities of an app without having background service enabled makes Android kill the service. After reopening it has to rediscover devices on the network. From time to time it just doesn't find anything which is an issue I will look into but likely won't be able to do much about.
I will release a new version with the fixes later today.
ghost
commented
3 years ago It works now, great!
slowscript
commented
3 years ago Nice! Closing the issue now.
Everything works fine while initiating the same file transfer from inside the app.