This gives a lot more flexibility to the user to cover bandwidth, power,
and privacy issues related to network traffic. The current implementation
does not represent these prefs as well as it should. For example, it does
not force the traffic over the preferred network type if the other type is
set to "never". Instead it just tracks the "unmetered" status of the
active network, and acts based on that.
closes#1381
This follows the Material preferred style using Switches instead of
CheckBoxes for boolean preferences. This leaves the "expert" preferences
as CheckBoxes to differentiate them, and make them stand out as something
different.
These are in fact needed:
/export/share/code/fdroid/client/app/src/main/res/values/dimens.xml:25: Error: The resource R.dimen.fixed_width_padding appears to be unused [UnusedResources]
<dimen name="fixed_width_padding">2dp</dimen>
~~~~~~~~~~~~~~~~~~~~~~~~~~
/export/share/code/fdroid/client/app/src/main/res/values/styles.xml:162: Error: The resource R.style.SwapTheme_StartSwap appears to be unused [UnusedResources]
<style name="SwapTheme.StartSwap" parent="AppThemeLight">
~~~~~~~~~~~~~~~~~~~~~~~~~~
/export/share/code/fdroid/client/app/src/main/res/values/styles.xml:166: Error: The resource R.style.SwapTheme_StartSwap_Text appears to be unused [UnusedResources]
<style name="SwapTheme.StartSwap.Text" parent="@style/SwapTheme.StartSwap">
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The new JobScheduler API can opportunitistically run a job based on whether
there is good internet, connected to power, etc. This is very useful for
running updates. Ideally, updates would always happen in the background
while on unmetered internet and connected to power.
#588
Each time the device connects to a wifi network, this waits for 2 minutes,
then if the wifi is still connected, it re-schedules the index update to
happen now. The goal is to favor unmetered networks as much as possible
when downloading the index and any automatic app updates.
This is only needed on older platforms, JobScheduler handles this for us on
android-21+
This changes the flow of the update triggering so that any Intent sent to
UpdateService can potentially trigger an update, depending only on the
state of the internet and the "Only on WiFi" preference. Instead of having
a timer that checks every hour to see if it is time to run the update, just
let AlarmManager send a trigger Intent based on the timing in the
"Update Interval" setting.
The update schedule is reset each time F-Droid restarts, and also each time
the user returns from the settings, so if AlarmManager fails us in the time
being, the updates will be rescheduled next time F-Droid is restarted, the
device is rebooted, etc.
refs #662
