apkanalyzer produces useful output when it can run, but it does not
support all recent JDK versions, and also some DEX versions, so this
cannot count on it to always produce useful output or even to run
without exiting with an error.
211dd65ff0 was based on false
assumptions that apkanalyzer can always produce output.
fdroiddata!8585
fdroiddata!8584
The .txt format was the last place where the lowercase "builds" was used,
this converts references everywhere to be "Builds". This makes it possible
to load metadata YAML files with any YAML parser, then have it possible to
use fdroidserver methods on that data, like metadata.write_metadata().
The test files in tests/metadata/dump/*.yaml were manually edited by cutting
the builds: block and putting it the sort order for Builds: so the contents
should be unchanged.
```
sed -i \
-e 's/app\.builds/app.get('Builds', \[\])/g' \
-e "s/app\.get(Builds, \[\]) =/app\['Builds'] =/g" \
-e "s/app\.get(Builds, \[\]) =/app\['Builds'] =/g" \
-e "s/app\.get(Builds, \[\])/app.get('Builds', \[\])/g" \
-e "s/app\.get('Builds', \[\])\.append/app\['Builds'\].append/g" \
-e "s/app\['builds'\]/app.get('Builds', [])/g" \
*/*.*
```
A file can be flagged for multiple problems (i.e. multiple unknown maven
repos in one build.gradle file that is included in a scandelete path).
The scanner will try to delete it once for every problem detected, we
don't really care, as long as the file is gone.
fixesfdroid/fdroidserver#759
This ditches the custom common.get_extension() for straight core Python
methods. This should make the code closer to Python conventions. For
example, pathlib also includes the "." in the extension it returns.
This sdk is open source. It was added because appcenter has a dependency
to play-services. It's possible though to build an app using appcenter
that doesn't pull in play services, so we can't blanket ban the sdk.
The appcenter-push modules has obvious refenrences to firebase, so it's
safe to error on that.
Ref: https://phabricator.wikimedia.org/T254980
closes#465
This script generated gradle-maven-blocks.yaml:
```python
import os
import re
import yaml
pat = re.compile(r'\smaven\s*{[^}]+}')
finds = set()
for root, dirs, files in os.walk('.'):
for f in files:
if '.gradle' in f:
with open(os.path.join(root, f), errors='surrogateescape') as fp:
contents = fp.read()
for m in pat.findall(contents):
finds.add(m)
with open('finds.yaml', 'w') as fp:
yaml.dump(sorted(finds), fp, default_flow_style=False)
```
* makes per-build entries in per-app entries
* `fdroid scanner --json --verbose` will output logging messages to stderr
* removed " at line N" from one message to make them uniform keys
* this will be used in issuebot
This is a second attempt with tests for how `fdroid build` calls the
scanner functions. closes#771. It was previously merged in !748 then
reverted in 68c072c72e
* makes per-build entries in per-app entries
* `fdroid scanner --json --verbose` will output logging messages to stderr
* removed " at line N" from one message to make them uniform keys
* this will be used in issuebot
It is now possible to build an app using only things in Debian. Since the
buildserver will always control the contents of file:///usr/share/maven-repo,
it is the most safe repo there is.
These are sourceavailable but not under a free license.
I made sure that this matches only the facebook sdk's from here:
https://github.com/facebook/facebook-android-sdk and not some real open
source libraries by facebook (fresco, stetho, ...). These seem to be
under a different namespace.
fdroid/fdroidserver#534
This lets `fdroid scanner my.package.name` run without requiring that the
versionCode is also specified. It also allows scanner.scan_source() to be
called as a function in the public API of fdroidserver.
This reverts commit 5f5d3ea896.
These new scanner rules for JARs causes most builds on fdroiddata to
break. For example, at least the past 20 releases of
org.fdroid.fdroid. fdroiddata needs to be cleaned up and prepared for
this before we can include 5f5d3ea896
I'm running fdroid scanner on the whole archive now, I'll post the log
to an issue once its done. Ignoring test files would eliminate some
of these build failures, at least for most org.fdroid.fdroid builds.
refs #!325
