Add a new feature to import a tunnel from a saved QR image, this feature
integrates into 'import from file' flow, however adds a condition, if
file is an image, attempt to parse it as QR image file.
My use case for this feature, is to allow easier sharing of tunnels to
family. Scanning QR code is ok when you have an external display to
show it, but if you sent QR code to someone, there is no way to import
it in the app. If you share a config file, that becomes way harder for
a non-technical person to import as now they need to find a file with
that name in the file picker etc etc, Where the images are very visible
in the file picker, and user can easily recognize it for import.
Testing:
- Click "+" blue button, try to import a valid `.conf` file - the
'original' file flow should not be affected
- Click "+" blue button, try to import a valid QR code image - if QR
code was parsed, then a new tunnel will be added.
- Click "+" blue button, try to import an invalid QR code image - Error
message will be shown
Signed-off-by: Nikita Pustovoi <deishelon@gmail.com>
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Fragment scopes get cancelled when the fragment goes away, but we don't
actually want to cancel an in-flight transition in that case. Also,
before when the fragment would cancel, there'd be an exception, and the
exception handler would call Fragment::getString, which in turn called
requireContext, which caused an exception. Work around this by using the
`activity ?: Application.get()` idiom to always have a context for
strings and toasts.
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>
When tunnel deletion is triggered we don't bother with animation theatrics
because the resulting Snackbar needs this fab to be its anchor, which it can't
do if its outside the screen or busy animating.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
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>
When biometric hardware is available, it will be used to authenticate
the user before private keys are shown on screen or when zip exports
are executed.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
