[guardian-dev] Orbot v14.1.4: The Battle for the Background!

Michael Rogers michael at briarproject.org
Mon Dec 1 11:33:27 EST 2014

Hash: SHA256

On 01/12/14 14:16, Nathan of Guardian wrote:
> In addition, there was an interesting phenomenon we took advantage
> of, which was that even if the TorService instance was killed, the
> separate processes launched via Runtime.exec() for the tor and
> privoxy/polipo binaries were not killed. This often caused problems
> on upgrades, where the entire app was killed or uninstalled, and
> yet /tor and /polipo kept running. This was definitely a bug, but
> it also allowed us to be a bit lazy, because as long as these
> background processes kept running, the lifecycle of the TorService
> didn't matter so much. Ultimately, this caused many problems with
> orphaned processees and multiple instaces of /tor running, that
> caused all sorts of crazy.

We used to have a lot of code in Briar's TorPlugin for detecting and
killing orphaned processes, but Yaron Goland pointed out that by using
__OwningControllerProcess and TAKEOWNERSHIP, the Tor process can clean
itself up when the controlling process dies. So TorPlugin is a lot
simpler now.


This requires a small patch to jtorctl to add support for the

> And another thing (i am running out of ways to say there is more),
> on early builds of Lollipop, this whole issue was really
> exacerbated with foreground apps that use a lot of memory, like
> Chrome browser. Using Chrome with Orbot (via Wifi or APN proxy
> settings on), caused almost an instant low memory warning in
> TorService, and then a kill -9. Often, Chrome browser itself would
> be killed, too. Fortunately, an upgrade to the final release ROM
> (on my Nexus 7 2013), stopped this behavior, proving that this
> extreme memory management was actually a bug and not a feature.

This is good to know, thanks!

> Not to be forgotten, there was also a bug in TorService where 
> setForeground() was not always being called, but since we call 
> setOngoing(true) in our NotificationBuilder, it made it seem like
> it was from the UI perspective (you couldn't swipe away the
> service). I noticed this by running a task manager app, which
> indicated which services were foreground, and I noticed sometimes
> TorService was not being called. There is also a known issue with
> ICS, where receiving/registering for certain Broadcast types, can
> cause you Foreground=true Service to be reset to Foreground=false.
> I can't find the exact ticket, but is out there, and Google knows
> about it.

Argh, it never ends, does it? I'll have a look for the ticket and see
whether BriarService is affected.

Version: GnuPG v1.4.12 (GNU/Linux)


More information about the Guardian-dev mailing list