This is kind of ridiculous, since the items own state should clearly be
queryable, but it doesn't appear to be the case here, so just shuffle it
around into kotlin and back.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
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>
java.lang.IllegalStateException:
at androidx.fragment.app.Fragment.requireContext (Fragment.java:17)
at com.wireguard.android.fragment.BaseFragment$setTunnelStateWithPermissionsResult$1.invokeSuspend (BaseFragment.java:4)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (BaseContinuationImpl.java:2)
at kotlinx.coroutines.UndispatchedCoroutine.afterResume (UndispatchedCoroutine.java:19)
at kotlinx.coroutines.AbstractCoroutine.resumeWith (AbstractCoroutine.java:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (BaseContinuationImpl.java:2)
at kotlinx.coroutines.UndispatchedCoroutine.afterResume (UndispatchedCoroutine.java:19)
at kotlinx.coroutines.AbstractCoroutine.resumeWith (AbstractCoroutine.java:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (BaseContinuationImpl.java:2)
at kotlinx.coroutines.DispatchedTask.run (DispatchedTask.java:2)
at android.os.Handler.handleCallback (Handler.java:790)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:164)
at android.app.ActivityThread.main (ActivityThread.java:7025)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:441)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1408)
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
onSelectedTunnelChanged is already queueing us to Dispatchers.Main
(rather than Dispatchers.Main.immediate, which would crash, but why?),
so avoid the extra trip through the event loop by toggling the selected
tunnel right away.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
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>
Long press a tunnel item. SIGKILL the app. Reenter it. Boom:
kotlin.KotlinNullPointerException:
at com.wireguard.android.fragment.TunnelListFragment$ActionModeListener.onCreateActionMode (TunnelListFragment.java:347)
at androidx.appcompat.app.AppCompatDelegateImpl$ActionModeCallbackWrapperV9.onCreateActionMode (AppCompatDelegateImpl.java:2442)
at androidx.appcompat.app.WindowDecorActionBar$ActionModeImpl.dispatchOnCreate (WindowDecorActionBar.java:1062)
at androidx.appcompat.app.WindowDecorActionBar.startActionMode (WindowDecorActionBar.java:530)
at androidx.appcompat.app.AppCompatDelegateImpl.startSupportActionMode (AppCompatDelegateImpl.java:1055)
at androidx.appcompat.app.AppCompatActivity.startSupportActionMode (AppCompatActivity.java:316)
at com.wireguard.android.fragment.TunnelListFragment$ActionModeListener.setItemChecked (TunnelListFragment.java:371)
at com.wireguard.android.fragment.TunnelListFragment.onActivityCreated (TunnelListFragment.java:174)
at androidx.fragment.app.Fragment.performActivityCreated (Fragment.java:2717)
at androidx.fragment.app.FragmentStateManager.activityCreated (FragmentStateManager.java:346)
at androidx.fragment.app.FragmentManager.moveToState (FragmentManager.java:1188)
at androidx.fragment.app.FragmentManager.moveToState (FragmentManager.java:161)
at androidx.fragment.app.FragmentManager.moveToState (FragmentManager.java:1356)
at androidx.fragment.app.FragmentManager.moveToState (FragmentManager.java:5)
at androidx.fragment.app.FragmentManager.moveFragmentToExpectedState (FragmentManager.java:1434)
at androidx.fragment.app.FragmentManager.moveFragmentToExpectedState (FragmentManager.java:5)
at androidx.fragment.app.FragmentManager.moveToState (FragmentManager.java:1497)
at androidx.fragment.app.FragmentManager.moveToState (FragmentManager.java:389)
at androidx.fragment.app.FragmentManager.dispatchStateChange (FragmentManager.java:2625)
at androidx.fragment.app.FragmentManager.dispatchStateChange (FragmentManager.java:677)
at androidx.fragment.app.FragmentManager.dispatchActivityCreated (FragmentManager.java:2577)
at androidx.fragment.app.FragmentManager.dispatchActivityCreated (FragmentManager.java:9)
at androidx.fragment.app.FragmentController.dispatchActivityCreated (FragmentController.java:247)
at androidx.fragment.app.FragmentActivity.onStart (FragmentActivity.java:541)
at androidx.appcompat.app.AppCompatActivity.onStart (AppCompatActivity.java:201)
at android.app.Instrumentation.callActivityOnStart (Instrumentation.java:1440)
at android.app.Activity.performStart (Activity.java:8109)
at android.app.ActivityThread.handleStartActivity (ActivityThread.java:3806)
at android.app.servertransaction.TransactionExecutor.performLifecycleSequence (TransactionExecutor.java:235)
at android.app.servertransaction.TransactionExecutor.cycleToPath (TransactionExecutor.java:215)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:187)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:105)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2386)
at android.os.Handler.dispatchMessage (Handler.java:107)
at android.os.Looper.loop (Looper.java:213)
at android.app.ActivityThread.main (ActivityThread.java:8178)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:513)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1101)
This commit avoids the crash. But it's not clear to me that this is
really the right solution. However, in testing it appears to work.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
From the ld.gold source:
const char* name = parameters->options().soname();
if (name == NULL)
name = parameters->options().output_file_name();
That means by default it uses `-o {output}` as the verdef aux name,
which is random every time due to Go's build system. By passing in
`--soname={somethingexplicit}` we can instead have a deterministic
verdef.
This commit makes wireguard-android reproducible.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The fdroidserver repo hardcodes hashes of all gradle versions that are
allowed to be used. This is currently up to date, having 6.3. However,
the f-droid build server is not up to date, because it is controlled by
the founder of f-droid, who is generally unavailable and does not update
it. Meanwhile other members of the project would like to stand up their
own build server instance, but this seems potentially arduous and
there's still the question of the signing key. At least that's the story
I was able to glean from asking around.
So, in order to work around this organizational brokeness, we just
downgrade to 6.2.1.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld