Also tried a more specific naming scheme for dimens to make it clearer where
they are to be used. This increased the padding on the left/right of the collapsable
lists. It also decreased the padding above/below.
Still needs some better assets for the actual donate buttons, but now it includes
the relevant text about donating to developers. It also puts the donation options
in a grid layout and lets them flow across so that if there is more than three, they
will end up on the second line.
This introduces three network states:
1. completely disconnected
2. connected only via metered networks
3. connected via unlimited networks
This allows the update process to use bandwidth better, especially when the
user has enabled the "Only on WiFi" setting. It also helps prevent silly,
cryptic error messages in the update process is triggered when there isn't
internet available.
I tested this with:
* 4G only, but not set up for internet
* 4G only, with internet
* 4G + WiFi
* WiFi only airplane mode
* no internet at all, full airplane mode
closes#793closes#774
For now, this is disabled by default and hidden in the expert preferences
since it doesn't do anything yet inside of F-Droid. It is useful now for
whitelabel builds to fetch the install history from another app. #396
This allows a designated app to read the install history from F-Droid via a
ContentProvider. The app is designated by the packageName defined in the
string install_history_reader_packageName.
The install and uninstall history has lots of uses, including displaying
to the user in the app itself, reporting to the Device Administrator to
enable tracking of installs/uninstalls from the admin's app repo, etc. It
can also be used as part of a "popularity contest" #396
This allows whitelabel versions of apps to specify built-in app repos that
have push requests accepted by default. This is useful for the case where
there is a central manager of the core apps that are installed.
https://gitlab.com/fdroid/fdroidserver/issues/177
This is a step towards supporting easy whitelabeling, using gradle flavors.
This allows the whitelabel version to set the default repos just by making
their own default_repos.xml in app/src/whitelabel/res/values. That one
will then override the built-in F-Droid one.
When the Privileged Extension is working, then enabling the preference
"Automatically download updates" will actually install those updates in the
background. So the preference should communicate that to the user. So now
it serves as a global "allow background updates"
#16closes#106
This involved the typical Android design pattern of a "Base" style in
`values/styles.xml`, then the an empty normal style which uses that Base style
as a `parent` also in `values/styles.xml`, and finally any API specific
styles in another version of the normal style in a `values/styles-v17` folder.
Same was done for android:actionBarStyle moving it into into values-v11.
This time, didn't worry about the base style, because there was not much to be
gained. by doing so.
This schedules CleanCacheService to run regularly, and delete files older
than the value set in the new "Keep cached apps" preference. It auto-
migrates the old "Cache packages" pref to the new one. The default cache
time for people who did not have "Cache packages" enabled is one day.
Fixes for priv extension install
For now, disable install of privileged extension on Android >=5.1 until we found better methods.
Also, fix crash of dialogs on Android 6 using a workaround for transparent activities and some code simplifications.
See merge request !259
Previously, navigating back to an app which is in the queue
qould indeed grey out the "Install" button and show the text
"Downloading..." in that disabled button. However, it woulnd't show
any sort of progress. This change shows an indeterminite progress
bar with the text "Waiting to start download..." underneath.
Happy to receive input on the best terminology if that is not
desirable.
In order to do this, I had to be more specific about when
the header fragment is updated. Previously, `headerFragment.updateViews()`
would get called by the `onResumeFragments()` activity method.
This was redundant because the `onResume()` method of the fragment
also invokes `updateViews()`. Thus, that call was removed (though
we still need to obtain a reference to the fragment in
`onResumeFragments()`.
Now that we have a nice background service, let's put it to work! This
makes update APKs be automatically downloaded after the index is updated.
Then when the user goes to install the updates, they will not have to wait
for the download part.
#601https://gitlab.com/fdroid/fdroidclient/issues/601
