Also, add code to AppDetails2 to match AppDetails, keeping track of
currently viewed app. Moved the nulling of this info to onStop instead
of onPause, since alerts may be shown on top of the details page, while
still visible.
The `setApkInternal` method had to infer the intent of the caller
based on the arguments which were passed on, and then do specific
things depending on the input. Instead, this change has three
distinct actions which can happen (add/remove/update). Each of
these methods does only one thing, and doesn't have to guess
the intent of the caller. The only exception may be "add", which
will (for convenience) delegate to "update" if it already knows
about the apk in question.
The only time `status == null` was when coming from `removeApk()`. By
moving the logic out of `setApkInternal()` into `removeApk()` it makes
it easier to reason about `setApkInternal()` as it now does less. Also,
it was doubling up on the `syncrhonized (appMapping)` and `if (entry !=
null)` logic which is no longer required, because `removeApk()` was
already doing that.
While here, also make explicit the fact that `status` can no longer be
`null`.
Because of the way that this can be misused without the compiler knowing
(e.g. by forgetting to call `endBatchUpdates()`) it may be safer to move
it to an internal implementation detail of the class.
It could probably be done away with completely if the `notify*` methods
were moved out of the respective `*ApkInternal()` methods, but that
requires more significant refactoring to get right without code
duplication.
It seems that `setContentIntent()` will do fine if we pass it a null
argument. The default value is `null` anyway, and it doesn't mandate
a non-null argument.
Given that none of the callers need the functionality of the builder,
lets make it explicit that we don't expect the builder to be further
customized once it is returned. Instead, return a notification to hint
that no further customization is required/desired.
Given that some places where this method is invoked does a null check,
it seems reasonable to make this assumption explicit. That way if devs
use the method in the future, then they will be aware of the contract.
Neither pmd/checkstyle/many-devs are particularly precious about
hard rules of when to wrap a line. In this case we could've brought the
`ErrorDialogActivity` onto the same line as `putExtra`, but instead
opted to chain the method calls as per the `getAppDetailsIntent` method.
Whether a category is "available" or not is not a function of whether it
is in the category table or not. Rather, it is a function of whether there
are any active apps/apks which are in that category. Thus, don't notify
after inserting a category (the notification was wrong anyway as it was
trying to notify the AppProvider Uri instead of the ContentProvider one).
Instead, do it after a repo update is complete.
This adds support for the index fields: icon, mirrors, and antiFeatures.
icon and mirrors are for Repo, they've been around a while on the server
side, but just never used on the client side.
For Apk, this adds a new per-APK antiFeatures field so that each APK can
be individually marked. For example, when tracking is added or removed,
vulnerabilities are discovered and fixed, etc.
These fields will be ignored when using the v0 index.xml format, they
will be used by the upcoming index-v1 format: !422
In the v0 index format, empty descriptions were filled in with boilerplate
text. The v1 index format instead leaves empty descriptions empty, and
lets the various consumers (fdroidclient, web interfaces, etc) decide what
to show. The database and code still assume that the description will not
be null, so instead this ensures there is something in the database, but it
will be an empty string instead of a null. In the future, it would
probably make sense to standardize empty values on null or something.
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.
RequiresRoot is obsolete as a metadata field since there is the SUPER_USER
permission. This `requirements` array was set up to handle other things,
but that was never implemented.
APKs installed in /system} will often have zeroed out timestamps, like
2008-01-01 (ziptime) or 2009-01-01. So instead anything older than 2010
every time since we have no way to know whether an APK wasn't changed as
part of an OTA update. An OTA update could change the APK without changing
the versionCode or lastUpdateTime.
closes#819
gitlab-ci used to run all of our jobs in parallel, now it mostly seems
to run them sequentially. So splitting up the various parts of the CI
suite into separate jobs mostly slows things down. This combines the
static tests into one job (lint, pmd, checkstyle, tools) with the JVM
tests aka Robolectric. That makes three jobs from the previous six.
[ant:checkstyle] [ERROR]
/export/share/code/fdroid/client/app/src/main/java/com/geecko/QuickLyric/view/AppCompatListPreference.java:35:29:
Name 'mDialog' must match pattern '^[a-z][a-z0-9][a-zA-Z0-9]*$'. [MemberName]
Introduced in 79ecffc91c8856e7ceb6a65441d19a6272195426
