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.
Fix version upgrade string for RTL languages
In right-to-left languages _forward_ is the direction to the left, so leftwards arrow should be used to indicate upgrade:
For left-to-right languages it remains the same:
Closes#609.
See merge request !235
Simplify Downloaders
This is some groundwork to simplify the Downloader stuff in preparation to moving it to something like an `IntentService`, as part of #601. This mostly removes unused bits that I've found in the process of writing the `DownloaderService`. Some of these events will be added back in a more consistent way, so that there is one event type for the same idea throughout the code base.
See merge request !236
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.
start porting tests to latest Android Studio/gradle setup
To encourage more people to use and add to the test suite, I've been working on making it work nicely with Android Studio and gradle. I've also setup the possibility for JUnit tests that run on the host machine, not the emulator. Those are run with `gradle test`. I added a JUnit test of `HttpDownloader` too.
See merge request !233
"Variable explicitly initialized to 'false' (default value for its type)"
I never remember what the default init value of booleans are, so this error
is quite annoying to me, and I can't see the harm of this behavior.
checkstyle says: "So in this case, x gets initialized to 0 twice, and bar
gets initialized to null twice. So there is a minor inefficiency."
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
This is the last Android code in the whole suite of Downloader subclasses,
so now we can write JUnit tests for them all, and avoid the fragility of
tests running on the emulator.
When running tests on the host machine, android.jar contains no code at all
which is totally stupid. We can keep android.util.Log in there because it
does not affect the logic at all. Then just set that android.jar to return
generic values using:
unitTests.returnDefaultValues = true
If there is no LocalBroadcastManager, then the Downloader tests can be done
with pretty plain JUnit and then do not require the Android emulator to run
Fix crash when returning to swap after cancelling
Fixes#409. The problem was that there was some listeners being added for broadcast events when the swap view was shown. These were never removed, and so cancelling swap, then returning to it would spin up a _new_ activity with new views, while the old listeners were still around. When the old listeners received events, they would try to talk to their associated `Activity`. This no longer existed, so a crash ensued.
While I was fixing the specific bug associated with #409, I took the opportunity to make more of the event listeners well behaved in the swap process. I don't think any of them were liable to cause crashes, but were likely to cause some weirdness at some point in time if they were not fixed.
*Note:* This swap view was an exercise in moving away from `Fragment`s towards an `Activity` with individual `View`s. I'm going to call this a bit of a failure at this point, because there is so much work that needs to be invested in implementing lifecycle stuff in our custom views. `Fragment`s naturally come with lifecycle methods that are familiar to other Android dev's looking to contribute to this project (even if they are a little difficult to understand at times). Implementing our own custom Views instead still results in similar classes of bugs (i.e. talking to an `Activity` when the view no longer is part of that activity).
A classic example of this is in my usage of the `onDetachedFromWindow` function in the `View`. I have no idea if this is the best place to unregister listeners or not. In a Fragment, it would be a matter of `onPause` or one of the more well defined lifecycle methods. Empirically, `onDetachedFromWindow` seems to be well behaved. The other alternative would be for the Activity to explicitly invoke a `onRemoved` type method each view when it knows it is transitioning from one state to the next. However at this point, we are then really into reimplementing `Fragment` land.
See merge request !232
Translators:
ageru French
Ajeje Brazorf Sardinian
Mohamad Hasan Al Banna Indonesian
Paresh Chouhan Hindi
YFdyh000 Simplified Chinese
YF Simplified Chinese
Pass through a known good `Context` to `translateCategories`
All the good work to make sure that `getActivity()` actually returned
a proper context, obtaining a final reference to that known good activity
object, and then using that in the background thread is thrown away.
The reason was because the `translateCategories` method would go and
call `getActivity()` all over again. This changes the `translateCategories`
helper function so that it asks for a `Context`. This way, a known
good `Context` can be passed in, rather than having to perform a check
to see if `getActivity()` is good again.
Fixes#603 (Hopefully)
See merge request !231
The old swap code used to delegate to the `AppDetails` activity when
touching an app in the swap view. Now it shows the install button
and download feedback inline. The code which used to exist is no
longer required.
This fixes the following bugs:
* `BroadcastReceiver` was never being created due to incorrect guard
condition `if (pollForUpdatesReceiver != null)` (should have been
`== null`).
* Called `unregisterReceiver` rather than `registerReceiver`.
* Even if it did work, it didn't make an effort to unregister the receiver.
In addition, the creation and listening with the `BroadcastReceiver is
now done in a way similar to the other swap views:
* Create it as a `final` member variable.
* `registerReceiver` when view is inflated.
* `unregisterReceiver` when view is detached.
Previously the receiver was added but never removed. The result
is that once a swap session is cancelled, the receiver still
gets broadcasts.
This is what was causing the bug in #409. It was trying to access
the `Activity` once it had been closed, and another swap session started
with a new activity.
All the good work to make sure that `getActivity()` actually returned
a proper context, obtaining a final reference to that known good activity
object, and then using that in the background thread is thrown away.
The reason was because the `translateCategories` method would go and
call `getActivity()` all over again. This changes the `translateCategories`
helper function so that it asks for a `Context`. This way, a known
good `Context` can be passed in, rather than having to perform a check
to see if `getActivity()` is good again.
Update Support Library components to 23.2.1
As far as I can see from the release notes, 23.2.1 does not fix any bugs that could affect F-Droid. Anyway, it's better to be up-to-date.
See merge request !228
CI: Bump docker image
Also use a specific tag instead of latest, so that pushing latest on
Docker Hub won't break older branches and tags.
See merge request !229
gitlab-ci: enable lint, log posting, and caching
Some work to improve the CI functions, and first stab at getting parts running in parallel.
See merge request !211
