Remove LITERAL_DO from the config in RightCurly as we want this:
do {
foo;
} while (bar);
Not this:
do {
foo;
}
while (bar);
This went unnoticed as LITERAL_DO was broken in RightCurly in earlier
Checkstyle versions.
Also change the overrides from onCreate to init as suggested in the
changelog:
https://github.com/ACRA/acra/wiki/ChangeLog#acra-490-rc-1-2-may-2016
The behaviour should be very similar, although overriding the wrong
method (which we were doing) could cause all sorts of weird issues.
Those that are sometimes false positives but could still point out valid
issues should be warnings, not disabled entirely.
The first two are warnings already, the third is an error.
The spongycastle issue is taking a long time to get resolved, has not yet
affected us, and would be a lot of work to fix in a different way. So the
'InvalidPackage' error is just disabled for now.
To appease PMD, we now have a three rulesets in `config/pmd/*.xml`:
* `rules.xml`: The bulk of the rules, used by both main and test code.
* `rules-main.xml`: Rules specific to the andoid client code.
* `rules-test.xml`: Rules specific to test code.
The rationale is because checkstyle by default checks for "too many static
imports", which is a fair call. However in JUnit4 code, it is common to
import many `assert*` static methods.
Get around silly `final` methods in `ContentResolver` with Mockito and `delegatesTo`.
The Robolectric library presumes that people always want to test content providers by
manually invoking the `query`/`update`/`delete` methods on the `ShadowContentResolver`.
While that is a great feature for testing, we have helper methods that require testing,
and these methods accept either a _real_ `ContentResolver` or `Context`. Robolectric
did some cool magic in terms of intercepting runtime calls to content resolvers and
forwarding them to the "shadow" verison, to deal with final/package private/etc methods.
However, as a side effect, the `ShadowContentProvider` _is not a `ContentProvider` as
far as the Java compiler is concerned.
By utilising Mockito + `delegatesTo` method, we are able to achieve what is required:
* An actual `ContentProvider` instance.
* It forwards calls to the `ShadowContentProvider` provided by Robolectric.
Robolectric provides testing support for Android via the JVM, including testing
of content providers. In order to get these tests to work, we need to avoid
the default behaviour of starting up FDroidApp.onCreate(). This method has a lot
of static state which fails if set multiple times. Instead of trying to ensure
we correctly zero out that state each test, it is preferable to instead never
bother with that in the first place. Expecially when that is not what is under
test (as is the case with content provider tests).
Check repo index timestamps
The Update Framework documents provide a [nice discussion of possible attacks](https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md) against update systems. One example is a "rollback attack", where the attacker just serves the old signed `index.jar` to keep all clients from updating their apps. That allows the attacker to exploit known vulnerabilities in those un-updated apps.
While this is a reasonably hard attack, this fix is an important step towards removing the requirement for trusting the web server operator. Ultimately, it should be able trusting the index signing key only. Then it doesn't matter were the files come from, it just matters that they are verifiably signed by the index signing key.
This does not address "freeze attacks" since it allows an index update with the same timestamp. I did that deliberately to slowly ramp up the security checks in order to avoid problems along the way. Code-wise, blocking freeze-attacks is mostly a matter of changing the timestamp check from `<` to `<=`.
See merge request !302
This makes it easy to tell which debug build a device is running, since the
versionName now automatically describes the exact commit that was built,
based on `git describe`, e.g.: 0.100-alpha7-33-gc2e8e8a
For release builds, i.e. builds from commits that are tagged as releases,
the versionName will be just the tag name: 0.100-alpha8
closes#664https://gitlab.com/fdroid/fdroidclient/issues/664
This used to be the case, which is why only minimal changes were
required to bring it back. This also makes it take the same files that
checkstyle does, which is more consistent.
This release allows for Android 6+ support, but we'll need to ask for
permissions at runtime too. This commit simply does one half of the work
needed to support Android 6 with all things wi-fi.
See the issue and example app commit for reference:
https://github.com/mvdan/accesspoint/issues/66284f0376b
Also add useProgard true, since minifyEnabled now refers to the new
experimental code shrinker.
I'm not removing proguard yet as we depend on it for the samsung
workaround. I also do not know how to port the rest of the config
options to the new shrinker.
Android recently switched from JUnit 3 to 4 for its base testing classes.
It doesn't seem to support the old JUnit3 methods with gradle and AS. So
all the tests need to be ported to JUnit4 to work again.
#607https://gitlab.com/fdroid/fdroidclient/issues/607
'src' works because we're only doing java files under that directory.
But it would be slower than needed, and in the case of PMD it would also
use the test files which wasn't intended at all.
It seems like having it as a compile dependency already works for the
tests. Having it duplicated seems to sometimes trigger errors (e.g. a
user reported a duplicate zip entry due to the duplication) and might
also be problematic if we don't keep the two versions in sync.
This makes it so gradle provides all dependencies, rather than a mix of
classes that are copied in versus imported via gradle. This library is
already used by the tests, so its not really a new dependency, and proguard
should remove all the unused stuff.
This makes it a lot easier to setup all the testing stuff. Mostly,
I'm tired of fighting Android Studio's fragility, so I want to remove
as much non-standardness as possible in the hopes of improving that
situation.
closes#534https://gitlab.com/fdroid/fdroidclient/issues/534
