Having a consistent set of code style and inspection rules makes it
easier for contributors to match the existing code.
Signed-off-by: Samuel Holland <samuel@sholland.org>
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>
In AppCompat based preferences, this#getContext returns an
object of android.view.ContextThemeWrapper class from where
we can safely extract a reference to our parent activity.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
This is an activity, so it does not join the fragment backstack, but
instead piles on top
SettingsActivity
| -> MainActivity
| -> EditorFragment
| -> DetailFragment
| -> ListFragment
Without overriding the back button in the toolbar, it simply
kills the entire state on MainActivity and causes it to reload.
By calling finish() on the activity when home is pressed from the
item menu we can silently make it die without affecting any underlying
states held by MainActivity and instead return to the exact fragment
we launched settings from.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
AppCompat is the preferred way to go for any app targetting
a wider range of SDKs.
Replace all activities and fragments with their AppCompat
variants and fixup method calls to use support variants.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Maintain common versions in a single place
Also upgraded the support library to 27.1.1 and
databinding library to 3.1.1.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
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>
