-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ah, this remindes me of a hack I did for AdAway. I had this webserver that only delivers blank webpages.
Sometimes it was killed by the OS. I copy pasted this code I found on the web and it worked (haven't tested it with newer versions of Android). Obviously, it requires root: https://github.com/dschuermann/ad-away/blob/master/AdAway/jni/blank_webserver/blank_webserver.c#L35 Regards Dominik On 12/01/2014 06:10 PM, Michael Rogers wrote: > After a bit of googling it seems to be handled by a kernel > module... or at least it was in Android 3.10, I can't find the > kernel sources after that. > > https://android.googlesource.com/kernel/common.git/+/android-3.10/drivers/staging/android/lowmemorykiller.c > > Userland declares a policy by setting memory thresholds and > attaching oom_adj scores to processes, and the driver SIGKILLs > processes without (as far as I can see) calling back into userland > first. > > See also: http://www.programering.com/a/MjNzADMwATE.html > > Cheers, Michael > > On 01/12/14 16:37, Tim Bray wrote: >> 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" >> <[email protected] <mailto:[email protected]>> >> wrote: > >> 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. > >> https://code.briarproject.org/akwizgran/briar/blob/master/briar-android/src/org/briarproject/plugins/tor/TorPlugin.java > >> 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. > >> Cheers, Michael _______________________________________________ >> Guardian-dev mailing list > >> Post: [email protected] >> <mailto:[email protected]> List info: >> https://lists.mayfirst.org/mailman/listinfo/guardian-dev > >> To Unsubscribe Send email to: >> [email protected] >> <mailto:[email protected]> Or visit: >> https://lists.mayfirst.org/mailman/options/guardian-dev/tbray%40textuality.com > >> You are subscribed as: [email protected] >> <mailto:[email protected]> > > _______________________________________________ Guardian-dev > mailing list > > Post: [email protected] List info: > https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe Send email to: > [email protected] Or visit: > https://lists.mayfirst.org/mailman/options/guardian-dev/dominik%40dominikschuermann.de > > You are subscribed as: [email protected] > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJUfKOaAAoJEHGMBwEAASKCx1gH/Rx5HWmYMYhAzcj4OK5J1oCQ xQWVYM0EcCnZlrwGOu0D0EGyqYVTjOEztew60wKt2AlnM29/lJRffss0ft8BuFx9 z2TRB1PiDonuSJp9ji1qZdWmeuW56pLyq1elcYlWHWy0XM5Zv9TKF3GexDybuHQD Q9Lgxr3mO9qmlUovnEQkaN7jleHiNj1ZvCgmEDxi3zvYx3xfFV0/kUnkS4zYQRgv T2PM3KdI+z+hOaD5bOYuAGsqGQakktkKT+eZGB9F8dxxP9W98p+DZCY1J1llgqA0 DmBDqWntyb96wXTk4KlFrO1yr6sdNeTo6LFmpqLLkKJoJ0blyHQgIyDw8CCsg80= =sQYQ -----END PGP SIGNATURE----- _______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
