By not setting sdk_path when /usr/bin/aapt is found, sdk_path then defaults
to $ANDROID_HOME when its used. Since in this case, aapt will be used from
the system path, using aapt entirely ignores sdk_path. If the user runs
`fdroid build` in this setup, sdk_path will be $ANDROID_HOME, so it should
check the env vars for it, but maybe that doesn't actually work like that
yet.
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/
Done after verifying that they match ones built using a recipe.
Everything in the metadata should be the same as normal, with the
addition of the Binaries: directive to specify where (with pattern
substitution) to get the binaries from.
Publishing only takes place if there is a proper match. (Which seems
very unlikely to be the case unless the exact same toolchain is used, so
I would imagine that unless the person building and signing the incoming
binaries uses fdroidserver to build them, probably the exact same
buildserver id, they will not match. But at least we have the
functionality to support that.)
* Default paths are not expanded
* When writing to config.py in "fdroid init", don't write expanded paths
either
* Support changes in e.g. $ANDROID_HOME after a config.py is generated thanks
to the fix above
Reasons:
* Cloning a svn repo via svn doesn't fetch the entire history
* Svn checkout is incredibly slow
* Svn doesn't have important features such as a 'clean' command
The only reason why we kept svn was for anonymous logins to repositories. This
is no longer a reason since git-svn also supports them.
This gives us flexibility in how the blocks of text can be formatted in
config.py, but also provides a more useful format for displaying since the
client can decide where to wrap the text.
'set-head origin --auto' fails if there are multiple branches that are the
same as origin/HEAD:
error: Multiple remote HEAD branches. Please choose one explicitly with:
git remote set-head origin develop
git remote set-head origin master
So we want to grab any of them, e.g. the first branch that it gives us, and
just use that as it will work just fine.
This reverts b637568a62 since it added a
redundant check that broke `fdroid init` when the default version dir of
build_tools does not exist on the local system. It then uses the function
that was already in place for checking the build_tools setup in a way that
does not break `fdroid init`.
Now that the fake android home version is not matching the default version,
the tests will catch this bug in the future.
To support a fully offline build/signing machine, there is the "local copy
dir". The repo is generated on the offline machine and then copied to a
local dir where a thumb drive or SD Card is mounted. Then on the online
machine, using `fdroid server update --sync-from-local-copy-dir` allows
the whole server update process to happen in a single command:
0. read config.py on online machine's repo
1. rsync from the local_copy_dir to the current dir
2. copy to serverwebroot, awsbucket, etc.
Test updates and related bug fixes
I just set up some big tests of generating repos based on feeding as many random APKs into `fdroid update` as possible. On our jenkins server, the tests copy all of the APKs that the jenkins server has generated and builds a repo from them. This process caught lots of little glitches in the whole process. While these little glitches are usually caused by problematic APKs, `fdroid update` should handle them gracefully. Hopefully this set of fixes accomplishes that.
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.
Make sure that fdroid can find aapt in the current config, otherwise exit
with an error. Some users don't have build_tools set, and their SDK does
not include the build-tools in the default versioned dir, so this should
warn them of what is wrong.
Use --verbose if you really want a full traceback with your 'you made a
typo in an package ID' messages.
It would be better to do this based on exception types (i.e. our own
exceptions - MetadataException, BuildException, VCSException) would not
print a traceback, but unexpected exceptions would. But the types are
not available at the 'fdroid' level currently.
* 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
This allows the user to set the path to their Android SDK from the command
line. This option is named after the standard env var ANDROID_HOME, as used
in the build.xml generated by `android update project`. --android-home
takes precendence over the ANDROID_HOME env var if it is set.
`fdroid init` runs before any config.py exists, but it still needs to have
the default config and the SDK path tests. So split those two bits out of
common.read_config() so that they can be run separately before config.py
is in place.
The .fdroid.*.txt password files are only meant to be a conduit for the
passwords, so blow them away everytime. The canonical password is stored
in config.py.
It might makes sense to replace these files with env vars using
-storepass:env and -keypass:env. I figured that the passwords are already
in a file, config.py, so adding more files in the same location with the
same perms would not increase the risk at all.
* Group apk, jar and zip files in the same case
* Use regex to support more patterns and be more flexible
* Only check for usual suspects in jar files (saves time)
* Also catch unknown zip-like files as warnings
