First, thanks Greg for the detailed response. I’ll respond to that next, but wanted to get some basic points in here.
> On Jul 23, 2022, at 9:25 AM, Tom Ritter <[email protected]> wrote: > > This is a specific question more about Android and iOS dev than tor. > > Tor's got the new experimental in-process API: > https://gitweb.torproject.org/tor.git/tree/src/feature/api I'm > working with someone who is developing a mobile app, and they want to > bundle tor. We don't know if it would be better to make tor a > separate process (I'm assuming this is possible, I know next to > nothing about mobile dev) or have it as its own thread using the API. We have been running Tor in-process for awhile now for both Orbot on Android (via the tor-android library) and OnionBrowser (iOS via the Tor.framework library). We don’t need the new in-process API, since we can continue to use the tor control port, even though it is in process. Library info and sample code here: https://gitlab.com/guardianproject/tor-android iOS release here: https://github.com/iCepa/Tor.framework/tree/pure_pod It all seems to work just fine being in a thread, though we’ve had to work through various issues with tor understanding how to be stopped and started within the same process multiple times. Orbot’s code for calling tor-android in the same process as the Android app: https://github.com/guardianproject/orbot/blob/master/orbotservice/src/main/java/org/torproject/android/service/OrbotService.java#L703 > > I was wondering from an OS point of view, under memory pressure would > the OS kill the tor process but not the app? Or would it kill both? > Has anyone thought about this? Is there a general consensus or > informed opinion? OnionShare Android also uses the tor-android library, but I believe it runs its service in a separate Android process: https://github.com/onionshare/onionshare-android You can see this here: https://github.com/onionshare/onionshare-android/blob/main/app/src/main/AndroidManifest.xml#L38 The main UI is in the primary process, while the OnionService that manages tor-android is in a separate process called “:tor” Torsten and the Briar team working on the app did this for various reasons, which they might chime in on here. By having the separate process in an Android Service that can be destroyed within the Android lifecycle, you ensure a clean stop/start no matter what tor does or doesn’t do. *** As for overall memory management within Android, it is still a Wild West. We do know that if you bind to an Android VPN service or have a ForegroundService with a permanent notification, that your background code process generally doesn’t get killed. If your app is in the foreground, that process will not be killed. Best, Nathan _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
