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.
This will be more important as people work with media, since it is quite
common to use spaces in filenames generated by humans. Media files will
not be built by fdroid, so most likely, they will have human-generated
names.
* This installer is invoked when for non-apk/media files, and
copies them to an appropriate folder on the sdcard.
* We also introduce a FileInstallerActivity to ask for storage
permissions at runtime, as needed by Android 6.0 and above,
and handle the install/uninstall process.
* A toast is shown with the install path after installation.
TODO:
* Manage Installed Apps screen doesn't show media files.
* For non apk files, the signature column would be NULL always,
and in SQLite NULL = NULL is false, but NULL IS NULL is true.
See http://www.sqlite.org/lang_expr.html Operators
If an app is downloaded into our cache, but an app with the same hash is
already installed, don't bother notifying people about it.
Extracted the logic for finding the path to an apk on disk (given a
PackageInfo object) to also be used by AppUpdateStatusSerice.
Change logging so that if we discard a downloaded file we Log.i instead
of Utils.debugLog. This is so that when debugging a release build we can
see what is happening, because this specific problem was easier to debug
with release builds (rather than setting up a custom fdroid repo).
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.
This is a conservative fix. If we wanted to really highlight the
feature graphic functionality and reward upstream devs for keeping
metadata up to date, then we could also take apps which were recently
updated, and prioritise them over new apps if they have a feature
graphic.
Fixes#938.
Also fixed display of feature graphic in main screen by getting full
path to image, not the relative path (e.g. "en-US/featureGraphic.png").
This creates a hard dependence between `RepoUpdater` and
`UpdateService`. However this could be trivially extracted by moving the
helper methods from `UpdateService` to `RepoUpdater`, and making the
broadcasts more "repo updater" oriented. That would also require
changing the broadcasts which `UpdateService` listens for.
Reuses the "commiting" message to indicate how many apps have been
processed so far.
Refactors existing progress handling between `RepoUpdater` and
`UpdateService` to use `LocalBroadcastManager` in preference to
`ProgressListener`. Still needs to use `ProgressListener` to talk
between `RepoUpdater` and the `Downloader` +
`ProgressBufferedInputStream`.
The only change that is related to something more important than
notifications is the fact that now `IndexV1Updater` makes use of the
`indexUrl`. To do so, because it is final, the base class constructor
delegates to `getIndexUrl()` which is overriden by the v1 updater.
This is required because we want to differentiate between broadcasts
coming from different repo update processes.
Fixes#1054.
This was setup to work correctly, but for two problems:
* The `cursor.close()` in `CategoriesViewBinder` stops the cursor from
being requeried when required.
* The `AppProvider` was not notifying correctly after deleting apps
belonging to a repo.
Fixes#1028.
Moved methods around so the class is more coherent when reading from top
to bottom.
Added some comments.
Formatted lines to be under 120 chars. No longer suppress line length checkstyle messages.
This breaks out subclasses for each specific type of app list item,
allowing for code reuse, but also letting the specific business logic
belonging to each different app list item to be separate.
This is particularly helpful in the following situation:
* In the search results, it is great to be able to render "App
downloaded, ready to install" in the same manner as the update tab.
* In the installed app list, this is not desired. Indeed, the status
text which should be shown should reference the currently installed
version and whether the user has ignored any updates.
By separating the AppListItemController into subclasses, it reduced the
need to handle several different types of text view (e.g.
"installedStatus", "status", "ignoredStatus", "downloadReady"), and
replace them all with a "status" and "secondaryStatus" TextView. What is
displayed in status and secondaryStatus is up to the individual
subclasses of AppListItemController.
Previously, there were different pieces of business logic, invoked at
different times, which would touch subsets of the UI.
This change rips that out, and replaces it with a single place where the
UI is setup. This can always be called safely, and it will render the
correct data for the current state of the app (e.g. downloading, waiting
for install, etc).
The AppListItemState class is a dumb object which keeps track of what is
supposed to be displayed in the UI. The AppListItemController now
creates a different AppListItemState depending on what state the list
item is in. This AppListItemState is then used to bind the values of
each UI widget.
All of the binding code is now in the single `resetView()` method, but
all of the business logic for what the view should look like is
separated into different `getViewState*()` methods.
This separation should make it easier to make sense of the UI code, and
hopefully should be testable should somebody choose to write tests for
it in the future.
The docs say that initLoader tries to reuse existing cursors.
The error message was "IllegalStateException: attempt to re-open an
already-closed object: SQLiteQuery: ...".
There may be a bigger problem around suggested versions being null at
all, but that is getting looked at in a different feature set (i.e.
multi signature support) and will come in time. This fixes the immediate
problem some people were having and sending crash reports for in 0.104.
STACK_TRACE=java.lang.NullPointerException: Attempt to read from field 'java.lang.String org.fdroid.fdroid.data.Apk.versionName' on a null object reference
at org.fdroid.fdroid.views.AppDetailsRecyclerViewAdapter$HeaderViewHolder.bindModel(AppDetailsRecyclerViewAdapter.java:425)
at org.fdroid.fdroid.views.AppDetailsRecyclerViewAdapter.onBindViewHolder(AppDetailsRecyclerViewAdapter.java:244)
at android.support.v7.widget.RecyclerView$Adapter.onBindViewHolder(RecyclerView.java:6310)
at android.support.v7.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:6343)
...
Introduced in 97fd3f0.
* F-Droid cannnot uninstall system apps, only their updates,
but even with the privileged extension, that can get complicated.
* Let's just not allow uninstalling system apps, the phone's settings
app can happily disable/re-enable system apps, and also uninstalls
their updates on disabling.
If the client fails due to some bug in handling index-v1.jar, then it will
be totally stuck, even if index.jar would have worked. This creates a new,
temporary "expert" preference to force the client only use the old XML
index file. Worst comes to worst, we can tell people to enable this to
upgrade.
Once everything proves stable, we can remove this.
... when PackageInstaller is the installer (privext).
* In the case where the Privileged Extension is installed,
but the installation happens through DefaultInstaller still
due to something like a permission mismatch,
that is set as the installer package name.
* We cannot install packages installed by that via the system methods,
so fallback to DefualtInstaller for uninstalling as well when the
app is installed by PackageInstaller
The fact that Cursors are used with the apk provider is more of an
implementation detail (to some extent). It is a crappy, leaky
implementation right now, but still an implementation detail.
This should probably be done on the database level, if purely for the
fact that we have a good set of unit tests for that. However it is still
quite clean to do so here.
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.
The main problem is that we were using an index on fdroid_apk.vercode,
when it should have been using an index on fdroid_apk.appId. There are
thousands of apks which would match based on vercode, but only two or
three which match based on appId. This improves performance of the
calculate-suggested-vercode query from 25,000ms to 100ms.
Produces the following output:
D Explain:
D SCAN TABLE fdroid_app
D EXECUTE CORRELATED SCALAR SUBQUERY 0
D SEARCH TABLE fdroid_apk USING INDEX apk_vercode
D EXECUTE CORRELATED SCALAR SUBQUERY 1
D SEARCH TABLE fdroid_app AS innerAppName USING INTEGER PRIMARY KEY (rowid=?)
D EXECUTE CORRELATED SCALAR SUBQUERY 2
D SEARCH TABLE fdroid_package AS pkg USING INTEGER PRIMARY KEY (rowid=?)
D SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)
There are two possibilities here, one is the number of correlated sub
queries (three seems a bit excessive). Alterantively, it could be the
fact that one of the inner queries is using a string index (appId=?)
instead of an integer primary key.
