Closed truedat101 closed 10 years ago
This is really the parent of #2 and #3.
If for some reason, none of the standard WebRTC options pan out, we can try this as a fallback: http://deadsimplescreensharing.com/#tutorial
Seems the remote screen viewing is something that requires rooting. Sigh.
Here's a good discussion of the options for VNC: http://forum.xda-developers.com/showthread.php?t=1947708
There's only one that is supposedly working without root. I may need to try it: https://play.google.com/store/apps/details?id=com.vmlite.vncserver
This might be th3 only option.
Another option that might work is screen casting: http://www.mightypocket.com/2010/08/android-screenshots-screen-capture-screen-cast/
My efforts around webrtc may be foiled specifically for Desktop Sharing. Seems this should be working in Chrome. I'll keep experimenting.
Every 2 years I keep hoping the state of Android has improved tremendously ... and it has and it hasn't. Five years ago I was complaining about tools and ability to get real open source projects running well on top of the Android toolchain. Three years ago I was complaining about good mobile web. And Two years, it was general lack of device access to USB services in host mode. And screen capture. Now ... we still can't get access to the framebuffer. And I'm still complaining about things like full screen mode and UI choices that prevent a developer from writing apps that really control the hardware. Sigh.
So none of the "screencasting" support works with Android below 4.4 yet. There is a new feature coming in, one available in Chrome Canary which allows some form of screen casting which makes sense for a 1-1 relationship between phone and tethered PC. Not what I want. I just want VNC. PleaZe. Without rooting.
The WebRTC features that actually support really cool desktop sharing are not available in Chrome on Android, presumably because we can't get to the FB. And then on top of that, the apis are specific to chrome, not standard, sooooo. I guess maybe in 1 year we can do this completely in WebRTC.
I can get Chrome Desktop (teacher) sharing to students, along with video and chat and file sharing, almost out of the box.
The approach that VMLite VNC server offered without root is a farce: http://itsanant.blogspot.com/2013/07/running-android-mobile-on-your-pc.html
It requires a USB tether. I can get USB tethering solutions today. What they do is host a server on the PC, which handles the actual VNC services ... not sure what they do to get the screen capture done, but I'd guess they to FB captures using screen grabs and keep the framerate low.
There are a bunch of solutions like this: http://www.mymobiler.com/ . I have one off these that I used to do screen casting from my tablet for SMILE. It is using the ADB protocol ... in fact that's probably what the VMLite solution does.
which leads me to http://code.google.com/p/androidscreencast/issues/detail?id=83
This might work. Will investigate.
If I can't get the above option working, I will throw in the towel on true screen cast, and support low framerate capture by streaming images quickly in a hacky fashion. Perhaps I can do something with ffmpeg or I can just use the webrtc data channel and share the images rapidly. Need to see if I can script the screen capture easily.
Minimally I should be able to do what we used to do which is to reload an image repeatedly from some route, say http://
ADB over Wifi requires root permissions so that is 100% out also.
Looking at the radix software, there's no detail in their technical description: http://www.radix-int.com/Classroom-Management/Tablet-Classroom-Management-Software.html#overview
about which tablets, though they mention 8 tablets supported. This is suspicious. There is only one company known to offer a product that seems to offer a true remote screen share. I've heard about RemoteCall (from RSupport) which is a commercial grade product, and not cheap. Also, the company that handled the screen share for Samsung's products seems to be active in this area. I believe what has to happen in those cases is they build their app with a key signed by the OEM, and license the product back to the OEM. That's how they get screen share working on a Samsung device, because the OEM has licensed the product and allowed it to work on the platform.
So final note on the Radix product I came across while searching for options on this ... ironically, someone answered on stack overflow mentioning the Radix product: http://android.stackexchange.com/a/42616/49912
Sign, not sure how they do it, but I suspect they only enter deals where they can get authorized key signed by the OEM, which would enable the right permission for framebuffer capture.
And my final word on this: http://android.stackexchange.com/questions/1931/i-want-to-remotely-control-my-android-device-from-my-pc-without-rooting-it-is-t?rq=1
Is no, not possible yet in Android. See a glimpse of the future: https://developers.google.com/chrome-developer-tools/docs/remote-debugging
Onward to screen grabbing.
This is brilliant: http://stackoverflow.com/a/16748500/796514
I was thinking of doing some key injection but I don't see that working , as requires window or system level permissions, and there don't appear to be any non-root ways to do this easily. One way appears to be leveraging android instrumentation. However, this is about as heavy weight as one could expect.
The way prescribed in the SO in the previous comment is to call the shell and use a little utility there to generate a screen grab. It's a little slow, about 800ms or so. So we'll only get 1fps if we use this method.
I can run shell commands in mcpservice.py using whatever subprocess command or os.system(). I believe what I'll do is run the command for screen grabs in a loop while we execute mcpservice. Hopefully this is just low impact. What we'd need to do is save the image into the root webdir of sl4a and the mcpservice. Then I can serve the images for each client via mcp. That might just work.
Back to this boring question, there's another option: http://code.google.com/p/android-screenshot-library/ mainly for testing it looks like.
Verified we can use sl4a.
Unfortunately, calls done through the shell don't have the right permission to get the framebuffer. Only calls from ADB shell work. ADB gives the permissions closest to root, though we can't exec root permissions on this device. The user shows up as shell. Regular apps run as u0_a102.
Here's the commercial solution that uses Samsung SAFE and Samsung KNOX device configurations: http://www.air-watch.com/solutions/android/samsung-for-enterprise
These are likely only available through special purchase via a reseller. If I can get this OTPC we might be able to find an open firmware we can use.
There is a way to send events via adb, which could inject key events: http://blog.softteco.com/2011/03/android-reproducing-swipe-motion-to.html
The Android Screenshot Library works on the OTPC Device. This is at least viable. I think the trick they use is to start the service from the shell using adb. If we can simply run a script from adb in the background on each demo device this should then work without needing the ASL.
Will verify.
Verified that the screencap works on the OTPC device.
I've gotten basic screen grab working, with hacky caveats . It's good enough to get through the requirement. However, we want to clarify with the customer the frame rate, the potential for deluge of network traffic if they try to monitor too many screens at once, and potential for I/O blocking and general burn on the battery life of these OTPC tablets.
I've got a Nexus 7 rooted with Cyanogenmod, as a back up plan, to hopefully allow us to host VNC server, but this is a backup. There is one problem with the vnc solution, and that's the requirement for java to view remotely via the web. We could try to implement a solution with NoVNC, but this is probably getting into enterprise requirements. The Cyanogen device is slick, in that it's on the latest android. But it needs an app store. I will assume this is on the backburner for now, but is a good long term solution to go with a rooted, cyanogen mod based firmware over the alternative which is a locked firmware.
Some initial testing shows that screencap DOES NOT work on the rooted device. But again this is 4.4 jand we don't know what permissions are needed for screen cap.
Need a UI for basic sharing of screens around. The list view thing on the side of the teacher UI will need to handle the sharing console. We need:
ThinVNC seems to be the selection choice for both simplicity and the fact it works on windows. Let's plan to use this initially for demo.
This is a picture of the screen watching a screen.
Ok, need to finalize the capture route for individual screens.
Will just add a route for screenmonitor (of one student). Then we can cycle these in the colorbox window like in a gallery style.
I think this feature can be redesigned significantly down the road, but for now this is ok.
For example, we better capture capabilities, we can generate thumbnails, build more of a gallery style viewer with tiles and less frequent updates.
I am marking this as complete. We have at least a best effort now in getting this feature to work well. Teacher share, as mentioned, requires the user to use "browser/internet" from AOSP, not the Firefox as it doesn't work well. I'll file an issue describing the problem.
Note, this isn't simultaneously, just needs to be on a per student basis.