The versionName is defined as a string or string resource that can be any
arbitrary data. fdroid should not second guess the developer here, and
should just use the versionName unmodified. For anything that needs to
compare different versions of apps, versionCode should always be used since
that's what Android uses.
https://developer.android.com/guide/topics/manifest/manifest-element.html#vname
Support media files
This is the first step in supporting adding artibitrary files to fdroid repos, targeted add supporting media files and flashable _update.zip_ files like used to install the Privileged Extension. This reuses the existing metadata fields to keep compatibilty with older versions, but that means that lots of names are confusingly named since they refer to aspects of an APK rather than a generic file. We can address that later when we refactor the whole index metadata.
See merge request !177
This adds the most basic level of support for including arbitrary files in
an F-Droid repository. This is useful for things like including videos,
ebooks, update.zip files for ROM updates, and more. The aim is to have
this as generic as possible to keep it flexible for unforeseen uses.
Code-wise, this is really just a first effort. This area of code has not
been touched in a very long time, and the repo parsing is done in a giant
function that is not easy to break apart. It should be broken up to more
cleanly support arbitrary files.
Also remove the TODO line, we've decided to keep the old permission
format for now, at least until there is a major overhaul of the index
data format. And the issue tracker the proper place for TODOs.
buildserver fixes on the way to KVM
Here are a couple of relatively basic fixes I found while working on the KVM support (merge request coming soon).
See merge request !174
No point in running any other code if the script is just going to bail
out with an error. This assumes that ./makebuildserver is only ever
run from a git clone of fdroidserver.git.
Reproducible via `fdroid checkupdates --auto subreddit.android.appstore`
at fdroiddata HEAD (e76449ab).
WARNING: ...subreddit.android.appstore : Couldn't find package ID
CRITICAL: Unknown exception found!
Traceback (most recent call last):
File "/home/mvdan/.bin/fdroid", line 147, in <module>
main()
File "/home/mvdan/.bin/fdroid", line 124, in main
mod.main()
File "/home/mvdan/git/fsr/fdroidserver/checkupdates.py", line 571, in main
checkupdates_app(app)
File "/home/mvdan/git/fsr/fdroidserver/checkupdates.py", line 469, in checkupdates_app
if int(build.vercode) >= int(app.CurrentVersionCode):
TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
VirtualBox runs as the same user as `fdroid`, so the cache does not need to
be accessible by the world. On libvirt, libvirtd runs the VMs as its own
user, so in that case, the cache dirs must have permissions to let that
user access them.
buildserver running in qemu/kvm to support KVM on KVM
jenkins.debian.net runs in QEMU/KVM instances, so in order to run the F-Droid buildserver there, it needs to work inside of a KVM guest. The best way I found to do that is to create QEMU/KVM instances via KVM's "nested" virtualization support. This collection of commits enables using QEMU/KVM as the buildserver when `./makebuildserver` detects that it is running inside of KVM. Otherwise, the old behavior is default: running in VirtualBox.
I have run these tests inside of ubuntu/16.04 on bare metal, which uses VirtualBox, and ubuntu/16.04 KVM guest, which uses QEMU/KVM. It'll also run on the Guardian Project jenkins box, which is Debian/jessie.
@mvdan @CiaranG @krt
See merge request !168
I think the `android update sdk` tool is installing all of the m2 files
that are present in the temp cache, and it seems to do it in order of
newest to oldest. Well done, and I thought that tool couldn't get any
worse. So only include the latest version of android_m2repository*.zip in
the temp cache.
For running in QEMU/KVM guests like on jenkins.debian.net, this sets up the
whole process automatically. This only really covers the case where this
is running in a KVM guest, and the original case of running VirtualBox on
bare metal. It could be extended to cover more cases if someone wanted to.
The Android SDK by default includes some Google repositories of their
proprietary SDKs. We of course do not want that stuff ever. We also do
not need the emulator images since this process does not currently install
or run an emulator.
