java.lang.IllegalStateException:
at android.app.ContextImpl.startServiceCommon (ContextImpl.java:1720)
at android.app.ContextImpl.startService (ContextImpl.java:1675)
at android.content.ContextWrapper.startService (ContextWrapper.java:669)
at com.wireguard.android.backend.GoBackend.startVpnService (GoBackend.java:4)
at com.wireguard.android.backend.GoBackend.setStateInternal (GoBackend.java:4)
at com.wireguard.android.backend.GoBackend.setState (GoBackend.java:2)
at com.wireguard.android.model.TunnelManager$setTunnelState$2$1.invokeSuspend (TunnelManager.java:6)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (BaseContinuationImpl.java:2)
at kotlinx.coroutines.DispatchedTask.run (DispatchedTask.java:2)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely (CoroutineScheduler.java)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask (CoroutineScheduler.java:7)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker (CoroutineScheduler.java:7)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run (CoroutineScheduler.java:7)
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
GlobalScope has numerous problems[1] that make it unfit for
use in most applications and making it behave correctly requires
an excessive amount of verbosity that's alleviated simply by using
any other scope. Since we run multiple operations in the context
of the application's lifecycle, introduce a new scope that is created
when our application is, and cancelled upon its termination.
While at it, make the scope default to Dispatchers.IO to reduce pressure
on the UI event loop. Tasks requiring access to the UI thread appropriately
switch context making the change completely safe.
1: https://medium.com/@elizarov/the-reason-to-avoid-globalscope-835337445abc
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
The stats might become null between these two checks, when a tunnel
flips off, resulting in a null pointer dereference:
at com.wireguard.android.model.ObservableTunnel.getStatisticsAsync (ObservableTunnel.java:103)
at com.wireguard.android.fragment.TunnelDetailFragment.updateStats (TunnelDetailFragment.java:108)
at com.wireguard.android.fragment.TunnelDetailFragment.access$updateStats (TunnelDetailFragment.java:27)
at com.wireguard.android.fragment.TunnelDetailFragment$onResume$1.run (TunnelDetailFragment.java:74)
at java.util.TimerThread.mainLoop (TimerThread.java:562)
at java.util.TimerThread.run (TimerThread.java:512)
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The correct way to retrieve the value inside a getter/setter is to use `field` to ensure
you don't invoke the getter while inside the getter and trigger a stack overflow
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Also fix up wording for the permission prompt that Tasker will show when
initially setting this up.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It's not right to blindly follow all of AndroidStudio's suggestions,
especially for things in tunnel/ which comprise useful API.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Hacking things up via gradle is not right, and package-info.java poses
problems with two modules, so instead we just apply it manually to every
class.
Remember to add this to new classes!
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld