## Summary
1) Fix the code responsible for loading the trusted network list.
2) The old `#_#` delimiter has been replaced with a less likely NUL character. This requires re-adding trusted networks, so I can revert it if necessary.
3) Ignore incoming identity packets on untrusted devices if they come from an untrusted device.
BUG: 492302
## Test Plan
### Before:
1) Trusted networks were completely broken, an would show variations of `#` and `_` on the list due to a bug in the splitting code.
2) Any network with `#_#` in the SSID - although unlikely - would not be possible to use as a trusted network.
3) The device was still discoverable on an untrusted network by manually refreshing the devices list.
### After:
1) Trusted networks now load the SSID list correctly.
2) Networks with `#_#` in the SSID can be added as trusted networks.
3) The device is no longer discoverable on an untrusted network.
Uses Android's `NsdManager` to announce a `_kdeconnect._udp` service using MDNS. This is done in addition to sending UDP broadcasts.
When we detect a device this way, we send a UDP identity packet to it (identical to the ones we broadcast but sent to a single device).
I also added a toggle in settings to disable the UDP broadcasts, so we can test MDNS by itself.
`DeviceInfo` contains all the properties we need to instantiate a `Device`:
id, name, type, cert, capabilities and protocol version. Before, we had a mix
of passing those around as arguments or passing identity packets (ie: json).
This simplifies the `Device` class quite a bit.
Now, `BaseLink` subclasses need to implement the `getDeviceInfo()` interface
that returns a `DeviceInfo`, which is what we will pass around and eventually
use to instantiate a `Device`.
This means that identity packets are an implementation detail of the
`LanLinkProvider` and that other implementations could get the `DeviceInfo`
in a different way.
In a future, we can add a mechanism for links to notify when their `DeviceInfo` changed.
This will allow us to better support device renames (which now are implemented by
reconnecting to the device and don't always work) or sending the capabilities fields
later in the case of MacOS/iOS where we can't send them in a UDP packet due to the
size limit of 1500 bytes.
Bubble up exceptions instead of using giant, generic try-catch blocks.
The UDP and TCP listener loops are now where we catch all the exceptions that might happen handling the incoming packets.
Also, the creation of worker threads now happens in the listener loops as well instead of the inner functions.
Finally the `broadcastUdpPacket` function has been split in `broadcastUdpIdentityPacket` and `sendUdpIdentityPacket` (the first calls the second).
By passing a port the implementation of DatagramSocket already binds to
it, making it fail if the port was already in use even if we did
setReuseAddress because that happened after binding.
We don't want to crash if we get onNetworkChange before tcpServer has been
initialized, however the way to do it was wrong because the exception was
being thrown from a new thread.
broadcastUdpPacket will throw if setupTcpListener isn't successful, and
at that point we no longer know the real issue. Re-throw exceptions in
setupTcpListener so we can see what goes wrong.
Added a new KdeConnect Application class that holds the Devices now, while
BackgroundService "only" takes care of the LinkProviders.
Since KdeConnect subclasses Application we have the guarantee that it will
exist as long as our process does, so we can use it as a singleton. This
removes the "BackgroundService.RunCommand" hack (which sent an Intent that
would awake BackgroundService in case it wasn't running already and then
call our code in a callback). This saves lots of round trips between the
system and us and makes things simpler (and stack traces useful) by making
the code sequential.
We already had an Application subclass that I moved to a new helper, which
now the KdeConnect class initializes together with all the other helpers.
## Summary
Spawning new threads in Java is costly. This MR aims to use a common thread pool instead.
I've replaced all cases where a new thread is started just to perform a task in the background. This does not include cases where a reference to the newly created thread is kept as a part of application logic – this is probably a problem in itself, but it exceeds the scope of this quick optimization. ;)
There was a couple of cases where a new thread was spawned just to sleep for a while an then change the state on a View on the main thread. I've replaced those with posting those deferred tasks to the View's message queue.
## Test Plan
Everything should work the same as it has before, just a bit faster and easier on the memory.
Summary: I have created a new activity that allows you to trust all networks or add networks one by one to a list when you are connected to that network
Test Plan:
Test Cases:
1. By default everything should works like it works before, If you uncheck the "Allow all" option in trusted network menu and there isn't any ssid in the trusted
network list the app doesn't send the first udp package and log "Current WiFi isn't a Trusted Network"
2. With the "Allow all" uncheck, use "Add: YOUR_SSID_NAME" button to add your current ssid to the trusted networks list, once you added, go back and the app should
works as always
{F6152314}
1 -> https://youtu.be/ZpCEFTstbJI
2 -> https://youtu.be/cVB1LXlFVyk
Reviewers: #kde_connect, jdvr
Subscribers: sredman, albertvaka, nicolasfella, apol, kdeconnect
Tags: #kde_connect
Maniphest Tasks: T8539
Differential Revision: https://phabricator.kde.org/D13505
Summary: The desktop side goes as far up as 1764.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17271
