PendingInstall means that the user considers the install still in process,
like when F-Droid gets killed in the background. There is unfortunately no
reliable way currently to ensure that removePendingInstall() is called when
the app is finally installed so we can't use it here.
This reverts a small part of 1c50e2891054b629e2af6b2d0b1fc89e0b1cf18b
closesfdroid/fdroidclient#1527fdroid/fdroidclient#1532
This removes a layer of redundancy where there were defaults set in the
Preferences class, as well as in preferences.xml. This makes it possible
for whitelabel versions to change the default values of the preferences by
changing it only in preferences.xml.
"full" is the original F-Droid app with all the features. It should still
build the exact same app after this change. "basic" is the smallest
version of F-Droid possible. It does not yet build, nor work.
This was only partially hooked up and often not even populated.
It was added in 4895e2d790ec3b91fa4271a24e1ea0ae69d362f4, but things have
changed a lot now. We should be moving towards preferring the drawable XML
vector icons, which will scale nicely for all DPIs.
It was already behaving like a singleton, but the code was spread around in
other classes. DBHelper does not use a private constructor though since
the tests prevent it.
While a large buffer might make things slightly faster, the smaller buffer
size should play much nicer when F-Droid is doing things in the background.
Since calculating the hash is part of the update procedure, which can now
happen in the background, this method will be often running in the
background.
The tests showed no difference in time between the large and small buffer.
Note that I don't think the query will work correctly across multiple repos,
because it is currently only querying the app with the "preferred
metadata".
Also use a newer version of testy.at.or.at index for the index-v1 test,
because it includes apks with "KnownVuln" anti features whereas the
older version did not.
This improves performance when we need to decide whether or not apps are
installed or not while scrolling through large lists.
Fixes#1143.
Also change Jackson tests to properly ignore App#isApk.
While investigating #1086 which was about swap being busted, I
discovered that we recently introduced a worse bug when working with
multi sig stuff. The swap process, when installing an app (or even when
listening for if a user started installing - before they even did
anything), would ask for an apk from any repo. This is wrong, because we
should only ask for the apks from the swap repo when presented with a
swap dialog.
By fixing this so that it asks for a specific apk, this may also
fix the issue in #1086, because that was about us not asking for enough
info from the database for each Apk which was returned. Now we just
return all columns, because the performance overhead should be minimal,
but it prevents this class of bugs, where we didn't fully populate
our value object. However, I'm not confident that it is fixed, because I
was unable to reproduce it due to the other crash fixed in this change.
Relevant crash:
```
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String org.fdroid.fdroid.data.Apk.getUrl()' on a null object reference
at org.fdroid.fdroid.views.swap.SwapAppsView$AppListAdapter$ViewHolder.setApp(SwapAppsView.java:311)
at org.fdroid.fdroid.views.swap.SwapAppsView$AppListAdapter.bindView(SwapAppsView.java:422)
at org.fdroid.fdroid.views.swap.SwapAppsView$AppListAdapter.newView(SwapAppsView.java:414)
at android.support.v4.widget.CursorAdapter.getView(CursorAdapter.java:269)
at android.widget.AbsListView.obtainView(AbsListView.java:2349)
at android.widget.ListView.makeAndAddView(ListView.java:1864)
at android.widget.ListView.fillDown(ListView.java:698)
...
```
