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.
This also removes all the related stuff that resulted in
EVENT_APK_DOWNLOAD_CANCELLED being sent. Since EVENT_APK_DOWNLOAD_CANCELLED
ultimately does nothing, that whole bit of plumbing is unused.
Allowing all downloads, including updates, to be canceled simplifies the
code and if the user wants to cancel an update, they should be able to. But
canceling updates is not implemented in this commit.
This makes it so gradle provides all dependencies, rather than a mix of
classes that are copied in versus imported via gradle. This library is
already used by the tests, so its not really a new dependency, and proguard
should remove all the unused stuff.
Since this is internal code and not a library for use with other projects,
it should only include the methods that are actually in use. The other
copies are just dead code, which means more stuff to read in order to
figure out.
Unfortunately, this approach did not really work out. It would have been
really nice to rely on the provided DownloadManager stuff, but it has too
many issues, like not working with Tor or other proxies, and being
difficult to tightly integrate.
This makes it a lot easier to setup all the testing stuff. Mostly,
I'm tired of fighting Android Studio's fragility, so I want to remove
as much non-standardness as possible in the hopes of improving that
situation.
closes#534https://gitlab.com/fdroid/fdroidclient/issues/534
