[tor-bugs] #32780 [- Select a component]: make TorService fit into the Android lifecycle as a "Bound Service"

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32780: make TorService fit into the Android lifecycle as a "Bound Service"
-------------------------------------+-------------------------------------
 Reporter:  eighthave                |          Owner:  (none)
     Type:  enhancement              |         Status:  new
 Priority:  Medium                   |      Component:  - Select a
                                     |  component
  Version:                           |       Severity:  Normal
 Keywords:  Android, TorService,     |  Actual Points:
  tbb-mobile                         |
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+-------------------------------------
 One key reason why `TorService` was created was to embed Tor daemon in a
 native Android `Service`.  That works now, so now this opens up a lot of
 possibilities for making Tor work in a way that Android wants background
 systems to operate.  First, I'm regularly seeing sub 5 second `TorService`
 starts, which means from zero Tor running to viewing
 https://check.torproject.org within 5 second.  With all the sleep/restore
 work in Core Tor, I think we remove the "always running" model that we've
 used for the past 10 years, and instead think of `TorService` as something
 that runs on demand, then stops when not needed.

 While reading about the background service restrictions:
 https://developer.android.com/about/versions/oreo/background#services
 I noticed that these restrictions do not apply to "bound services", where
 there is a `Binder` IPC connection between `TorService` and an Android
 app.  So for the Tor Browser or Briar model, where they ship with embedded
 `TorService`, they can use the `bindService()` interface to prevent
 `TorService` from being killed without needing a permanent `Notification`
 in the toolbar.

 That app binding to `TorService` need not be the app that ships with it.
 So we could also make NetCipher connect the client apps to `TorService` to
 keep it alive, in cases where the embedded `TorService` is expected to be
 used by other apps, e.g. Orbot and a Feed Reader app.

 Something like using the ControlPort via stdin/stdout or direct method
 call would make rapid (re)starts work more reliably, e.g.
 https://trac.torproject.org/projects/tor/ticket/32476#comment:5

 Also tracking this in NetCipher:
 https://gitlab.com/guardianproject/NetCipher/issues/10

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32780>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs