# Description
Use view binding in more activities:
* QRScannerActivity
* ShareActivity
* PullOrderDialogActivity
Rename also a couple of xml layout files from `fragment_xyz` to
`activity_xyz` as they are being used inside activities.
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.
## Description
Dependabot does not support (yet) upgrading the Gradle wrapper thus it
needs to be updated/upgraded manually.
## Changes:
* Upgrade gradle wrapper to version `8.5`
See also: https://github.com/dependabot/dependabot-core/issues/2223
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.
## Description:
Refactor gradle build files to use Kotlin DSL instead of Groovy.
There were also a bash script and a python script that needed to be
updated because they relied on parsing the `build.gradle` files written
in Groovy.
This PR completes the work started in:
https://github.com/syncthing/syncthing-android/pull/2000
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.
Bumps [com.google.guava:guava](https://github.com/google/guava) from
32.1.2-android to 32.1.3-android.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/google/guava/releases">com.google.guava:guava's
releases</a>.</em></p>
<blockquote>
<h2>32.1.3</h2>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>32.1.3-jre</version>
<!-- or, for Android: -->
<version>32.1.3-android</version>
</dependency>
</code></pre>
<h3>Jar files</h3>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/32.1.3-jre/guava-32.1.3-jre.jar">32.1.3-jre.jar</a></li>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/32.1.3-android/guava-32.1.3-android.jar">32.1.3-android.jar</a></li>
</ul>
<p>Guava requires <a
href="https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies">one
runtime dependency</a>, which you can download here:</p>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar">failureaccess-1.0.1.jar</a></li>
</ul>
<h3>Javadoc</h3>
<ul>
<li><a
href="http://guava.dev/releases/32.1.3-jre/api/docs/">32.1.3-jre</a></li>
<li><a
href="http://guava.dev/releases/32.1.3-android/api/docs/">32.1.3-android</a></li>
</ul>
<h3>JDiff</h3>
<ul>
<li><a href="http://guava.dev/releases/32.1.3-jre/api/diffs/">32.1.3-jre
vs. 32.1.2-jre</a></li>
<li><a
href="http://guava.dev/releases/32.1.3-android/api/diffs/">32.1.3-android
vs. 32.1.2-android</a></li>
<li><a
href="http://guava.dev/releases/32.1.3-android/api/androiddiffs/">32.1.3-android
vs. 32.1.3-jre</a></li>
</ul>
<h3>Changelog</h3>
<ul>
<li>Changed Gradle Metadata to include dependency versions directly.
This may address <a
href="https://redirect.github.com/google/guava/issues/6657">"Could
not find <code>some-dependency</code>" errors</a> that some users
have reported (which might be a result of users' excluding
<code>guava-parent</code>). (c6d35cf1a5)</li>
<li><code>collect</code>: Changed
<code>Multisets.unmodifiableMultiset(set).removeIf(predicate)</code> to
throw an exception always, even if nothing matches
<code>predicate</code>. (61dbccfda3)</li>
<li><code>graph</code>: Fixed the behavior of
<code>Graph</code>/<code>ValueGraph</code> views for a node when that
node is removed from the graph. (950799691c)</li>
<li><code>io</code>: Fixed <code>Files.createTempDir</code> and
<code>FileBackedOutputStream</code> under <a
href="https://redirect.github.com/google/guava/issues/6634">Windows
<em>services</em>, a rare use case</a>. (The fix actually covers only
Java 9+ because Java 8 would require an additional approach. Let us know
if you need support under Java 8.) (f87f68cd3e)</li>
<li><code>net</code>: Made <code>MediaType.parse</code> allow and skip
over whitespace around the <code>/</code> and <code>=</code> separator
tokens in addition to the <code>;</code> separator, for which it was
already being allowed. (2786f83291)</li>
<li><code>util.concurrent</code>: Tweaked
<code>Futures.getChecked</code> constructor-selection behavior: The
method continues to prefer to call constructors with a
<code>String</code> parameter, but now it breaks ties based on whether
the constructor has a <code>Throwable</code> parameter. Beyond that, the
choice of constructor remains undefined. (For this and other reasons, we
discourage the use of <code>getChecked</code>.) (59cfb2267a)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/google/guava/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
> **Note**
> Automatic rebases have been disabled on this pull request as it has
been open for over 30 days.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
`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.
Update all `strings.xml` translation files to replace triple full-stop
with proper Unicode ellipsis. Fix other syntax problems and cosmetics in
translation source `strings.xml`.
The code to calculate this metric has long been removed from the backend upstream, in commit c7d6a6d780.
Thus the GUI element should go away as well, currently always displaying 0 percent anyways.
Ref https://github.com/syncthing/syncthing/pull/6393
This error message is slightly misleading (related to #1778) currently,
the user will get this error even if they have whitelisted the SSID.
Co-authored-by: Simon Frei <freisim93@gmail.com>
There is a basic variant "de" which is recognized by Weblate and
actually has translated strings in contrast to the specialized de_DE
variant. Seems obvious to keep the former.
There is a basic variant "si" which is recognized by Weblate and much
more complete than the specialized si_LK variant. Seems obvious to
keep the former.
For strings containing escaped newlines (\n), always start a new line
right before that sequence and remove any other whitespace in between.
Let the closing </string> tag follow immediately on the last line.
Keep one-line translations on one line, without arbitrary wrapping.
Actually fix some line-break inconsistencies within the translations
along the way. Some had questionable \n\ sequences, capitalized \N or
the n actually forgotten after an escaping backslash, which lead to
parsing errors. Others simply used two line breaks (which are
collapsed to one space during parsing) instead of the needed \n escape
sequence.
This gets the format much closer to what Weblate generates when
dumping the parsed strings into fresh XML files. Also harmonizes the
formatting in the "source" (English) values/strings.xml though.
Assuming that these are just input errors, as they don't exist in the
English strings and are not explicitly quoted.
Weblate will remove when outputting translated strings anyway.
The option "restartOnWakeup" was removed in Syncthing v1.21.0 [1]. Thus,
remove it from the Android app as well, since the option does not
perform any function anymore. In addition, update the Docs also [2].
[1] https://github.com/syncthing/syncthing/issues/8448
[2] https://github.com/syncthing/docs/pull/815
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
Co-authored-by: Tomasz Wilczyński <twilczynski@naver.com>
Bumps [com.google.guava:guava](https://github.com/google/guava) from
31.1-android to 32.1.2-android.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/google/guava/releases">com.google.guava:guava's
releases</a>.</em></p>
<blockquote>
<h2>32.1.2</h2>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>32.1.2-jre</version>
<!-- or, for Android: -->
<version>32.1.2-android</version>
</dependency>
</code></pre>
<h3>Jar files</h3>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/32.1.2-jre/guava-32.1.2-jre.jar">32.1.2-jre.jar</a></li>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/32.1.2-android/guava-32.1.2-android.jar">32.1.2-android.jar</a></li>
</ul>
<p>Guava requires <a
href="https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies">one
runtime dependency</a>, which you can download here:</p>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar">failureaccess-1.0.1.jar</a></li>
</ul>
<h3>Javadoc</h3>
<ul>
<li><a
href="http://guava.dev/releases/32.1.2-jre/api/docs/">32.1.2-jre</a></li>
<li><a
href="http://guava.dev/releases/32.1.2-android/api/docs/">32.1.2-android</a></li>
</ul>
<h3>JDiff</h3>
<ul>
<li><a href="http://guava.dev/releases/32.1.2-jre/api/diffs/">32.1.2-jre
vs. 32.1.1-jre</a></li>
<li><a
href="http://guava.dev/releases/32.1.2-android/api/diffs/">32.1.2-android
vs. 32.1.1-android</a></li>
<li><a
href="http://guava.dev/releases/32.1.2-android/api/androiddiffs/">32.1.2-android
vs. 32.1.2-jre</a></li>
</ul>
<h3>Changelog</h3>
<ul>
<li><a
href="https://redirect.github.com/google/guava/issues/6642#issuecomment-1656201382">Removed</a>
the section of our Gradle metadata that caused Gradle to report
conflicts with <code>listenablefuture</code>. (9ed0fa65ab)</li>
<li>Changed our Maven project to avoid <a
href="https://redirect.github.com/google/guava/issues/6654">affecting
which version of Mockito our Gradle users see</a>. (71a16d5a74)</li>
<li><code>collect</code>: Under J2CL, exposed <code>ImmutableList</code>
and <code>ImmutableSet</code> methods <code>copyOf</code> and
<code>of</code> for JavaScript usage. (b41968f5f2)</li>
<li><code>net</code>: Optimized <code>InternetDomainName</code>
construction. (3a1d18fbefa10218988a0fbbb6e1fada012397bf,
eaa62eb09548a6f1b7a757e21d8852724b631cab)</li>
</ul>
<h2>32.1.1</h2>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>32.1.1-jre</version>
<!-- or, for Android: -->
<version>32.1.1-android</version>
</tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/google/guava/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
closes#1963
PS: This one has been kinda ugly to spot, ngl. I didn't expect that we
were modifying the welcome activity status bar color programmatically
instead of just with an XML theme ...
