[General Questions and Answers] hvandermaas:
On a non rooted Samsung Galaxy tab 2 7.0" I have the app GNUroot Debian installed. This is a chroot (actually it is called PRoot, see below for a description) Linux distribution - currently Debian 'Jessie' - with a terminal. I have installed the android-tools-adb package from the Debian Jessie repository. This means the chroot environment has access to the tablet's network hardware.

Now I would like to control another device (I have a non rooted Huawei Ascend Y300) from the tablet using adb inside the chroot terminal. I managed to do this through WiFi by first connecting the phone to a pc and run the terminal command 'adb tcpip 5555'. Then, on the tablet in the GNUroot Debian app terminal running the command 'adb connect xxx.xxx.x.x' gives adb control from the tablet over the phone through the local wifi network. Nice!

It would be even better to manage the adb control between two android devices from a chroot / PRoot environment without the pc, for example using an On The Go cable. Assuming non rooted devices. The tablet in question (Samsung Galaxy tab 2 7.0") has usb host capabilities. So in theory it could be done with a usb On The Go cable connecting the two Android devices.

Questions:

Is it possible to use adb within the described chroot / PRroot environment to run commands to controle another Android device, when both Android devices are connected through a USB On The Go cable?

Does a chroot / PRoot environment give access to the usb port as host?

Information:

The reason for this question is the development of an app on my tablet, using the Android IDE app, which must be tested on other (non rooted) Android devices. Preferably from the tablet, preferably without a pc.

Description of PRoot from 'proot-me' repository at github.com:

==

PRoot is a user-space implementation of ``chroot``, ``mount --bind``,

and ``binfmt_misc``. This means that users don't need any privileges

or setup to do things like using an arbitrary directory as the new

root filesystem, making files accessible somewhere else in the

filesystem hierarchy, or executing programs built for another CPU

architecture transparently through QEMU user-mode. Also, developers

can use PRoot as a generic Linux process instrumentation engine thanks

to its extension mechanism, see CARE_ for an example. Technically

PRoot relies on ``ptrace``, an unprivileged system-call available in

every Linux kernel.

The new root file-system, a.k.a *guest rootfs*, typically contains a

Linux distribution. By default PRoot confines the execution of

programs to the guest rootfs only, however users can use the built-in

*mount/bind* mechanism to access files and directories from the actual

root file-system, a.k.a *host rootfs*, just as if they were part of

the guest rootfs.

When the guest Linux distribution is made for a CPU architecture

incompatible with the host one, PRoot uses the CPU emulator QEMU

user-mode to execute transparently guest programs. It's a convenient

way to develop, to build, and to validate any guest Linux packages

seamlessly on users' computer, just as if they were in a *native*

guest environment. That way all of the cross-compilation issues are

avoided.

PRoot can also *mix* the execution of host programs and the execution

of guest programs emulated by QEMU user-mode. This is useful to use

host equivalents of programs that are missing from the guest rootfs

and to speed up build-time by using cross-compilation tools or

CPU-independent programs, like interpreters.

It is worth noting that the guest kernel is never involved, regardless

of whether QEMU user-mode is used or not. Technically, when guest

programs perform access to system resources, PRoot translates their

requests before sending them to the host kernel. This means that

guest programs can use host resources (devices, network, ...) just as

if they were "normal" host programs.

==