Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • N NetCipher
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 15
    • Issues 15
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • guardianproject
  • NetCipher
  • Issues
  • #10

You need to sign in or sign up before continuing.
Closed
Open
Created Dec 17, 2019 by Hans-Christoph Steiner@eighthaveOwner

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

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 Tor: https://trac.torproject.org/projects/tor/ticket/32780

Edited Dec 17, 2019 by Hans-Christoph Steiner
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking