I was using syncthing as a reference for handling notifications in my
app, when I noticed that the "Info" channel appears to be incorrectly
initialized.
It looks like it was intended for the Info channel not to vibrate, not
to make sound, but only to show a badge. This might be redundant as it's
possible every notification pushed to this channel already follows those
standards, I am unsure. However, the code used to initialize the Info
channel was actually modifying the already created Persistent channel,
and thus did nothing.
This pull request fixes, what I think are typos which originated from a
copy and paste of the code used to create the Persistent channel.
I think these lines should either be changed as per this pull request,
or removed entirely.
Refactor code inside `if-else` blocks that checks for versions that are
no longer relevant.
Few lines could be deleted some others were just un-wrapped from the
if-else blocks.
The `if-else` blocks inside `PRNGFixes` file were left out as this file
is should be deleted in
https://github.com/syncthing/syncthing-android/pull/2036
The security workarounds contained in the `PRNGFixes` class were needed
for devices older Android APIs (16, 17, 18) while the current min sdk
API is 21.
Therefore this workaround is no longer needed.
Lollipop, API 21, has been the min sdk version for over a year in this
project.
There were still some conditions in the code, which checked for api 21,
that can be removed or simplified.
`StrictMode` makes sense mainly in for debug build types, enabling
it for release does not provide any value as it can add additional overhead and its logs going to be removed (because R8 strips them).
Add support for exporting and importing HTTPS related files
(`https-cert.pem` and `https-key.pem`). It can be used to export/import
a self-signed certificate/custom HTTPS certificate to the Syncthing
instance on Android.
I couldn't launch the app in my IDE so I didn't test the changes.
Closes#1986
This fixes missing strings in Weblate translation, although they are
supposedly in the strings.xml files.
Introduce string-array elements matching those from the source
strings.xml, but instead pointing to a `@string` reference. The latter
is to be translated based on the assigned sub item's key.
Weblate does not handle string-arrays, but needs this indirection, see
https://docs.weblate.org/en/latest/formats/android.html
All existing translations are pulled in by migrating the `<string-array
name="..."><item>...` elements to `<string name="...">` elements
instead. This was done using an XSLT stylesheet, so can be easily
reproduced.
**IMPORTANT, MERGING ORDER:**
1. [x] The automated Weblate PR should be merged first, after committing
any outstanding translation changes on Weblate.
2. [x] Then rebase this branch, best re-applying the XSLT in case of
conflicts.
3. [ ] Then merge this PR.
