'ndk_paths' will be automatically filled out from well known sources
like $ANDROID_HOME/ndk-bundle and $ANDROID_HOME/ndk/*. If a required
version is missing in the buildserver VM, it will be automatically
downloaded and installed into the standard $ANDROID_HOME/ndk/
directory. Manually setting it here will override the auto-detected
values. The keys can either be the "release" (e.g. r21e) or the
"revision" (e.g. 21.4.7075529).
https://developer.android.com/studio/projects/configure-agp-ndk#agp_version_41
* sdkmanager installs "ndk;12.3.4567890" into $ANDROID_SDK_ROOT/ndk/
* sdkmanager installs "ndk-bundle" into $ANDROID_SDK_ROOT/ndk-bundle/
There are two version numbers used for NDKs: the "release" and the
"revision". The "release" is used in the download URL and zipball and the
"revision" is used in the source.properties and the gradle ndkVersion field.
Also, there are some builds which need multiple NDKs installed, so this
makes it possible to have a list of release/revision entries in build.ndk.
This does not yet add full support since _fdroidserver/build.py_ will also
need changes.
Before, whenever an unsigned APK failed to reproduce, it was just deleted.
That makes debugging hard. This makes it keep the unsigned APK, which is
written in tmp/ when using --test.
@jspricke this is related to !864
We switched to apksigner in 50f0534d but old apks where still verified
with jarsigner (or an old apksigner version). Bumping the
METADATA_VERSION to force a rebuild of apkcache.
Hopefully this resolves de.chagemann.regexcrossword getting the
KnownVuln, DisabledAlgorithm tags.
https://jenkins.debian.net/job/reproducible_fdroid_test/422https://jenkins.debian.net/job/reproducible_fdroid_test/423
```
Traceback (most recent call last):
File "../fdroid", line 22, in <module>
fdroidserver.__main__.main()
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/__main__.py", line 227, in main
raise e
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/__main__.py", line 208, in main
mod.main()
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 2316, in main
apks, cachechanged = process_apks(apkcache, repodirs[0], knownapks, options.use_date_from_apk)
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 1746, in process_apks
use_date_from_apk, ada, True)
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 1619, in process_apk
apk = scan_apk(apkfile)
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 1385, in scan_apk
scan_apk_androguard(apk, apk_file)
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 1527, in scan_apk_androguard
resource_id = arsc.get_id(apk['packageName'], icon_id)
File "/usr/lib/python3/dist-packages/androguard/core/bytecodes/axml/__init__.py", line 1668, in get_id
self._analyse()
File "/usr/lib/python3/dist-packages/androguard/core/bytecodes/axml/__init__.py", line 1321, in _analyse
ate = self.packages[package_name][nb + 3 + nb_i]
IndexError: list index out of range
```
Implemented as a fallback solution when parsing settings.gradle
and globbing the build dir with "'*', 'src', '*', 'play'" did not
yield results.
Before, the logic would not find triple-t metadata in projects where
settings.gradle is in a subdirectory or 'src' is found at a directory
depth != 2.
Closesfdroid/fdroiddata#2295
This is a vestige of implementing builds from a .fdroid.yml file directly
in the app's source repo. It was never fully complete and seems to not be
used in any apps in fdroiddata. This makes `fdroid build --all` runs much
faster since it does not need to do any git handling for apps that do not
have any new builds to run.
4e8e29794948689281a4e431080e37be9b06e775d330c
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
