Opened 10 months ago

Last modified 10 months ago

#32780 new enhancement

make TorService fit into the Android lifecycle as a "Bound Service"

Reported by: eighthave Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: Android, TorService, tbb-mobile
Cc: n8fr8, sysrqb, sisbell Actual Points:
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 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:
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.

Also tracking this in NetCipher:

Child Tickets

Change History (1)

comment:1 Changed 10 months ago by dgoulet

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team
Note: See TracTickets for help on using tickets.