This is a more flexible approach than testing for the complete SDK and
build-tools up front. This will only test for the commands that are
actually being run, so that if you only have `aapt` installed, you can do
`fdroid update` without errors, but other commands will still give
appropriate errors.
This also makes the build_tools item in config.py optional, it is only
needed if you want to force a specific version of the build-tools.
I wrote up the feature to automatically generate symlinks with a constant name
that points to the current release version. I have it on by default, with a
*config.py* option to turn it off. There is also an option to set where the
symlink name comes from which defaults to app['Name'] i.e. F-Droid.apk, but
can easily be set to app['id'], i.e. _org.fdroid.fdroid.apk_. I think the best
place for the symlinks is in the root of the repo, so like
https://f-droid.org/F-Droid.apk or https://guardianproject.info/fdroid/ChatSecure.apk
For the case of the current FDroid static link https://f-droid.org/FDroid.apk
it can just be a symlink to the generated one (https://f-droid.org/F-Droid.apk
or https://f-droid.org/org.fdroid.fdroid.apk). Right now, this feature is all
or nothing, meaning it generates symlinks for all apps in the repo, or none. I
can’t think of any problems that this might cause since its only symlinks, so
the amount of disk space is tiny. Also, I think it would be useful for having
an easy “Download this app” button on each app’s page on the “Browse” view. As
long as this button is less prominent than the “Download F-Droid” button, and
it is clear that it is better to use the FDroid app than doing direct
downloads. For the f-droid.org repo, the symlinks should probably be based on
app['id'] to prevent name conflicts.
more info here:
https://f-droid.org/forums/topic/static-urls-to-current-version-of-each-app/
By using jarsigner here, we can get rid of getsig.java, since the rest of
what getsig.java does can easily be handled in python. This simplifies
installation and deployment, and makes things work better cross-platform.
This also means that the fdroidserver Debian package no longer needs to
Build-Depends: on default-jdk, which makes builds in pbuilder run a lot
faster. :-)
refs #5https://gitlab.com/fdroid/fdroidserver/issues/5
Before, if repo_icon or archive_icon pointed to a non-existent file, then
`fdroid update` would run through the whole process of building a repo,
then fail at the very end because of the non-existent file. On the next
run, `fdroid update` then starts from the beginning.
This just checks for those files at the beginning, and exits with an error
if they are not found.
It is not necessarily a good idea to try to distribute system APKs via
FDroid, but `fdroid update` should just ignore APKs it cannot handle rather
than die and prevent a repo from being fully created. This is necessary to
handle the automatic creation of repos, like for debug builds from a
Jenkins server.
Using this example app which does not have <uses-sdk>:
https://android.googlesource.com/platform/development/+log/master/samples/ApiDemos/assets/HelloActivity.apk
aapt then returns "sdkVersion:'IceCreamSandwich'". minSdkVersion is only
ever supposed to be an integer, so this is a bizarre APK. It is included
only as a binary in the git repo for Android sample code. But who knows
what else is out there, so report and error and carry on with the update
process.
Some APKs can be corrupt or some system APKs do not have all the normal
info. Instead of quitting, `fdroid update` skips the non-parsable APKs and
optionally deletes them if --delete-unknown is specified.
FDroidPopen outputs by default, this should be controlled by the --verbose
flag so that most of the time, only meaningful messages are shown like
errors and such. For command output that should be shown everytime,
output=True can be set.
Since the new metadata created by -c is added after the existing metadata
was already parsed, `fdroid update -c` was not doing a complete update of
the repo. This moves the metadata creation as early as possible, then
reruns the metadata parsing if new metadata was created.
refs #12https://gitlab.com/fdroid/fdroidserver/issues/12
This adds the option --delete-unknown for the current default behavior of
`fdroid update`: to delete any unknown APKs. Instead, it just outputs a
warning about the unknown APKs and suggests -c for adding it.
Fixes#8https://gitlab.com/fdroid/fdroidserver/issues/8
* E124 closing bracket does not match visual indentation
* E125 continuation line does not distinguish itself from next logical line
* E126 continuation line over-indented for hanging indent
* E127 continuation line over-indented for visual indent
* E128 continuation line under-indented for visual indent
