search

acidburn0zzz / ics-openvpn

Automatically exported from code.google.com/p/ics-openvpn
1 stars 0 forks source link

Restart after being killed? #286

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Since the app can sometimes be killed for memory constraints (even with 
foreground notification present), I think it would be good for OpenVPNService 
to be restarted as soon as possible after that happens.

We've implemented it in Bitmask Android because we don't use the foreground 
notification, so our app can be killed more frequently than ics-openvpn, and we 
wanted to mitigate it a bit. I can also work on the integration of that code 
into ics-openvpn, if you approve it of course.

Our intention is to stay as close as possible to ics-openvpn, improving just 
the UI and the automation and not the openvpn code itself. Libre Software 
developers software can collaborate between them, which is great :)

Original issue reported on code.google.com by parm...@sdf.org on 26 Sep 2014 at 12:22

GoogleCodeExporter commented 9 years ago 
I looked into that. It should be as simple as simply changing the flag that is 
returned and fixing everything that breaks. I have commited my changes. Maybe I 
missed something but that should work.

Original comment by arne@rfc2549.org on 29 Sep 2014 at 8:21

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision ea107025a51c.

Original comment by arne@rfc2549.org on 29 Sep 2014 at 8:21

GoogleCodeExporter commented 9 years ago 
Hi!

 You've put the REDELIVER_INTENT flag.

 That was my first approach too, but I realized that the restart would take a lot of time and that's not good at all. Digging into the scheduling code from AOSP, I saw that the time it calculates to schedule the restart is dependent on the time the intent has been in used (more or less, afaiu), and that time for me could be as high as ~100000ms, instead of ~1000ms.

 I'm also surprised because you made a lot of changes in your code just to implement this functionality, compared as to what I did with your same codebase.

 Let me suggest you to look at my commit (https://github.com/parmegv/bitmask_android/commit/1981229696cffe443936df2da1dd92e36003f563). I put the persistent tun if just to avoid changing your default functionality (since bitmask always uses persistent tun), but that could be changed to default removing that if.

 If you need something from me, please tell me.

 Thanks for your code and your friendliness, have a nice day

Original comment by parm...@sdf.org on 29 Sep 2014 at 8:34

GoogleCodeExporter commented 9 years ago 
Oh did not know that AOSP code treats REDELIVER_INTENT different from STICKY. I 
will have to change the code in that case. Without the other changes reconnect 
would break for profiles with keystore and profiles without saved PW (disabled 
for now). You probably don't need these profiles in your app and haven't tested 
them :)

Original comment by arne@rfc2549.org on 29 Sep 2014 at 8:43

GoogleCodeExporter commented 9 years ago 
hahaha.

True, you're right, sorry for the inconvinience hehehe
On lun, sep 29 2014,nil nil wrote:

Original comment by parm...@sdf.org on 29 Sep 2014 at 8:45

GoogleCodeExporter commented 9 years ago 
Revision 09362f32b036 should now work with using STICKY

Original comment by arne@rfc2549.org on 29 Sep 2014 at 9:22