Android: Tor shared library vs exec binary?

[coderman]

On Fri, Nov 26, 2010 at 10:18 AM, Nathan Freitas <nathan at freitas.net> wrote:
> Any thoughts on running Tor as a shared library within Orbot/Android
> versus the way we do it now (command line start/stop with control port)?
...

On Mon, Nov 29, 2010 at 7:04 AM, Nick Mathewson <nickm at freehaven.net> wrote:
> ... That said, I don't generally think embedding Tor as a shared library
> is the best choice, for a few reasons...
> * Using process isolation to isolate Tor from its controllers makes it
> easier to tell Tor bugs from controller bugs....
> * Using process isolation to isolate Tor from its controllers can also
> make it easier to secure each of the two domains properly against bugs
> in the other, especially if you're using OS or VM sandboxing features.

Tor must be its own process for these and other reasons. Yet it is
still preferable to have Orbot/Android app communicate / dependent on
just a slim shared library rather than cumbersome command line
start/stop method.

this implies use of android.app Service for Tor implemented as dynamic
DSO via NDK JNI for ideal integration. The NDK portion is really just
Tor invoked as main() per Nick's suggestion. a configuration like this
using both DSO and Service plays better with Task Killers as well,
among other benefits.

the Tor app Service could use a Message Queue or other available
communicate mechanism to map a subset of Control Port commands to a
queue and Java language client that the Controller utilizes when
needed and GUI active to display and configure the running Tor
instance / Service.

although this too is just suggestion to be taken with grains of salt. :)

best regards,