[guardian-dev] Orbot v14.1.4: The Battle for the Background!
tbray at textuality.com
Mon Dec 1 11:37:13 EST 2014
When I was in the Android group at Google, the dogma was always that you
can't count on on destroy() being called. The actual code that does this
should be part of AOSP...
On Dec 1, 2014 8:33 AM, "Michael Rogers" <michael at briarproject.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> TAKEOWNERSHIP command.
> > 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Guardian-dev mailing list
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To Unsubscribe
> Send email to: Guardian-dev-unsubscribe at lists.mayfirst.org
> Or visit:
> You are subscribed as: tbray at textuality.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Guardian-dev