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>
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>
After a timeout the android system is destroying the vpn service when it
is not used. By using a completable future we can wait for the service
to be relaunch on demand.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
