If we don't find the version name neither in the AndroidManifest.xml nor
in the build.grade file, we fallback to the tag the user specified to
search for.
That way we have a better version name than 'Unknown'.
I was wrong - we don't check for trailing whitespaces on lines. That
would have to happen at parse time, not in the linter, so it would slow
things down and would become an error, not a warning. Not really worth
it.
1. It is packaged in modern versions of distros, update docs accordingly
2. 1.1 is hopelessly outdated - support 1.4 onwards
3. Check the version properly, and write a better config (previously it
wrote the 1.1 config for 1.1 and 1.3+
4. Ensure that the default share from later versions is not present when
building, it's only required for provisioning.
Since we only sorted by count, ignoring the string, it meant that items
with the same count might be arranged in different manners. Hence the
`stats` behaviour was not predictable at all. Now it sorts first by
count, then by string.
It is a good idea in theory, especially for extra tasks specified by the
user. But in practice, tasks specified by developers often don't have a
clean counterpart. So this just breaks the build.
We were passing the utf-8 encoded string to textwrap, which took the
bytes as characters. Hence multi-byte unicode characters (in utf-8)
would count as multiple columns, which is clearly wrong.
This breaks on newer plugin versions. Instead of complicating this logic
even further to support them, upstream devs should instead use gradle
configs that actually work.
If their build fails because of lint, it's theirs to fix, not ours.
This allows us to run checks and fix types only on those that were
really modified. On our fdroiddata repo, with 2k apps with many unset
fields and flags, this reduces readmeta runtime from ~1.3s to ~1.1s.
Avoids typos, such as one I just found which was 'strsng' isntead of
'string'. The static analyzer can catch those if they are constants.
Comparing ints is also faster than strings, which adds up in readmeta.
Only keep lists in metadata files in the json format, since they don't
support multiline strings that are readable.
This makes the internal code easier, and a bit faster.