This finds maven repos of the format:
maven {
url 'http://foo.bar'
}
And checks if the repository is one that we allow. As usual, scanignore can be
used, or the list modified, if there are exceptions or more repositories to
allow.
* Move apks back from the archive repo (e.g. if builds are disabled thus the
number of apks on the main repo decreases)
* Also move apk signatures back and forth
This allows us to fetch strings like the following:
<string name="app_name">foo <xliff:g>bar</xliff:g></string>
Up until now, using .text would only return "foo ", but if we use .tostring()
with the text method, it converts everything into plain text for us resulting
in "foo bar".
8k is too small, e.g. when make -jN errors or when there are a lot of scanner
errors and warnings. 16k should be better. Also, use "[...]" to make it
obvious that the output is truncated.
Up until now, if it was thrown, fdroid would crash with a full stacktrace as
if the program had stopped unexpectedly. Now it just prints the metadata
error, as intended.
Looks to me like we were using SHA1withRSA all along. Tested that everything
still works with a test repo.
As Hans reports, SHA1withRSA has been the default on Android tools for a long
time and it's supported on all Android versions.
Add asynchronous filereader, fix python3 lockups
with the current implementation of AsynchronousFileReader with Python 3 FDroidPopen deadlocks with 100% CPU-utilization
The code is from https://github.com/soxofaan/asynchronousfilereader
I hope the MIT-Licence makes no problems
See merge request !80
Added support for gradle flavor specific dependencies in usual suspects check
When you have flavor specific dependencies in your project, you specify them in the build.gradle file with a prefixed *compile* command:
```
compile 'normal dependency'
myflavorCompile 'only for myflavor'
```
The usual suspects check just searches for some often used library names in the whole build.gradle file. I added another condition, so dependencies for not build flavors are not checked.
See merge request !77
This is much closer to what we did before with mimetypes. Using a whitelist
turns out to be a bad idea since repositories seem to be randomly filled with
executable images and documents, which trigger the scanner.
In an ideal world the scanner would complain about all of those. For now, just
warn about the possibility of them being hidden binaries.
