Internal custom URL no longer requires network

[dchp]

Context

When Custom URL logging is enabled, outgoing HTTP requests are scheduled via WorkManager. For public URLs, the job is constrained to an internet-capable network (Wi‑Fi or mobile data, optionally Wi‑Fi only).

This works for remote servers, but blocks jobs when the destination is reachable locally without internet access - for example a server on the LAN, localhost, or over USB tethering/RNDIS.

Problem

Users logging to localhost or utilizing USB RNDIS Reverse Tethering encounter an issue where the Android system correctly identifies that the device has no active internet (Wi-Fi/Cellular), which consequently prevents the log transmission job from running. However, in these scenarios, traditional internet connectivity is not required, as the traffic is routed locally or over a physical USB connection.

Solution

I have introduced an InternalAddresses utility class that detects local/private IP addresses without requiring DNS lookups or adding external dependencies.

If the destination URL is determined to be an internal address, the network constraints for the WorkManager job are relaxed, allowing the task to run regardless of the active network status.

Detected Ranges:

• localhost
• IPv4 loopback: 127.0.0.0/8
• RFC 1918 private ranges:
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

Intentionally not treated as internal:

• Hostnames (e.g. http://nas.local/...) - not resolved via DNS
• IPv6 loopback (::1) - out of scope for this change
• Link-local addresses (169.254.0.0/16)

Technical Details

If a destination is defined as a private IP but is unreachable (e.g., the USB cable is disconnected), the attempt will naturally fail at the socket level. This is preferred behavior, as it allows the WorkManager to trigger the job and utilize its built-in retry mechanism once connectivity is restored, rather than blocking the task from ever initiating.