[Android] Add NetworkChange implementation using PeriodicTimer

[simonrozsival]

We can't use netlink sockets to monitor network changes on Android anymore due to changes to permissions in recent Android versions. There doesn't seem to be a native Android API that could be used to implement the NetworkChange API in .NET. Instead, this PR implements the functionality using PeriodicTimer and manually diffing the IP addresses of all network interfaces. The period is set to 2s to limit the impact on battery life of mobile devices.

Ref #77822

[ghost]

Tagging subscribers to 'arch-android': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP - this code needs more testing before it will be ready for review.

We can't use netlink sockets to monitor network changes on Android anymore due to changes to permissions in recent Android versions. There doesn't seem to be a native Android API that could be used to implement the NetworkChange API in .NET. Instead, this PR attempts to implement the functionality using PeriodicTimer.

Ref #77822

Author:	simonrozsival
Assignees:	-
Labels:	area-System.Net, os-android
Milestone:	-

[simonrozsival]

/azp run runtime-android

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[steveisok]

LGTM. I think a 2 sec poll is reasonable for those who want to opt in. I don't think there are any other good alternatives.

[mdh1418]

A few nits, but overall looks good to me!
Out of curiosity, were there statistics to use 2 seconds polling? I'm not familiar, but is there a general frequency to network changes, and is the impact on battery life mainly from CheckIfAddressChanged firing? How long does it take for CheckIfAddressChanged to finish?

[simonrozsival]

@mdh1418 The 2s is my estimate of what is "almost immediately" but at the same time "not all the time". I tried being as conservative as possible with the frequency.

I didn't measure how long CheckIfAddressChanged CheckIfNetworkChanged runs because it will be different on different devices. The function enumerates the network interfaces present on the phone/tablet and that will behave a little differently on each device. I can make some measurements tomorrow.

[mdh1418]

Gotcha, I was wondering if the impact of battery life would be more directly related to the duty cycle of CheckIfNetworkChanged. If it takes a whole second to run (50% duty cycle/active time), then 2 seconds or even longer seems to make sense (without considering how important it is to not miss network changes), and on the other hand if it takes 1ns to run, then we can probably check more frequently. But I'm not sure if thats exactly how the battery is directly impacted.

What might be more helpful to determine polling frequency than duty cycle might be what happens if we miss a network change? Is it problematic if there were multiple network changes within the 2 seconds? Is it problematic if there was a change that cancelled itself out within 2 seconds (i.e. a network becomes available and then becomes unavailable all before the next poll)?

[simonrozsival]

@mdh1418 So on my Samsung Galaxy phone running Android 13 CheckIfNetworkChanged usually takes around 2-8 milliseconds when there isn't any change since the previous call and around 40-50 ms whenever there is a change. So it isn't on the order of seconds, but neither is it on the order of nanoseconds.

I don't think it's too important to detect these short network availability spikes, although there might be customers who might need this kind of information. The use case for this API in a mobile app I can imagine is to wait for network availability and only when the device is online, attempt to send a HTTP request. This implementation would IMO be suitable for that use case. it wouldn't be useful to monitor and diagnose network stability of an Android device. I think there are more suitable native APIs for that use case.

[simonrozsival]

/azp run runtime-android

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

Failing tests are unrelated to this PR.

[simonrozsival]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/4043009267

[github-actions]

@simonrozsival backporting to release/7.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: Add NetworkChange implementation using PeriodicTimer
Using index info to reconstruct a base tree...
M	src/libraries/System.Net.NetworkInformation/src/System.Net.NetworkInformation.csproj
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Net.NetworkInformation/src/System.Net.NetworkInformation.csproj
CONFLICT (content): Merge conflict in src/libraries/System.Net.NetworkInformation/src/System.Net.NetworkInformation.csproj
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Add NetworkChange implementation using PeriodicTimer
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[github-actions]

@simonrozsival an error occurred while backporting to release/7.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.