Since version 1.1.0, setDefaultNightMode now takes care of that. Also,
set the initial mode in a blocking fashion to prevent flashing white.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This change lets us use the same build for F-Droid, Play Store, self
builds, and elsewhere, which makes everything more easily publicly
verifiable, since the build system is reproducible. That means that all
APKs will have the same code and be completely interchangeable, no
matter where they come from.
It does this by removing the build-time branch for special Play Store
builds, and replacing it with a simple runtime check using the
PackageManager APIs that return the name of the installer. If the app is
installed by "com.android.vending", then it's a Play Store install.
It's possible to test this with:
$ pm install -i com.android.vending path/to/package.apk
And it appears to work well.
One potential concern is that it's unclear whether the Play Store
reviewers install the app using utilities that set com.android.vending
like this. If not, that might be a problem. However, it looks like
various banking apps also use the installer package name check in the
same way, and refuse to start if it's not right. That suggests that it
would be impossible for Play Store reviewers to even review those
banking apps if they did not set com.android.vending properly.
Out of an abundance of caution, though, and in order to avoid a Play
Store suspension that's harder to appeal, I sent a support request
today (which just managed to fit exactly in the 1000 character limit):
Hi,
My app pays special attention to Google Play Store guidelines. For that
reason, there is some code in the app that looks like this:
if (BuildConfig.IS_GOOGLE_PLAY)
...
else
...
This means that I compile two versions of my app, one for Google Play,
and another for other app stores. This has worked well for many years
and it satisfies Google's policy requirements.
However, compiling two versions of my app is a bit of a pain. Instead, I
would like to do this check at runtime, with code like this:
if (pm.getInstallSourceInfo(package).installingPackageName == "com.android.vending")
...
else
...
I have tested that this code works well, and I've installed my app with:
$ pm install -i com.android.vending ui-release.apk
This works and successfully satisfies the policy requirements.
My question is how this works during the review process. Are reviewed
apps installed with the necessary -i com.android.vending switch to make
this work?
Thanks.
They responded fairly quickly:
Hi Jason,
Thanks for contacting the Google Play team.
Unfortunately I'm not able to comment on your planned implementation. If
you think your app is in compliance, please submit your app for review.
You may want to review the Developer Program Policies for additional
policy guidance.
We recommend reviewing the details listed in this blog post and update
your app accordingly to comply with the changes.
Thanks for your understanding and continued support.
Regards,
Mia
Google Play Developer Support
So I'll interpret that as a, "if you think it's okay, submit it and see,
and then we'll let you know." So here we go. Hopefully if it is
rejected, the update will only be blocked, and I'll just revert this
commit and resubmit.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
All of the parcelers have their own type prefix. So we have to actually
use the legit methods. This is a bit annoying, as there's no fully
compatible way across all API versions, so we have to branch.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Exception java.lang.IllegalStateException:
at androidx.fragment.app.FragmentStore.addFragment (FragmentStore.java:92)
at androidx.fragment.app.FragmentManager.addFragment (FragmentManager.java:1481)
at androidx.fragment.app.BackStackRecord.executeOps (BackStackRecord.java:387)
at androidx.fragment.app.FragmentManager.executeOps (FragmentManager.java:1965)
at androidx.fragment.app.FragmentManager.executeOpsTogether (FragmentManager.java:1873)
at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute (FragmentManager.java:1823)
at androidx.fragment.app.FragmentManager.execPendingActions (FragmentManager.java:1760)
at androidx.fragment.app.FragmentManager$5.run (FragmentManager.java:547)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:268)
at android.app.ActivityThread.main (ActivityThread.java:8101)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:627)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:997)
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Exception java.lang.IllegalStateException:
at androidx.fragment.app.Fragment.requireContext (Fragment.java:967)
at com.wireguard.android.fragment.TunnelListFragment$tunnelFileImportResultLauncher$1$1.invokeSuspend (TunnelListFragment.kt:64)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run (DispatchedTask.kt:104)
at android.os.Handler.handleCallback (Handler.java:761)
at android.os.Handler.dispatchMessage (Handler.java:98)
at android.os.Looper.loop (Looper.java:156)
at android.app.ActivityThread.main (ActivityThread.java:6617)
at java.lang.reflect.Method.invoke
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:832)
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This required some weird changes to prevent clipping on the top, because
apparently the new switch is a bit fatter.
I think this actually looks a bit uglier than before, but it seems like
that's what Material design wants. Maybe we can improve it?
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
I'm not sure why that comment (Samuel's) was there saying it was
necessary. Given it's been async for a long while, this wasn't
guaranteed anyway. So let's get rid of it and see what happens. Screen
rotation seems fine thus far.
Cc: Samuel Holland <samuel@sholland.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise, for lots of apps, the dialog shows before they're enumerated,
and the button text never gets set.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The TV theme has been kept as-is since Material You guidance around this
is a bit scarce at the moment.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
This check was added in 3c31c340d8 when the kernel module loader was
introduced into the app lifecycle, to avoid attempting to start a root shell
twice. When the module loader was removed in a03ad51622, this flag
was accidentally left in when it should have been deleted.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
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>
Nathan Chance dropped the ball repeatedly and never maintained this in a
consistent way that anybody could use. With Android 12 out now, just
drop it all together. A bummer, but I don't see much of a choice.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
wg-quick has supported this for a while, but not the config layer, and
not the Go backend, so wire this all up.
Requested-by: Alexis Geoffrey <alexis.geoffrey97@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This has several problems: 1) it blocks the main thread; 2) it doesn't
distinguish between a permanent error and a transient one; 3) the 10
seconds is hard coded; 4) there's no way for the user to cancel it.
We'll have to improve this.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld