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
fdroidclient now uses SHA256 fingerprints internally, and they are shown in
the repo details view. This changes the digest algorithm to SHA256 and
changes the format to match what is shown in the repo details view.
This assumes that the smartcard is already setup with a signing key. init
does not generate a key on the smartcard, and skips genkey() if things are
configured to use a smartcard.
This also does not touch APK signing because that is a much more elaborate
question, since each app is signed by its own key.
These options are needed to configure Java's keytool and jarsigner to use
a Hardware Security Module aka HSM aka smartcard. The defaults provided
are meant to make things work as easily as possible.
FDroidPopen() does not have a way to send to stdin, so we will use the
password file for now. In the long run, at least the keypass should always
be sent via stdin rather than via a file. Ideally, storepass would be too,
but if they are different, then storepass is less important.
Any process can read the process table, and can therefore see the entire
command line of any other process. That means its a bad idea to ever put
passwords as part of a command line. Python is executing keytool and
jarsigner command lines here, so now instead of putting the password on the
command line, a file is passed instead with suitable file permissions.
This should reduce the exposure a lot. But still, sensitive passwords
should not be written to any text file.
This change requires OpenJDK-7 since the :file option to -storepass and
-keypass was only added in Java 7's keytool and jarsigner.
