ndk_paths is set up right after installing the NDK and right before
ndk_paths is used in Build.ndk_path().
A proper NDK install always has a _source.properties_ which declares
the revision and release strings. That is used as the source of
revision and release. This only reads from the local filesystem, and
reads the official source of version info (_source.properties_),
thereby avoiding any potential network calls that sdkmanager might
do. This implementation was inspired by @uniqx's:
ed931d47d7 (27b997d583cd1c0a05b2213437e0d9fe6536bfe3)
When walking through the repo, there may be another settings.gradle in a
sub project with a different catalog. In the subdir the catalog of the
sub project shuold be used and in other subdir the catalog of the root
project should be used.
allowlist and blocklist are much clearer terms with no cultural baggage.
This changes all "whitelist" references to "allowlist", and all "blacklist"
references to "blocklist".
com.github.jameshnsears.quoteunquote defines flavours 'fdroid' and
'fdroidS'. The old code used flavour in line, which matches both and the
wrong one was selected.
Closes: #912
These days, the location that overrides all the others is in the android{}
block of the build.gradle file that loads the com.android.application
plugin. So this should be the preferred place to read these values.
test files GPL licensed: https://github.com/Integreight/1Sheeld-Android-App
This addresses the discussion in !64https://gitlab.com/fdroid/fdroidserver/merge_requests/64
Sometimes, buildToolsVersion is a kind of gradle macro call, and other
times it is a variable assignment. This regsub pattern now handles both of
those cases.
