Unfortunately at least with a quick look the protocol that @rikujolla’s application uses is something homespun and not compatible with the official THL application used in Finland.
Now as I looked into the application code a bit deeper I realized that the meat of the thing is not actually in the THL application but in a google API that the application uses.
This approach looks better to me. If the bluetooth beacon system works as specified by the google API then it would only need to port the parts that interface to the THL servers to get the list of infected keys.
In the first iteration there would be no need to upload own keysets as I assume there are so few SFOS users that it would not matter too much. In case of suspected infection it would be just enough to self-quarantine.
Thanks @vige for pointing out the link. Contrac has a full implementation of the Google/Apple Exposure Notification spec which Koronavilkku uses, so it would just be a matter of writing the code to interface with THL’s servers and hooking it into the Contrac D-Bus interface.
@juiceme, if you’re interested, I’d be more than happy to collaborate with you on it. I’m just completing the implementation for the German app and don’t have time to work on them both independently, but if you’re able to get the DTKs downloaded from Finland’s servers, then that’d be a great first step.
Thanks @flypig, it would be nice to get Contrac working with the official Finnish infection servers. I am willing to help to get it done.
On terminology, “DTK” would be the set ok “infected keys”, right? I’ll have to check what is the method and format to download the dataset. On the THL github there is also sources for the reference implementation of the backend tey are using, so studying that might be useful.
Yes, sorry, the terminology has changed and I should have said “Temporary Exposure Key” or TEK now. But “infected keys” is correct (changes daily and you upload it to the server if you test positive).
The GApple API expects these to be provided in a particular format, and it’d make sense if THL were just providing them in this format directly. If so, once downloaded it’d just be a case of making a dbus call with the filenames and a config file to get them processed.
Thanks; that should be useful indeed and I’ll also take a look.
I did with XA2 3.3.0.16.
App starts fine, but it’s not many screens till the app says that it needs Google’s Spy…I mean Play services.
I don’t have either Google Play nor the microG.
@lumen the way the android application works, it is just a frontend to the google implementation of both the bluetooth protocol and the infection key handling.
This is the reason you cannot run it without a recent enough Google Play Services which contains the implementation.
I asked at THLfi/koronavilkku-backend about being compatible with the german cwa-server. Maybe you can comment their and put some more infos to it.
As both servers implement in the end the same standard a extra server is a waste of resources in my oponion.
Glad to see this thread here, I was going to start my own but then found this one.
I tried installing the Finnish Koronavilkku app on my XA2 running Sailfish OS 3.3 Rokua. I didn’t find it in Aurora Store for some reason, but was able to download the APK from APKmirror. In addition, I have installed the MicroG package (reimplementation of Google Services) which contains an implementation of the Exposure Notifications API in the newest release. The Koronavilkku app started up, but it doesn’t work - it just shows a big red “Ota käyttöön” (‘start using’) button which doesn’t do anything. This was what I suspected, but I wanted to give it a shot. I believe the missing piece here is the Android emulation layer which has extremely limited support for Bluetooth (speakers only IIRC). So even though the rest of the stack is there with MicroG implementing EN, it can’t talk to the BLE hardware. Assuming the Bluetooth support for the Android emulation is not going to improve (and I don’t think the community can do much as it’s proprietary), this is a dead end.
That leaves the option of a native implementation, which was already discussed above. To add a few pointers to the discussion, I found this blog post by Alyssa Rosenzweig interesting: it describes the author’s Linux implementation of the Exposure Notifications service/API (called liben) as well as a Linux application that attempts to be compatible with the Canadian COVID-19 tracking app / infrastructure. Technically it’s a success although there are problems with the keys needed to contact the official key servers.
If there are issues with other implementations of Exposure Notifications, maybe liben could also be of use on the Sailfish platform?
The reason being: it’s reported as not compatible with your phone because it’s not matching some of its requirement (usually stuff like OS API version, etc.). In your case, that is …
I believe the missing piece here is the Android emulation layer which has extremely limited support for Bluetooth (speakers only IIRC).
…Yup. Exactly.
Contact tracing require direct access to the bluetooth hardware (so that the Google, Apple or in your case microG service can send the random ID, and detect other people’s random ID and make that available to your local app).
But, indeed, the AlienDalvik layer used in Sailfish OS doesn’t give this access (because the underlaying Linux uses BlueZ like any standard GNU/Linux distribution, whereas Andoird uses it’s own thing, and there’s currently no translation layer between the two APIs in Aliendalvik. Thus Android apps are limited to only devices that are handled on the Sailfish OS side of things and appear as standard devices inside AlienDalvik: bluetooth speaker (appear as simple audio output to android apps), bluetooth keyboards (appear as standard input to android apps), etc.)
From the point of view of Android Apps, your smartphone doesn’t have any bluetooth, only a bunch of standard devices. That’s why the contact tracing app doesn’t show up in either Aurora or the official Play Store.
The must necessarily be handled in a Sailfish OS Native app.