The previous language hinted at the fact we auto download and install
updates like Google Play. This is not the case (unless you have
priv-ext). To clarify, now we "Automatically _fetch_ updates", ready to
install when the user initiates the install.
Fixes#839.
Shows a red badge over the "Updates" menu item.
The updates badge is a bit hacky. There are indeed libraries which
implement a bottom nav which have support for badges built into
them. However they target API 14. There are also other badge
libraries which just deal with rendering, but for the cost of
another dependency, it is not particularly difficult to create a
`TextView` with a background and position it ourselves.
Alows for more flexibility in what we are able to display, including:
* Prompting users to donate to frequently updated apps
* Showing messages from package maintainers to users
* Marking apps for later installation when offline
Most of these are not yet implemented, but will be able to when
required, whereas they were not able to in the previous UI.
This is as per the mockup in issue #840, and does the following:
* Adds a new `PreferencesCategory` of "My Apps" at the top of the
preferences screen.
* Adds a "Manage Installed Apps" preference, and moves the
"Repositories" preference into this category.
* Repeals an existing change which prevented "updateable" apps from
appearing in the list of "installed" apps. This is because the two
lists of apps are no longer displayed alongside eachother.
* Enhances the `AppListItemController` to also be able to display
whether or not the currently installed version is the recommended
version or not.
* Also adds option to display whether the user has asked to ignore any
updates for any specific apps.
Things that are still not right:
* BottomNavigationView doesn't read out the title of items when selected.
Created this issue: https://code.google.com/p/android/issues/detail?id=230595&thanks=230595&ts=1482125499
* TTS reader combines the app name and summary without a pause which is jarring.
* Touching the background of the recycler view in the categories view reads all category names.
* Likely other problems too.
The styles used by the app details showed good padding on either
side of the buttons text. This was because they had a certain amount
of screen space to fill up which resulted in nice empty space on either
side of the text. Other buttons do not have this type of layout, so
need to have a minimum amount of padding thrust upon them.
Required breaking out into values-v17 too, so refactored common styles
into base style to make this easier.
This is a little bit flakey at this point, because the weird asynchronous nature of
adding fragments. If swiping to the second-to-last entry on the bottom navigation view,
it will populate the settings fragment in the UI and then it will dissapear. Need to
fix this.
Show a "Chip" in the search box whcih indicates the user is viewing
a particular category. This chip:
* Gets remtoved when the user presses backspace from in front of it.
* Can be re-added by typing the name of a category and then a colon.
* Follows the material design guidelines.
* Has an accessibility hint that tells screen readers it is a category name.
This is different to the old categories drop down, because that also
included meta-categories of "Whats New" and "Recently Updated". Given
we now show them on the first page, this categories screen can do away
with them.
Each category entry loads a few apps to show to the user.
Note: The "View all" button next to each category doesn't currently
go anywhere. It will soon be hooked up to an app list that is filtered
to the selected category.
Not fully featured yet, because it doesn't listen for broadcasts
from the installers, but it is shows the correct list of apps and
allows users to queue up downloads of all updateable apps.
Smooshes the recently updated and recently added lists into one,
and adds a status line under each app saying which of the two it
is (i.e. "Recnelty Updated" or "Whats New".
The fragment was quite straightforward to roll into the activity. Most
of the code moved across almost exactly as is.
Also added a theme for the toolbar so that in the future it will be
easier to support dark/night themes as well.
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.
