Android API Level 30 issues

[mzanetti]

With Android API level 30, registering the zoerconf browser fails with

W qtMainLoopThrea: type=1400 audit(0.0:8386): avc: denied { ioctl } for path="socket:[6380337]" dev="sockfs" ino=6380337 ioctlcmd=0x8927 scontext=u:r:untrusted_app:s0:c154,c256,c512,c768 tcontext=u:r:untrusted_app:s0:c154,c256,c512,c768 tclass=tcp_socket permissive=0 app=io.guh.nymeaapp

The failing call is in netlink.c, in avahi_netlink_new

    if (bind(fd, (struct sockaddr *) &addr, sizeof(addr)) < 0) {

fails with "Permission denied".

Now that new apps can't be uploaded any more with an API level less than 30 (and existing apps only until end of November) this becomes a real problem. I'm still debugging how to get it to work again but so far couldn't find anything.

[jbagg]

Hi, Have you added android.permission.INTERNET in the manifest?

https://developer.android.com/reference/android/Manifest.permission#INTERNET

[mzanetti]

Yes, using QT += network does that implicitly. Anyhow, I've also tried adding it explicitly, same.

According to this report arvidn/libtorrent#6251 bind() is not available any more now. Just commenting this out for testing purposes makes the code pass, but then fails at avahi_netlink_send, send().

That said, there must be a solution as Qt <= 5.15.1 also has troubles with the QNetworkConfiguration class and API level 30, but it's working fine again with 5.15.2 but I suppose it requires to patch the avahi code.

[mzanetti]

AFAICT, this is all about the interface enumeration of the avahi_interface_monitor... And apparently, starting with a minimum API level of 24, getifaddrs() may be used instead. That would be one option I guess, not yet sure if it's the best, or even if that's all to it or if there will be more obstacles after this.

[mzanetti]

Another option, I suppose, would be to ditch avahi for and android case and instead provide a Java implementation using https://developer.android.com/training/connect-devices-wirelessly/nsd#java
Downside would be that users of the lib on android would need to make sure that the java files are compiled in their gradle file. Not sure if that's a viable option.

[jbagg]

I don't know of a way to asynchronously get updates to interfaces using getifaddrs the way netlink provides. Avahi needs this. I suspect if I / we modify avahi to use getifaddrs, it would have to have a timer that polls it once / second, which seams like a horrible thing to do. QZeroConf will probably have to use the java nsd as you suggest. I have started looking in the past at using nsd as it is not ideal to have more than one mdns daemon on a system. Java is not my strong suit, but I found some useful stuff this morning
https://developer.vuforia.com/forum/faq/android-how-can-i-call-java-methods-c

https://developer.android.com/ndk/samples/sample_hellojni

[mzanetti]

Yeah, I'm already using some Java code in my app and mostly got the hang of it on how to interact between Qt and the android JNI. I'll give it a go and report back.

[mzanetti]

Got it working! Here's a preview: mzanetti#2

There's still a lot cleanup to do. It's merely a prove of concept for now. So far it only supports browsing, no publishing, but the way it works would be the same for everything. Tested on a Pixel 3 with Android 11 and nymea:app.

Currently it's a PR against my fork because I have some other commits on top too so the diff would be polluted. Unless you stop me because you think there's something wrong, I would now go ahead, fill in the gaps and then propose a cleaned up pull request towards upstream.

Currently I just added the folder with the java file to my build.grade file and it works fine. Apart form making the actual code work, there's still the task to figure out a nice way of allowing user of the lib somehow to just "include qtzeroconf.gradle" or something like that without having to bother about the actual files to be built by the Java compiler.

[jbagg]

Looks like a good start. If I understand it right, if a program has multiple instances of QZeroConf, each instance of QZeroConf will get it's own nsdService, right? I should create a androidjni branch that you can make pull request against.

[mzanetti]

Yes, every instance of QtZeroConf would create its own instance of the java class which in turn creates a new instance of the NsdManager. This is very much like the avahiclient implementation. NsdManager is really just a thin client to Androids system service.

We could create a single instance and share that across instances of QtZeroConf using some ref counting as the avahicore one does. This current way IMO simplifies the implementation and should also work fine if users instantiate multiple QtZeroConf objects across different threads. Such a shared mechanism would need to be mutexed and all (well, I guess the avahicore implementation doesn't really cope with that either so it's probably not a supported use case anyways). In any case, the benefits of a single shared NsdManager approach seem to be smaller than the downsides to me currently.

For the branches, I don't think you need to do anything, I'll just have to rebase my branch on your master instead of mine and propose a pull request against that. Unless you don't want to merge it to master when it's done but keep it only in an androidjni branch for a while.

[jbagg]

I created a branch called android-nds. This will allow us to test it well before merging to master. Have you used clang-format before?

[jbagg]

I agree, I think not sharing a single instance of NsdManager is the right way. Each QZeroConf instance should have it's own instance of NsdManager

[mzanetti]

I created a branch called android-nds. This will allow us to test it well before merging to master. Have you used clang-format before?

Hmm, no. Is this about the code formatting?

[mzanetti]

While heads down in the code I ran into a couple of questions/issues:

• I noticed that androids browser will resolve service types in the format _http._tcp.. Note the . at the end. The avahi implementation gives results as _http._tcp. I could of course trim the dot at the end, but while doing so, I noticed that the bonjour implementation gives services as ._http._tcp (No dot at the end but a dot at the start). Now I'm not sure, seems that this should be aligned through the lib, but obviously changing one or the other would mean sort of an API break... WDYT? Just align it to the avahi implementation to keep old behavior, or also align the bonjour one?

• Calling stopPublishService() on avahi implementations would only cause publisherExists() to return false, however, on the bonjour implementation it would additionally emit serviceRemoved(). Again, I suppose I'll follow the avahi implementation and not emit serviceRemoved, right?

• Name collision handling differs too: While the bonjour implementation does not ever seem to fail on name collisions (at least the error() is never emitted), the avahi implementations would bail out with error(serviceNameCollision). Interestingly enough, the android API behavior is to automatically resolve those collisions (by implicitly renaming) and returning the new name back. So I guess I could emit the error for name collision but still emitting servicePublished() and setting publisherExists to true. But not sure if that's weird for a user and I should just not emit the error at all?

[mzanetti]

I've pushed the latest code to my branch. It is now feature complete but still not 100% cleaned up and the above questions need to be sorted out still.

I wanted to rebase it onto your master, but ran into conflicts wrt UBPorts port. Depending on whether the UBPorts edition will be accepted upstream or not, the conflicts would need to be resolved differently. See #48

[jbagg]

WDYT? Just align it to the avahi implementation to keep old behaviour, or also align the bonjour one?

I would just keep the old (inconsistent) behaviour. I wasn't aware of the difference and no one has raised it before. I guess a user doesn't really care about the domain when browsing, their primary interest is the service's IP address.