PNG crunching is not a deterministic process, especially the way aapt does
it. This makes the F-Droid builds not reproducible. The easy solution to
this is to pre-crunch the PNGs and commit them to git. It also makes the
final APK a tiny amount smaller, for whatever reason.
https://medium.com/@duhroach/smaller-pngs-and-android-s-aapt-tool-4ce38a24019d
This is hitting a lot of plurals, causing the CI builds to fail. But
unfortunately, its getting it wrong. Its actually for a format in a string
like "Updated today" in languages like pt that need special cases for 0/1
items. In this case, it makes no sense to say "Updated 0 days ago".
This results in a slightly larger apk (e.g. 500KiB), but it reduces the
scope for bugs greatly. We still get all the benefits of only having to
maintain a single density-independent vector (rather than several
density dependent PNGs and all the work that involves).
The class of bugs that it solves is that there are several places where
vectors cannot be used, and you wont notice when developing on a device
newer than 5.0. For example, notification icons, `TextView`
and its `android:drawableStart` attribute.
Fixes#913.
This adds support for parsing the new index-v1.json data as defined in
fdroidserver!221. This new index metadata format is required to
support localization, graphics, screenshots, etc.
refs #15
The default behaviour of gradle when encountering a transitive
dependency which is the same as an explicit dependency, but where the
transitive dependency has a higher version, is to bump the depdendency
which was explicitly added. This meant that the addition of the
bottom navigation library implicitly bumped our support lib to 25.3.0
due to its dependence on it.
The options are:
* Change the 3rd party lib to support 25.2.0 instead of 25.3.0.
* Explicitly exclude the transitive support lib dependency in our build
script (what we have done in the past, e.g. with acra).
* Bump our explicit dependency.
Given the nature of the changes from 25.2.0 and 25.3.0, it seemed like
it was simplest to bump our dep. However, there is a bug
https://code.google.com/p/android/issues/detail?id=251302 which causes
a function we depend on in SwitchCompat to require API 14. Therefore,
this change excludes the 25.3.0 transitive dependencies, allowing our
25.2.0 dep to get used.
In the process, I've noted that there were a few places we opted for
excluding the transitive dependency in the past. These have now been
removed because we have a higher version than they do, and thus they
will no longer drag our old version forward.
The previous dependency extended the support library bottom nav. It did
this at the expense of lots of reflection. This is pretty brittle and
likely to break in future releases as the support lib gets updated. In
the mean time we need to have a fully working bottom nav, so this commit
includes a different dependency.
Most 3rd party bottom navigation panes look great. All that I found
require at least API 11, mostly API 14 (due to animations I suspect).
I've forked one of the most popular ones on GitHub and made it support
back down to API 10. My fork is added as a dependency until upstream
accepts the PR.
If they don't ever, then we can reconsider what our options are.
The two times I've swapped the bottom nav implementation have both been
trivial. The code generally only touches the MainActivity and its
layout.
Right now, it will allow us to set the selected item more nicely.
In the near future, we will use this dependency to control the visual
display of the bottom nav better (e.g. icons/text appearance/animation).
Note that there is a bit of development going on at the Android team,
and the official bottom navigation view may oneday support all of these
features. In that case, we should probably switch back.
There were a few different options around, but some of the best ones
which provided the most flexibility when adding diverse/complex
viewTypes to a recycler view target a minsdk above 10.
The "adapterdelegates" library still offers a big improvement on vanila
adapters, especially for the Updates view.
The following official Android support libraries were added:
* recyclerview-v7
* cardview-v7
* design
* support-vector-drawable
* constraint-layout
* palette
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.
Doesn't do anything except create an app with no versions,
no donate links, anything like that, and ensure that the adapter
is able to create the view holders for each resulting item.
In the future we can beef this up to check more exotic conditions,
such as calling `updateItems(App)` with different apps, each
with different combinations of versions, donation links, permissions,
etc.
