Add F-Droid build flavor.

We need a different build flavor for F-Droid because they forbid
auto-updaters as they download blobs from the internet (and it wouldn't
be possible to install the downloaded APK anyways because of the
signatures mismatch).

I chose to implement this using a build config field instead of using a
per-build-flavor source directory because I thought it introduces less
maintenance burden. In particular, per-build-flavor source directories
would require an interface in the main source directory for the update
manager, which would be implemented for each build flavor in a specific
source directory. Considering this project doesn't have CI builds yet, I
think it wouldn't be wise. Still we might reconsider should we need more
complex setup (such as different dependencies for the two build
flavors). The main downside of the build config field for now is that it
may be more prone to silent regressions.

Fixes #41
pull/111/head
Gilbert Gilb's 2 years ago
parent 7fb2daaa63
commit e1cc03045d

@ -28,6 +28,25 @@ android {
debuggable true
}
}
flavorDimensions "type"
productFlavors {
"default" {
dimension "type"
buildConfigField "boolean", "ENABLE_AUTO_UPDATER", "true"
}
fdroid {
dimension "type"
applicationIdSuffix ".fdroid"
// Need to disable auto-updater for F-Droid flavor because their inclusion policy
// forbids downloading blobs from third-party websites (and F-Droid APK isn't signed
// with our keys, so the APK wouldn't install anyways).
buildConfigField "boolean", "ENABLE_AUTO_UPDATER", "false"
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8

@ -63,6 +63,8 @@ public class AppUpdateManager {
// Return true if should show a notification
public boolean checkUpdate(boolean force) {
if (!BuildConfig.ENABLE_AUTO_UPDATER)
return false;
if (!force && this.peekShouldUpdate())
return true;
long lastChecked = this.lastChecked;

Loading…
Cancel
Save