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
HttpDownloaderTest doesn't get run in gitlab-ci since it was too flaky with
internet connections in the emulator. So these were missed until I manually
ran the tests.
688057b3e7e214db49566b84d5b3dcd0db30dc2b
195aaae7e52dc1c47741965904ed17bdc816a71c
df08e84e7829652d7999eee5451080a012b00a1e
Some devices send multiple copies of given events, like a Moto G often
sends three {@code CONNECTED} events. So they have to be debounced to
keep the {@link #BROADCAST} useful.
