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
[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
Also ensure it shows this animation correctly when expanding "Versions".
This is done by changing from `notifyDataSetChanged()` to the more
specific `notifyItemRange(Inserted|Removed)`, which ensures the
"Versions" item doesn't get rebuilt midway through an animation.
Fixes#817.
As discussed in #817, this preference is not useful on Android >= 5.0.
As such, the preference should just be removed. However, it should stay
if the privileged installer is already installed (e.g. via update.zip or
included as part of the ROM).
Translators:
Ahmad Zafrullah Indonesian
Allan Nordhøy Norwegian Bokmål
Balázs Úr Hungarian
Hasan İlingi Kurdish
Jonatan Nyberg Swedish
Juraj Harasta Czech
Michalis Greek
Michalis Spanish
Nick Bishop Greek
Verdulo Esperanto
yiannakis Greek
Fixes Issue #750.
This new class makes sure to use the correct `AlertDialog.Builder` from
the support lib. This in turn ensures the correct styles get applied to
the result alert dialog.
Doesn't change anything, just removes a deprecation warning.
AppCompatActivity currently extends ActionBarActivity and doesn't
provide any further imnplementation.
Translators:
Adrià García-Alzórriz Catalan
Ajeje Brazorf Sardinian
Alaa Issa Arabic
Alberto Moshpirit Spanish
Alexander Georgievskiy Russian
András Lengyel-Nagy Hungarian
André Marcelo Alvarenga Portuguese (Brazil)
Anteri Finnish
Athmane MOKRAOUI Arabic
Claus Rüdinger German
Cyxae Dexyc French
dark159123 Danish
Dmitriy Bogdanov Russian
Enol P Asturian
ezjerry liao Chinese (Traditional)
Gregor Santner German
Hsiu-Ming Chang Chinese (Traditional)
Jean-Baptiste French
John Doe Turkish
Jonatan Nyberg Swedish
Kheireddine Mkh Arabic
Lari Oesch Finnish
Luca Bianchi Italian
Marcelo Santana Portuguese (Brazil)
Marian Hanzel Slovak
Michael German
Mladen Pejaković Serbian
msrn Finnish
naofum Japanese
Olexandr Nesterenko Ukrainian
Osoitz Basque
Raphaël Barman French
Sveinn í Felli Icelandic
Sylvia van Os Dutch
Tobias Bannert German
Verdulo Esperanto
Verdulo Polish
Yaron Shahrabani Hebrew
zmni Indonesian
