Refresh AppDetails header on package state change (fix#161)
Update the application details to display the correct state on
application install/uninstall.
Should fix issue #161https://gitlab.com/fdroid/fdroidclient/issues/161
See merge request !56
To refresh the header, we retrieve the fragment from its id.
But the landscape layout used another id for the same fragment, so it
could not be retrieved, leading to a NullPointerException in landscape.
Therefore, use the same fragment id as in the portrait layout.
When adding repositories using the Manage Repos activity, firstly look
for an /index.jar appended on the URL provided by the user. If that
doesn't work (HTTP status code other than 200) then it will try
/fdroid/repo/index.jar, then /repo/index.jar. If it can't establish a
connection to the server, or if none of the above attempts results
in a 200, then the path provided by the user is kept (even though we
have a hunch it might be wrong).
This is to cover for the case where people arn't connected to the net.
Another way to deal with no internet connectivity is provided by a
"Skip" button on the dialog while searching for the index.jar.
The searching for index.jar is done by doing a HTTP HEAD request, so
the entire jar needn't be downloaded.
Finally, to make this happen in a clean sort of way, I refactored the
ManageReposActivity a little bit to encapsulate all of the add repo
dialog handling into a subclass. This way, the outer class doesn't
need to know things like: Is the dialog showing, what state is it in,
is the background task to search for index.jar files running, how and
when to cancel that task, etc.
Do not manually call onChange() (fix NPE)
If the AppDetails activity has been destroyed by the system during an
application installation/remove, it is recreated once it should be
displayed again (this behavior can be forced by enabling "Don't keep
activities" in Android developer options).
In onCreate(), it passes its instance of myInstallerCallback to an
Installer. In onActivityResult() (which is called before onResume()),
this installer calls a method (onSuccess() or onError()) on this
callback. The implementation of these methods (the anonymous inner class
assigned to myInstallerCallback) dereference myAppObserver, which is
still null, because it will be initialized in onResume(), so a
NullPointerException is thrown.
However, the problem is not only that myAppObserver.onChange() is called
when myAppObserver is null, but that it should not be called manually at
all: it is a ContentObserver, so it is automatically called when
registered to the content resolver. As a consequence, this callback was
called twice.
Removing these calls fix both problems.
Should fix issue #135https://gitlab.com/fdroid/fdroidclient/issues/135
See merge request !58
When we receive notifications indicating that the app has changed, the
App object needs to be changed and the view updated.
These notifications can be received from two sources:
- the ContentObserver;
- onActivityResult().
Thus, the implementation should not be related to the ContentObserver
(in theory, we might want to keep only the onActivityResult()
notification). Therefore, move it to a separate method in AppDetails.
This also preventively avoids bugs when the ContentObserver is null.
This reverts commit 47e065442edc108d4bb38f9daaa7cdb3fff26b49.
Now that the ContentObserver is created when activity is started (even if not
resumed), then it will be non-null during onActivityResult(). Therefore,
the calls to onChange() will not lead to NullPointerException anymore.
The reason why we want to manually call onChange() is that the
ContentObserver notifications may happen several seconds later:
https://gitlab.com/fdroid/fdroidclient/merge_requests/58#note_948719
The ContentObserver was registered only when the activity was in resumed
state. However, in started but paused state (when the activity is
visible but not in focus), we still want to receive these notifications
to update the view.
Therefore, register it on start and unregister it on stop.
As a consequence, myAppObserver will be non-null during
onActivityResult().
If the AppDetails activity has been destroyed by the system during an
application installation/remove, it is recreated once it should be
displayed again (this behavior can be forced by enabling "Don't keep
activities" in Android developer options).
In onCreate(), it passes its instance of myInstallerCallback to an
Installer. In onActivityResult() (which is called before onResume()),
this installer calls a method (onSuccess() or onError()) on this
callback. The implementation of these methods (the anonymous inner class
assigned to myInstallerCallback) dereference myAppObserver, which is
still null, because it will be initialized in onResume(), so a
NullPointerException is thrown.
However, the problem is not only that myAppObserver.onChange() is called
when myAppObserver is null, but that it should not be called manually at
all: it is a ContentObserver, so it is automatically called when
registered to the content resolver. As a consequence, this callback was
called twice.
Removing these calls fix both problems.
Should fix issue #135https://gitlab.com/fdroid/fdroidclient/issues/135
Immediately after an app uninstall, the associated App will be updated
by a call to reset() in the AppObserver.onChange().
But before receiving this event, the activity and the fragments resume,
leading to a call to getInstalledStatus(…). At this stage, we don't know
that the app has been removed yet, but the package manager already
removed it. Therefore, PackageManager.getInstallerPackageName(…) throws
an IllegalArgumentException.
In that case, consider that the application has been uninstalled.
Should fix issue #167https://gitlab.com/fdroid/fdroidclient/issues/167
Default to building F-Droid with precompiled dependencies, with option for source dependencies.
I hope this isn't to controversial, I've tried to very clearly articulate my thinking behind it in the commit message for 6594357c and also document the feature in detail in F-Droid/libs/README.md.
When I first contributed to F-Droid, it had zero dependencies, and so was a matter of checking it out and running `ant debug`. I'd like future contributors to be able to experience this too, by checking out the code and then running `gradle assembleDebug`.
I've ensured that the premise of building libraries from source is still front and centre though, and building from source is a matter of running `gradle -PsourceDeps assembleDebug` as documented in F-Droid/libs/README.md.
I'd appreciate if somebody (hopefully with all of the dependencies already checked out and building) would be able to test this for me, and provide feedback. Happy to answer any questions which remain unanswered after reading the commit message and the F-Droid/libs/README.md file.
See merge request !49
Binary deps were not getting build and cleaned from the binaryDeps
subdirectory of "libs". Also, reverted the android support appcompat
library target to android-19, as there was no need to change it.
The support libraries expect to be using the gradle plugin version 0.10.0.
We are currently on version 1.0.0. They use APIs in their build script which
have moved or been removed, and so the build just breaks when we run it with
the 1.0.0 plugin. I tried some magic to make it work in various ways, but
kept failing. As such, I've reverted the `gradle -PsourceDeps` build to not
build the support libraries from source. In the future, we should be able to
change this if they change the plugin version to a more recent one.
Note that the ant build script still hasn't been modified, and so will be
using the binary support-v4 library, but should build appcompat-v7 from source.
Was going to bump to Support v21, however there is some behaviour change which
causes a crash. They have removed the progress view from the toolbar/actionbar.
This breaks the AppDetails activity. As such, I'll leave that for the future.
For now, there will be a slight difference between building with
ant (which uses support v-almost-21) and gradle (which uses v20).
This will stay the case until we get around to completely porting
the app to v21, and fixing any bugs or UI sadness that arises.
NOTE: This commit does not touch the ant build system at all,
only gradle.
There are currently 23 gradle projects which require configuration,
let alone building, in order to build F-Droid. This takes a non-trivial
amount of time/memory/cpu. Additionally, it also provides difficulties
when importing the project into Android Studio - which is the IDE that
many potential contributors will be using. Finally, I have over 100mb
of data in the extern/ folder, and the support libraries require almost
every single Android SDK to be installed, which is several GB. This is
not a friendly environment to encourage people to submit merge requests.
However, I'm very mindful of the need for an open source project such
as F-Droid to be able to be built from source. So to make sure we have
the best of both worlds, I've ensured that building all dependencies
from source is still possible.
The F-Droid/libs/README.md file explains in greater detail how to
do this (i.e. "gradle -PsourceDeps build").
As much as possible, I've tried to make the binary dependencies fetched
from jcenter. However there are still libraries which either haven't
integrated required changes for F-Droid back upstream, or don't have
mavenCentral/jcenter binaries available.
Android preference fragment has been changed to the original
upstream repository. The one we had before was because upstream
hadn't merged a MR for gradfle support yet. However, that has
now been merged. This version still doesn't exist in jcenter though.
In order for libsuperuser to build from upstream, using
`gradle -PsourceDeps`, we need to include a few gradle plugins
from jcenter which are never actually used (used by upstream to
release to jcenter).
Even though support-v4 is included through jcenter, it is kept in
the libs directory, so that ./ant-prepare.sh can use it.
Update support preference fragment to newer version. There has been
bugfixes commited, so lets include them in the version we are using.
Repository update interval (#158)
This is issue #158https://gitlab.com/fdroid/fdroidclient/issues/158
I have modified the update interval to include "weekly" and "Every 2 Weeks" and removed "Hourly" as update frequencies. THe maximum interval was daily which was still too often for me. I have removed "Hourly" as you probably have to pay for your bandwidth and that is insanely often :-). Every 4 hours should still be plenty often.
2 Languages did not have the right amount of options there anyway, and I fixed those.
Please check, test, judge and ... hopefully ... merge.
See merge request !52
This makes this script more likely to run on various setups, since it does
three checks for finding where the `android` utility is:
1. is it in the PATH already?
2. is ANDROID_HOME set?
3. does ~/.android/bashrc exist?
This also copies ~/.android/ant.properties into the project for anyone who
wants to setup automated tests of `ant release` builds.
The maximum interval to check repositories was "Daily". Allow to also
update weekly and bi-weekly and remove the "hourly" option (someone has
to pay for all that bandwidth after all). I was considering to even remove
the "Every 4 hours" option, but did not dare do it.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Classes which contain calls to platform specific methods cause
problems, because the dexer will go looking for that method even
if you put a guard condition checking the build number. However,
if you lazily load a class depdending on the version number, then
older API devices wont try and load it, and no VerifyError occurs.
* Android-21 introduced an API for symlinking.
* Android-19 has an API which can be used via reflection.
* Earlier versions use Runtime.exec('/system/bin/ln')
This also extends the SanitizedFile stuff so that the android < 19 can
safely use Runtime.exec() with less fear of command injection vulnerabilities.
Finally, some tests for the SanitizedFile and symlink stuff was added.
This prevents an app with "write external storage" permission from
being able to switch the legit app with a dodgey one between F-Droid
requesting an install, and the package manager actually showing the
install dialog to the user.
In order to make the file in private internal storage readable by
the package manager, its parent directories need to be world-executable,
and the file itself needs to be world-readable. It seems that the
"/data/data/org.fdroid.fdroid/cache" dir provided by the Context is
already world executable, but the "apks" subdirectory does not default
to this.
Also, to be compatible with android-8, a Runtime.getRuntime().exec()
call was added for such devices, which invokes /system/bin/chmod.
The effect of this was to require some level of file sanitization to
be made available using the Java type system to prevent command injection
attacks from weird apk names (as people are free to download metadata
from random internet people).
