On certain locales, F-Droid would crash at startup due to #334.
This isn't a proper fix, but rather a workaround that logs what happened and
links to the issue, instead of making F-Droid crash entirely.
We can't rely on their plugin versions to be compatible with ours. Besides,
they require tons of Android SDK targets to be installed to build.
They are already bundled with the SDK, so you can build them as part of the
SDK from source if you want to.
Include support for libaccesspoint to control the WiFiAP of a device.
Selecting wifi networks i snow possible by touching the name of the
wifi network in the "Start Swap" screen (sometimes it will say
"No network yet"). This exhibits the same behaviour as the "Join Wifi"
screen used to (and still does) do.
On emulators (is there other devices too?), Bluetooth is unavailable,
but the "Send F-Droid" is still there. I could remove it, but then
people may get confused as to why it is not there. Instead, there is
now a dialog which explains why it can't be sent (no Bluetooth).
In the future, this should be implemented with a relevant help screen,
but for now it is more than we have time for. It will require, not only
good content which is translatable, but also a generic approach so that
it can be used elsewhere in F-Droid too.
The StringBufferInputStream is deprecated, because it doesn't know the
encoding of the string it is buffering. This has been changed to use
a ByteArrayInputStream with UTF-8 encoding now.
Also made use of previously unused mimeType parameter to set the
Content-Type header of the response.
Sets a stream handler in FDroidApp which understands bluetooth://
URLs and returns a non-functioning URL handler for such URLs.
The reason it is non-funcitoning is because the openConnection()
function is not being used by the BluetoothDownloader at this point.
In the absense of this, a MalformedURLException is thrown.
The bluetooth stuff is still broken, but it is not broken in
this way any more.
The AppDetails subclass used to be used when you couldn't install apps
directly from the swap workflow. Now we don't send people to app
details, so the activity is unneeded.
The swap progress also now listens for progress broadcasts, rather than
showing an indeterminant progress bar.
Seems to work pretty-alright even when installing multiple apps.
Shows a progress (indeterminent at this stage) bar for each downloading
item, and hides the install button.
InnerView.getToolbarColour() was expecting a @ColorRes, except all views
were returning integers which were the colour value, not a pointer to
the resource as they should have been. Now only one place requires a
call to getResources().getColor() whereas before it was in each view.
Notifications on pre 4.1 devices require a pending intent to work. This
is so that when you touch the intent, it takes you somewhere meaningfull.
Without it, the update process crashes.
