feat: implement Android connectivity detection

[gabref]

Closes #10.

Adds Android support for connection_status() using Tauri's mobile plugin bridge and Android's ConnectivityManager / NetworkCapabilities APIs.

Changes

• Added Android plugin scaffold under android/src/main/.
• Added Kotlin bridge invoked from Rust through src/mobile.rs.
• Maps Android connectivity state into the existing ConnectionStatus fields:
  • connected: active network with NET_CAPABILITY_INTERNET and NET_CAPABILITY_VALIDATED
  • metered: absence of NET_CAPABILITY_NOT_METERED, with NET_CAPABILITY_TEMPORARILY_NOT_METERED treated as unmetered while present
  • constrained: Data Saver / RESTRICT_BACKGROUND_STATUS_ENABLED
  • connectionType: Wi-Fi, Ethernet, Cellular, or Unknown
• Added android.permission.ACCESS_NETWORK_STATE to the Android manifest.
• Kept desktop backends in src/platform.rs and added a separate mobile bridge path for Android and future mobile platforms.
• Added Android unit tests for the mapping logic.
• Added manual Android testing documentation, including Data Saver adb commands and tested scenarios.

Testing

Automated:

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• npm test
• npm run eslint
• npm run type-check
• npm run markdownlint
• COMMITLINT_FROM=HEAD~1 COMMITLINT_TO=HEAD npm run commitlint
• Android unit tests: :tauri-plugin-connectivity:testDebugUnitTest

Manual Android testing with the example app:

• Wi-Fi connected
• Cellular connected
• Airplane mode / disconnected
• Data Saver constrained state
• Metered Wi-Fi through hotspot

Android debug build was also verified with:

npm run tauri android build -- --debug --ignore-version-mismatches

[jjhafer]

DBUS_TIMEOUT is applied as a per-method timeout, and a single connection_status() makes several sequential D-Bus calls (NameHasOwner, Connectivity, [State], PrimaryConnection, Devices, per-device DeviceType/Metered, and for a modem the ModemManager Udi/RegistrationState). In the worst case (NM/MM present but wedged) those 2s timeouts stack to ~15-20s with no overall deadline, and since the desktop path runs on the bounded spawn_blocking pool, a few concurrent calls could starve other blocking work app-wide. Two cheap options: wrap the whole operation in an aggregate budget (falling back to fallback_connection_status() on expiry), and/or lower the per-call timeout since these are local-bus reads that should return in ms. Optionally, a fresh blocking Connection (own executor + socket) is built on every call — caching one in plugin state via OnceLock would avoid that per-call setup if this ever gets polled. Not blocking, but worth considering for robustness.

Comment added by AI model Claude

[velocitysystems]

Deferred. Unrelated to this PR.

[gabref]

Good point. I agree this is a valid Linux robustness concern: the timeout is per D-Bus method call, so several slow calls could stack up during one connection_status() request, and those run through spawn_blocking.

I think this is worth considering as a Linux follow-up, especially around either lowering the per-call timeout or adding an aggregate budget for the whole Linux query. I’d probably avoid caching the D-Bus connection unless we see polling or connection setup overhead become a real issue. Since this is Linux-specific and not part of the Android implementation, I think we can keep it out of this PR

[jjhafer]

@gabref @velocitysystems Claude added a few comments for consideration.

[velocitysystems]

Since this PR implements Android support, should the README support matrix be updated from "Planned"?