We're still maybe curlzipping and using a binary distribution of Go, but
at least this is only the case on machines that don't have go.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This is insane, but it appears to be working. We essentially store
things in a separate class for editing, and then commit it back at a
given time.
This business with onViewStateRestored in both TunnelEditorFragment and
in TunnelDetailFragment is buggy and likely wrong.
In general TunnelEditorFragment should probably be rewritten. The
relationship with the changed name is not clear.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This will make the two way data binding crash more, but it will improve
the robustness of the config file parser, which deals with exceptions
gracefully, and when we move to one way data binding, it will help with
that too.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
We don't actually comprehend how this works yet, so disable it. But
we'll need to add support for this at some point.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This synchronizes the OS's connection state with ours, such as when the
user disconnects using the system UI.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This is a bummer, but Gradle already specifies tons of specific versions
of various binary components, so this is not materially different than
the rest of how this whole thing works.
It also allows us to specify the Go version that will actually build a
working binary of wireguard-go, since all of the Go bugs mean not every
version works equally. We do *not* want to use whatever version a distro
happens to be shipping.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This sucks, but it works with mobile networks. Later we can do something
sophisticated like we do with wg-quick.c, but not now.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Since the amount of mind numbing boiler plate has been increased, this
must be the proper way to do things.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise we might dereference it, per this play store gathered trace:
Xiaomi Redmi 3S (land), 2048MB RAM, Android 7.1
java.lang.NullPointerException:
at com.wireguard.android.model.Tunnel.setConfig (Tunnel.java:118)
at com.wireguard.android.fragment.TunnelEditorFragment.onOptionsItemSelected (TunnelEditorFragment.java:160)
at android.app.Fragment.performOptionsItemSelected (Fragment.java:2478)
at android.app.FragmentManagerImpl.dispatchOptionsItemSelected (FragmentManager.java:2182)
at android.app.FragmentController.dispatchOptionsItemSelected (FragmentController.java:336)
at android.app.Activity.onMenuItemSelected (Activity.java:3211)
at com.android.internal.policy.PhoneWindow.onMenuItemSelected (PhoneWindow.java:1219)
at com.android.internal.view.menu.MenuBuilder.dispatchMenuItemSelected (MenuBuilder.java:761)
at com.android.internal.view.menu.MenuItemImpl.invoke (MenuItemImpl.java:152)
at com.android.internal.view.menu.MenuBuilder.performItemAction (MenuBuilder.java:904)
at com.android.internal.view.menu.MenuBuilder.performItemAction (MenuBuilder.java:894)
at android.widget.ActionMenuView.invokeItem (ActionMenuView.java:616)
at com.android.internal.view.menu.ActionMenuItemView.onClick (ActionMenuItemView.java:152)
at android.view.View.performClick (View.java:5637)
at android.view.View$PerformClick.run (View.java:22433)
at android.os.Handler.handleCallback (Handler.java:751)
at android.os.Handler.dispatchMessage (Handler.java:95)
at android.os.Looper.loop (Looper.java:153)
at android.app.ActivityThread.main (ActivityThread.java:6244)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:891)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:781)
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
According to play store reports, such as:
wt88047, 0MB RAM, Android 8.1
java.lang.NullPointerException:
at com.wireguard.android.QuickTileService.updateTile (QuickTileService.java:97)
at com.wireguard.android.QuickTileService.onStartListening (QuickTileService.java:56)
at android.service.quicksettings.TileService$H.handleMessage (TileService.java:407)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loop (Looper.java:164)
at android.app.ActivityThread.main (ActivityThread.java:6520)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:442)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:807)
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
IP addresses and key material could be potentially sensitive. We also
don't want any interactions with the suggestive text APIs. So, we mark
it as both a visible password and we turn off suggestions. This will fix
the length limit, too, in Android 8.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This has all sorts of terrible implications and fixes a problem in a
pretty terrible way. If the interface MTU is less than 1280, IPv6
addresses will fail to be added. Rather than explictly trying to catch
this and do something particular about it -- such as nicely warning the
user that there could be a v6 isolation issue, for example -- we just
set the MTU _after_ we set the addresses, so that in setting the MTU, we
wind up removing the addresses that were just added. This is pretty bad,
but it makes things a bit smoother.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
