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