AndroidNotCompatibleException is not used for anything specific right now,
and in the process of adding verification to the start of the install
process, there will be other kinds of failures. So convert that Exception
into a general usage InstallFailedException.
No need to flood receivers with progress events since they are basically
always going to the UI, and the UI will only refresh every so often. If
the refresh rate is 50Hz, then that's every 20ms. 100ms seems to make a
smooth enough progress bar, and saves some CPU time. This becomes more
important if there are multiple downloads happening in the background, like
if we make DownloaderService support parallel downloads from different repos
When dealing with complex lifecycles like Fragments, it is important
to expose the reliance of the Fragment on the Activity, since they
have different lifecycles.
Just cast to AppDetails instead of adding complexity with unneeded
Interfaces. The actual instance and class will be the same with or
without the Interfaces, so it does not help with lifecycle issues.
The methods that implement the interfaces only hide the fact that they
rely on an active instance of AppDetails, which can lead to
lifecycle-related crashes.
This is a step along the way to streamlining AppDetails Activity so that it
only uses Fragments when they are beneficial.
DownloaderService is based on IntentService to provide queued requests that
run in a background thread via the Handler and the HandlerThread. It began
as the IntentService code, but it could not be a subclass because the
downloading needs to be cancelable. IntentServices cannot be canceled and
they provide no visibility into their queue.
DownloaderService then announces relevant events via LocalBroadcastManager
and Intents with custom "action" Strings.
https://gitlab.com/fdroid/fdroidclient/issues/601#601
Verify apk signature of privileged extension before installation
This implements a check that the signature of the extension apk is the same as the signature of F-Droid before installing the extension apk. Related issue: https://gitlab.com/fdroid/fdroidclient/issues/437
See merge request !256
Currently, UpdateService is running at default priority, which is the same
as the UI tasks, since it is a regular IntentService. That means it would
put a noticable load on the device when running, especially on older
devices. This should help with that.
#563https://gitlab.com/fdroid/fdroidclient/issues/563
Android recently switched from JUnit 3 to 4 for its base testing classes.
It doesn't seem to support the old JUnit3 methods with gradle and AS. So
all the tests need to be ported to JUnit4 to work again.
#607https://gitlab.com/fdroid/fdroidclient/issues/607
Since SSLHandshakeException is a subclass of IOException, and all that is
happening is rethrowing an Exception, instead pass this one through so it
will be handled by the central Downloader error handling. That's currently
just a Toast, but it can easily be expanded in the future.
Shared element transition for app list item v21 and above
Shared element transitions for API level v21 and above
See merge request !251
Since Downloader's outputFile variable is final, it can safely be used
as a public property variable. This makes it simple to use in
subclasses. Making it a public final variable rather than a getter
also communicates that the value does not change since there is no
getter method that could potentially change it.
http://binkley.blogspot.com/2005/01/read-only-properties-in-java.html
Having 0 mean max makes the logic confusing when maxSdkValue is used in
variable. This sanitizes the data so that maxSdkValue is always just a
plain int value that can be used to test against. It does this by
defaulting to Byte.MAX_VALUE (127) if it is not explicitly set. At the rate
of 24 SDK numbers in 8 years, that gives us about 24 years before we have
to think about setting it to Short.MAX_VALUE.
This fixes an issue created by e021eb5ca7e8f05dbce7c1b87833722542138302
Since the DownloaderService's events are all based on the complete download
URLs, and RepoUpdater is where the update URLs are built, this makes the
full download URL into a read-only property of RepoUpdater so it can be
used wherever there is an instance of RepoUpdater
This is also important because having the `final` property highlights
the lifecycle of that variable: it does not change during the entire
life of a RepoUpdater Instance.
Instead of duplicate APIs, standardize on a single API, and use that
everywhere via the Downloader.LOCAL_ACTION_PROGRESS event that is already
wired in.
This is needed so that downloads can be canceled from within an
IntentService. Since the Downloader classes do not have any Thread logic in
them, they shouldn't use Thread logic within them anyway.
This also removes the unused argument to AsyncDownloader.attemptCancel().
This is not pretty, but its the best I could think of.
Fixes this lint error:
Call requires API level 9 (current min is 8): android.content.SharedPreferences.Editor#apply [NewApi]
'src' works because we're only doing java files under that directory.
But it would be slower than needed, and in the case of PMD it would also
use the test files which wasn't intended at all.
It seems like having it as a compile dependency already works for the
tests. Having it duplicated seems to sometimes trigger errors (e.g. a
user reported a duplicate zip entry due to the duplication) and might
also be problematic if we don't keep the two versions in sync.
"Consider using apply() instead; commit writes its data to persistent
storage immediately, whereas apply will handle it in the background"
commit() is only useful if the code actually checks the return value.
* Use a % sign that String.format() recognizes, apparently there are more
than one % signs, in Chinese, its big: ％
* a string in lithuanian forgot the %s
An AsyncTask ties into the UI thread for things like onPostExecute(). If it
is run within an AsyncTask, then it freaks out because it can't tie into
the UI thread. We don't need it to do that here anyway, so just use a
plain Thread, and set the priority to background.
As part of the process of moving the APK downloading to an
IntentService, I'm removing and incrementally reorganizing the
existing events so that the code continues to be functional as it is
reorganized. We might want to include more detail in a download error
to expose to the user, but I think instead what will be more fruitful
is to hide details on errors where there is nothing the user can do
except retry. Then if there are errors where the user can do
something about it, then F-Droid should instead offer them the option
of doing that, and not just show an error message and walk away.
This is part of the move to standardizing all internal broadcasts to use
the Intent's Uri field as the standard place for a download URL, and then
using that in IntentFilters to do matching.
