Architecture - sisbell/tor-android-service GitHub Wiki

1. VPN

Tor Browser does not depend on the VPN module. Move VPN into its own module so it can be built and used if needed. This will require decoupling various preference fields and making the VPN service optional within TorService

2. OnionProxyManager/TorService

Currently TOPL launches tor as a process. Use tor as an embedded service with JNI layer.

3. Installation

Create common installer for config files and native libraries. Tor Android Service only installs config files, not the the tor libraries. This is done by naming the native library libTor.so . Android knows to pick this up and install it. Orbot has fallback logic to handle native library installation itself. Such fallbacks were needed to deal with installation bugs on certain older Android devices. I believe such bugs are no longer common and the fallback installation shouldn't be needed anymore.

4. Settings

Settings and preferences could be moved into its own module for Android, a standard module that could be extended if needed. The reason would be to allow divergent paths for the implementation of tor settings but keeping the interface the same.

I'd like to move to having the settings more type-safe (like a Set of bridges or exit nodes AND integers for ports, etc). This would require a minimal parser back and forth between UI and preferences AND between preferences and torrc generation. This would allow a potentially more interesting UI for settings, like adding bridges or nodes one by one in the settings page, while still allowing the existing settings UI to work.

5. Broadcasts

Orbot broadcasts messages from TorService to the main app to update logs and metrics that are displayed to the user. Most of these are supported in the TOPL EventBroadcaster. However, I can see Orbot evolving where it needs to add additional ones. We need to find a way to handle this case, allowing specialization when needed.

6. TorService

Another issue is that Orbot will expand TorService with additional features that are unneeded in Tor Browser. How can we support this? Some type of delegation would be needed. Perhaps adding a TorService lifecycle with some plugin ability.

1. Continued use of TOPL? This also supports desktop, which is not our primary target.
2. Build system - have some divergence of builds and where we pull the native libraries. Is there a way we can reuse these libraries between projects?
3. Is it viable to try to maintain a common tor-android-service that both Orbot and Tor Browser use? Or are just certain pieces reusable (like configuration)?