RepoUpdater.prepareRepoDetailsForSaving() was broken here because the Repo
properties were being set before calling it, and then the Repo instance was
passed to it for comparison. So the comparison was always saying the value
was unchanged. In IndexV1Updater, the flow doesn't need those checks.
This also fixes the bug where added repos never had their name/description/
icon/etc show up in ManageRepos and RepoDetails.
@cde found this bug working on mirror support, thanks!
related to #35closes#1016
The install process automatically sanitizes filenames to avoid exploits
that put attack code in the filename. Media files are also installed using
this logic, so the installed check needs to use sanitized file names to be
accurate.
Before mult-signature support, the process of marking an app as
installed in the `InstalledAppProvider` didn't have any side effects
beyond its own table. Now, it is also responsible for calculating the
`suggestedVersionCode` of the associated app as well.
This means old tests around suggested versions no longer work. This is
because they would insert an App, and set the
`Cols.SUGGESTED_VERSION_CODE` using a `ContentValues`. This was then
overwritten by the `InstalledAppProvider` asking for the real
calculation for suggested versions. That is - it would check for
relevant apks and figure out which was best.
To make the old tests correct, they need:
* To be able to "install" apps with the correct signature.
* To insert the relevant apks into the database, not just depend on the
presence of an `app`.
Previously, it was only done on repo update.
Now it is done whenever an app is installed or unisntalled. The query to
update the suggested version for each app is quite slow when run at the
end of a repo update. However in this change, we are limiting the query
to only update a single app, which means that performance should not be
a problem.
When a single repo provides apks with multiple signatures, then we need
to be able to select the preferred one. This adds tests for this which
fail, because that feature has not yet been implemented.
This is really the intention of the method, given it used to accept
a version code and a package name. Now it optionally accepts a sig
also. If present, it will restrict the query to apks with that sig.
Also added to the multi-sig tests to ensure this method takes it into
consideration.
There is some magic conversions going on so that booleans get
converted into integers, but they are only on Android. Under
robolectric, it throws a class cast exception instead.
Some were removed and left removed if they were run during tests,
because the tests are supposed to be automated and the noise they added
would not have helped diagnose a failure.
Also removed the dead code around "uses-feature" which will never
get implemented, especially as it is in the XML index.
gitlab's diff views wrap badly when lines are longer than 118. Android
Studio places a grey line in the UI at 120.
@SuppressWarnings("LineLength") is added to a bunch of files to prevent
making this commit huge. People can remove that as they work on those
files, and fix the issues then.
I also ran Android Studio's default Ctrl-Alt-L code formatter, where it was
easy to do, and I was already in the file.
This allows us to test "installing" Adaway, which has a native code
dependency that the default Robolectric setup doesn't support (defaults
to armeabi-v7a).
fdroidserver currently only supports a single WhatsNew field that
comes from the CurrentVersionCode of the app. Google Play and
fastlane supply support a WhatsNew field per-release, but we don't use
that data anywhere, and implementing that in the data structures would
add a lot of complexity since Apk would then need to have its own
"localized" section like App does.
The "Video" field is just a URL pointing to a video.
closes#910
We no longer prefix the list of categories with "Whats New", "Recently
Updated", and "All". The new UI doesn't require this. The only place
they were being used now were in the tests.
This is based on @pserwlyo's work. The App and Apk classes currently
need just the public instance variables auto-filled by Jackson, so
everything else is considered opt-in, via @JsonProperty declarations.
This is currently only used for setLocalized(), setUsesPermission(),
and setUsesPermissionSdk23().
# Conflicts:
# app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
The parser should accept additional elements to each
uses-permission entry, in case more XML attributes is added to
<uses-permission>. <uses-permission> has had two attributes
since the beginning.
Other changes to this JSON data structure are bad index-v1
format, and will cause crashes:
* Removing an element e.g. null from a uses-permission entry
would be invalid index-v1 JSON, since that structure mirrors
the uses-permission AndroidManifest.xml element, which has a
long standing fixed definition of name/maxSdkVersion. That
should crash so that fdroidserver authors know they are
generating invalid index-v1.
* setting versionCode to anything but an int is invalid index-v1
JSON, and should crash. versionCode has been defined as an
32-bit signed integer value since the beginning of Android.
* <uses-permission android:name=""> has been defined as a string
since the beginning of Android.
https://developer.android.com/guide/topics/manifest/uses-permission-element.html
repoId is used in Repo, App, and Apk instances to point to the Repo data
in the database. It does not come from the index files, but rather the
client database.
An important security protection is erroring when the index-v1.jar is
older than what is currently in the database. If the current or older
jar is allowed to be parsed, then a malicious server or
Man-In-The-Middle could replay old version of the index-v1.jar to
prevent the clients from learning about updates that fix security issues
Tell the Jackson JSON parser to ignore App/Apk fields that should never
come from the index, but instead are set locally to keep track of the
current state of things on the device.
There are two forms of tests to enforce that the proper things get
ignored. It is not possible to do this with decorators alone, so I
chose to use @JsonIgnore and leave the variables we want filled in
undecorated. Also, all of the instance variables in Apk/App/Repo
should come directly from the index metadata so that they are pure
data classes. Currently some state info is stored in them, those are
decorated with @JsonIgnore.
The tests then include lists of accepted and ignored properties, and
anything that is not in those lists will cause the tests to fail. So
if someone is adding a new instance variable, they will get a fail
until the tests are updated. One set of tests actually writes blank
instances out as JSON since that's the easiest test to write, and
Jackson treats @JsonIgnore the same in both directions. Then there is
another test that reads a JSON file with added, unsupported values to
make sure that they are properly ignored.
This adds support for parsing the new index-v1.json data as defined in
fdroidserver!221. This new index metadata format is required to
support localization, graphics, screenshots, etc.
refs #15
This is in response to identifying a bug with the way priorities work
with categories. Two repos may both specify different categories for
the same package. In this case, F-Droid should only select the
categories from the highest priority repo. Well, it is not to say that
this is the most preferable option, but it is consistent with other ways
that repo priorities are used.
This is as per the mockup in issue #840, and does the following:
* Adds a new `PreferencesCategory` of "My Apps" at the top of the
preferences screen.
* Adds a "Manage Installed Apps" preference, and moves the
"Repositories" preference into this category.
* Repeals an existing change which prevented "updateable" apps from
appearing in the list of "installed" apps. This is because the two
lists of apps are no longer displayed alongside eachother.
* Enhances the `AppListItemController` to also be able to display
whether or not the currently installed version is the recommended
version or not.
* Also adds option to display whether the user has asked to ignore any
updates for any specific apps.
Not fully featured yet, because it doesn't listen for broadcasts
from the installers, but it is shows the correct list of apps and
allows users to queue up downloads of all updateable apps.
This makes the name of the instance variables in the App class match the
names of the metadata fields in the new fdroidserver .yml YAML format. This
means that the Jackson parser can automatically instantiate instances for
us, which will be more efficient and maintainable.
These names aren't great, but it would a ton of work to rename the field
names in all of the metadata files, the docs, fdroidserver code, etc.
Changed the helpful comments to a Javadoc comment, as tooling such as editors
will be more likely to make use of it like that.
Renamed to emphasise that only trailing new lines are stripped.
Added a basic test for this function to ensure it only strips trailing,
and also that it does actually strip trailing slashes.
Doesn't do anything except create an app with no versions,
no donate links, anything like that, and ensure that the adapter
is able to create the view holders for each resulting item.
In the future we can beef this up to check more exotic conditions,
such as calling `updateItems(App)` with different apps, each
with different combinations of versions, donation links, permissions,
etc.
