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>
- The hand-rolled clean task is not required
- Tasks should use configureEach to prevent eager evaluation
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Fixes: 4f261560 ("gradle: force the use of an older NDK version")
Signed-off-by: L.W.Reek <syphyr@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
- The `copied_to_clipboard` translation for Farsi does not include
the placeholder, so it has been removed.
- A couple lints that are errors but we cannot particularly do anything about
were downgraded to warnings.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Kotlin has been building a new JVM backend for a while now
and it is finally in Beta, scheduled to hit stable in Kotlin 1.4.50.
This is the time to enable it and report any bugs we hit, before it
becomes the default.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Google recommends all dependencies with -ktx variants depend on them directly since they transitively pull in the main artifacts and offer extensions for better usage from Kotlin
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
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>
The tunnel/ module still uses it and exposes it as an "api", but nothing
inside of ui/ should be using it now.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This contains a share button and a save button, the former using a
custom content provider.
Co-authored-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Since the signing config is also stored in the project root it makes sense to have storeFile
path be relative to it.
Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
Hacking things up via gradle is not right, and package-info.java poses
problems with two modules, so instead we just apply it manually to every
class.
Remember to add this to new classes!
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld