GitLab

Translators:

Coucouf           French
Danial Behzadi    Persian
Green Lunar       Hebrew
Licaon Kter       Romanian
M2ck              French
Marian Hanzel     Slovak
Verdulo           Esperanto
Verdulo           Polish

Work around dead activity issue in AppDetails

It seems like install() sometimes runs when the AppDetails activity is
finished or finishing. This results in the windows (dialogs) failing to
show, and a BadTokenException to fire:

    android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@d6e3570 is not valid; is your activity running?

This seems to be the culprit:

    at org.fdroid.fdroid.AppDetails.install(AppDetails.java:840)
    at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.install(AppDetails.java:1657)
    at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.onListItemClick(AppDetails.java:1721)

Apparently, you can check whether an activity/context is being finished:

https://stackoverflow.com/questions/7811993/error-binderproxy45d459c0-is-not-valid-is-your-activity-running

I cannot reproduce this issue, thus can't say whether this fixes it or
not. Either way, it can't hurt to try. This can be reverted if we see
ACRA reports of this in the future, and the issue reopened.

Fixes #565.

See merge request !204

WifiStateChangeService: Avoid DhcpInfo NPE

Fixes #569.

See merge request !205

Fixes #569.

It seems like install() sometimes runs when the AppDetails activity is
finished or finishing. This results in the windows (dialogs) failing to
show, and a BadTokenException to fire:

    android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@d6e3570 is not valid; is your activity running?

This seems to be the culprit:

    at org.fdroid.fdroid.AppDetails.install(AppDetails.java:840)
    at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.install(AppDetails.java:1657)
    at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.onListItemClick(AppDetails.java:1721)

Apparently, you can check whether an activity/context is being finished:

https://stackoverflow.com/questions/7811993/error-binderproxy45d459c0-is-not-valid-is-your-activity-running

I cannot reproduce this issue, thus can't say whether this fixes it or
not. Either way, it can't hurt to try. This can be reverted if we see
ACRA reports of this in the future, and the issue reopened.

Fixes #565.

Translators:

Allan Nordhøy    Norwegian Bokmål
Licaon Kter      Romanian

Fix 555  content provider invalid uri

Was not correctly encoding "/" characters when searching. This caused the Uri used by the Content Providers to include a slash, which makes it look like a separate segment of the path which was wrong. Now correctly encodes "/" characters. Also noticed one other place incorrectly encoding characters, where they would've been double encoded when added as query parameters to a Uri.

See merge request !203

Refactor swap "peer finders" to use ReactiveX

*NOTE: This includes the commit specified by !197.*

In the old code, there is a _lot_ of procedual style "Is this peer finder running, if so, do this". In addition, the choice to do things on background threads or not is a little ad-hoc. Finally, the `SwapService` needs to know about both bluetooth and wifi peer finders, whereas really they are both only there to emit "Peers", regardless of the type.

As such, some improvements in this change are:
 * The choice to run peer finding on a background thread is made once, at a higher level when starting the peer finder.
 * No longer does the UI code ask "Am I searching for peers". It instead waits to be told whether it is or isn't.
 * The addition of new types of peers in the future is the job of the Peer finder itself. It quietly aggregates all of the Peer Finders it knows about into a single observable that emits different types of peers.

This code doesn't fix any particular issue, but rather it is about making the entire swap workflow easier to reason about. I plan on migrating more of this workflow to this functional style in the future, and hopefully that will have benefits in terms of stability and code understanding.

See merge request !198

Fixes nasty crash on android-19 and earlier.

Also fix the 0.98 date to be the same as the one in the stable-v0.98
branch.

Translators:

fabrizio maggi     Italian
Gabriele Pau       Italian
Irvan Kurniawan    Indonesian
Karola Marky       Latvian
Patrik Kretic      Slovenian
riotism            Chinese (Hong Kong)

I misread the documentation when first using the `appendEncodedPath` method,
because it expects the path to already be encoded. This causes a bug because
if you search for a '/'. The result is a malformed URI that has the path
'/search//' instead of '/search/%2F'.

Using `appendPath` will always encode the string given to it, which is desirable.

Also check for empty strings, and return a URI that gives all apps. This was
not strictly neccesary, because the code which invokes it checks for empty
strings, but if somewhere else in the future starts to use this code, they
would've had to know to check for empty strings first.

Fixes #555.

Should help prevent abuse of the search API into the future.

This is left over from when the search functionality was updated recently.

Put null check around access of `R.id.header` fragment.

Please note I haven't reproduced the specific problem. Also, the stack
traces being reported are only marginally informative, because they are
in response to a content providers firing events, and thus don't have
any context about when or where the event was fired from.

However, my looking at the code seems to indicate that this will prevent
NPE when the Activity is no longer visible but an app is finished
installing. Also, the view should still update correctly on resuming the
Activity because the `onResumeFragments()` methods will be invoked
which invokes the `refreshHeaders()` method.

Fixes #286.

See merge request !202

Please note I haven't reproduced the specific problem. Also, the stack
traces being reported are only marginally informative, because they are
in response to a content providers firing events, and thus don't have
any context about when or where the event was fired from.

However, my looking at the code seems to indicate that this will prevent
NPE when the Activity is no longer visible but an app is finished
installing. Also, the view should still update correctly on resuming the
Activity because the `onResumeFragments()` methods will be invoked
which invokes the `refreshHeaders()` method.

Fixes #286.

Add ReactiveX (rxjava + rxandroid) as dependency

This is going to be used to make the managing of async tasks in F-Droid easier to reason about. It does this by using a more functional style to performing multiple different asynchronous tasks as compared to the Android `AsyncTask` or `Service` or some other approach.

More specifically, I have some changes coming that will use this dependency.
I wanted to merge this separately so that it doesn't matter which of the changes I'm working on gets merged first.

I've never added a `dependencyVerification` to the gradle build before, and there wasn't a whole bunch of docs on the interwebs about how to do that. So I did a SHA256 sum of some other .jar files in my gradle cache and compared them to the existing dependency verification settings and they did match. So I also did a SHA256 sum of the newly added dependencies and gradle seems happy with the hashes I've chosen.

See merge request !197

The benefits of this are as follows:

No longer need to worry about how many types of `Peer`s exist.
There is a single publicly accessible `PeerFinder` which aggregates
the results of both the Bluetooth and Bonjour peer finders. In the
future if another is added, the consumer of the peer finder
(i.e. `StartSwapView`) doesn't need to be aware of this. Neither does
the `SwapService` or `SwapActivity` or any other code.

Never ask "Are we searching" but instead receive push notifications
from the peer finder when it stops searching.

Don't worry about receiving the same peer multiple times, it will
automatically get filtered out.

Less concern about doing things in `AsyncTasks` (and knowing what to
do in an `AsyncTask`). The RXJava + RXAndroid libraries deal with this
by allowing the client consuming the `PeerFinder` to specify which
thread to perform the background task on, and also that the found
`Peer`s should be emitted on the UI thread.

In the future, can play with caching the results of a particular
sequence of found peers. However right now using the `Observable.cache()`
method means we can no longer unsubscribe from the peer finders
and thus they run longer than they need to when we move on from
the initial swap screen.

The rxjava library depends on sun.misc.Unsafe, which is unavailable on Android
The rxjava team is aware of this, and mention in the docs that they only use
the unsafe functionality if the platform supports it.
 - https://github.com/ReactiveX/RxJava/issues/1415#issuecomment-48390883
 - https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/internal/util/unsafe/UnsafeAccess.java#L23

This is going to be used to make the managing of async tasks in
F-Droid easier to reason about. It does this by using a more
functional style to performing multiple different asynchronous tasks
as compared to the Android `AsyncTask` or `Service` or some other approach.

fix AOSP build integration

The build isn't done from the top-level directory so the symlink needs
to use an absolute path.

Fixes #551.

See merge request !200

Fix 560  (searching only whitespace)

When no keywords to search, use an empty query selection that evaluates to "1".

This means that instead of building invalid SQL such as `WHERE (() OR ())` it
will build `WHERE((1) OR (1))` which, while non-optimal, is at least valid.
In fact, I'm not even sure that it is non optimal because I'd hope the sqlite
query optimizer is able to realise that `1 OR 1` is effectively a no-op.

Fixes issue #560.

See merge request !201

Changing the search query is quite an expensive operation, so this does some rudimentary
checking to see if the two queries are meaningfully different. At present, it trims the
strings and does a case insensitive comparison.

The query is eventually exploded based on whitespace, so leading and trailing white
space is not important. Also, sqlite `LIKE` clauses are case insensitive, so case
is unimportant. Having said that, I'm not sure how someone will be able to change
the queries case without first deleting and then adding characters (thus inducing
meaningfull changse).

This means that instead of building invalid SQL such as `WHERE (() OR ())` it
will build `WHERE((1) OR (1))` which, while non-optimal, is at least valid.

Fixes issue #560.

The build isn't done from the top-level directory so the symlink needs
to use an absolute path.

Fixes #551.

Avoid NPE in Uri.getPath().replaceAll()

Fixes #533.

See merge request !199

Fixes #533.

As suggested by Android Studio.

Its use was removed long ago, and the dependency was left behind for
some reason. This commit can be reverted if it's needed in the future
again.

This of course slightly simplifies the build thus speeding it a little,
but what's more interesting is that the output apk is also ~100KB
smaller. So something is going on.