It doesn't work for me at all as apk installed... No request of root permission at all!
However I extracted vhusbdan binary from application folder and ran it from terminal as root (or as $cripter script). Daemon stated successfully :-) However again - when I ran it from init.d script it kills my dropbear ssh server systematically :-( Don't understand why... Any idea, Michael???
Also please confirm that vhusbdan is not able to run with ssl certificate. I was failed to do this.
I made this experiment to play Hi-Res audio via DAC connected to Android tablet. I was failed probably due to Android limitation. Onkyo HF player that I bought at Android market plays the same files from the same network location (mounted as cifs or nfs share) perfectly. So this is not solution to use Windows PC not directly connected to DAC to play audio. But I don't complain - task is difficult :-)
Really thankful to you because your apps pushed me to assemble custom kernel for my Samsung tablet!
Thanks and regards,
PS IMHO android client limitation to connect only to licensed server is toooooooooooooooo strict... :-) But it is you right as developer.
Hi Alexey, the VirtualHere apk does not require root anymore so it will not ask for root.
However if you do want to run it as root, you will need a rooted device and also you will need to run su then run the vhusbdan in the android shell so that virtualhere has root permissions when it starts. When the virtualhere server detects it has root permission it provides support sharing multiple devices and better USB compatibility and also would support ssl if it was purchased.
It does not interact with dropbear ssh at all, so i dont know why dropbear stops, take a look in logcat as that will show the error. You will need to run logcat after su to show the log for all processes on the system otherwise logcat will just show the basic log with a single process.
Let me know what errors are in logcat regarding dropbear.
More on this, i updated the apk to 2.1.7 on the android play store that now has a menu to display the system message log of the server. Send me this when trying to run your apk and that will tell me why its not working. to mail [at] virtualhere.com
I investigated the case just for curiosity.
It seems to me that all init.d scripts are running in the same terminal window.
Your binary is waiting for Ctrl+C for finalizing the job as well as dropbear if it was started with -F option. So if I start your binary from init.d there is no chance to execute next scripts :-( The same about dropbear if was started with -F option. Program will wait for user response that will never come... It just a version that I have to check but it seems to me most appropriate in this case.
Finally I excluded -F from dropbear startup options and made vhusndan call after dropbear at the end of scripts chain. Everything is OK now.
As result I have suggestion to you to compile the next version with possibility to fork into background. Definitely it would be great.
Seems to me it is the reason that at normal installation of program server stops when user closes the app window however it would be better to keep it running in background.
By the way, notifications in trial version of vhusbdan are really annoying - if linux version gives me one notification at client startup, vhusbdan gives me it every minute. Did you change algorithm of notification to push user to buy full version? Not good (for user)...
Will shutdown server and install apk to share with you changes result.
You run the server with the -b flag to run it as a daemon.
It shouldnt keep saying trial version unless your network keeps going to sleep then waking up all the time, then the client keeps reconnecting.
Keep your wifi off sleep and it should be ok.
OK, Michaell, will apply changes to init.d file! Many thanks for this!
Your explanation regarding trial message is clear as well - sounds reasonable! Also thanks for this - it didn't come to my slow mind :-)
Log file was sent to your e-mail. Please check.
Fill free to request doing more as beta tester if you need it.
To follow up on this for other readers, this issue is fixed in 2.1.8 pushed to the android play store
Yes, I can confirm that now everything is OK!
Michael is very responsive!