Questions:
Is it possible to use adb within a chroot / PRroot environment on one Android device to run commands to control another Android device, when both Android devices are connected through a USB On The Go cable?
In other words:
Does a chroot / PRoot environment give access to the usb port as host?
Situation:
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. Obviously 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.
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.
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.
==
Is it possible to use adb within a chroot / PRroot environment on one Android device to run commands to control another Android device, when both Android devices are connected through a USB On The Go cable?
In other words:
Does a chroot / PRoot environment give access to the usb port as host?
Situation:
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. Obviously 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.
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.
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.
==
Facebook
Twitter
Instagram