fix(android): report the app's version from /api/0/info

[TimeToBuildBob]

Android half of item 3 in #236, the follow-up to ActivityWatch/aw-server-rust#656 (merged).

Problem

The webui footer showed v0.14.0 (rust) on a v0.14.0b2 install: GET /api/0/info reported the aw-server-rust package version, which is the version of a component rather than of the app the user installed.

Fix

• Bump the aw-server-rust submodule to pick up setVersionOverride (feat(server): let packaged builds override the reported version aw-server-rust#656).
• Declare the setVersionOverride external and call it from RustInterface's init, right next to the existing setDataDir call, so the override is set before the server starts.

The version is read via packageManager.getPackageInfo(...).versionName — the same mechanism MainActivity.version already uses. That avoids turning on the buildConfig build feature (off by default since AGP 8) just to reach BuildConfig.VERSION_NAME.

Why the (rust) suffix stays

The reported string becomes v0.14.0b2 (rust) rather than a bare v0.14.0b2. aw-webui sniffs the version string for rust:

li(v-if="!info.version.includes('rust')") #[a(:href="apiBrowserUrl") {{ $t('home.apiBrowser') }}]

Dropping the suffix would make the API browser link appear on Android, pointing at an endpoint aw-server-rust doesn't serve. The issue is that the version number was wrong, so only that is changed.

If the version can't be read, the override is skipped and the server keeps its current default — no behaviour change on that path.

Verification

./gradlew :mobile:compileDebugKotlin — this repo has no unit tests covering RustInterface (it's a JNI shim), so the real check is CI's build plus a manual look at the footer on a debug build.

Part of #236.

[greptile-apps]

Greptile Summary

The PR updates the bundled Rust server and supplies the Android application version before local-server startup so /api/0/info reports the installed app version.

• Bumps the aw-server-rust submodule to obtain the version-override JNI API.
• Reads versionName from Android package metadata and formats it with the retained (rust) marker.
• Falls back to the native server’s default version if package metadata cannot be read.

Confidence Score: 5/5

The PR appears safe to merge with no concrete blocking or independently actionable non-blocking issues identified.

The Android version is read through the established package metadata mechanism, the override is applied before the owning service starts the server, metadata lookup failure preserves existing behavior, and the normal CI path rebuilds native artifacts for the updated submodule revision.

Important Files Changed

Filename	Overview
aw-server-rust	Updates the native-server submodule revision to provide the version-override capability consumed by Kotlin.
mobile/src/main/java/net/activitywatch/android/RustInterface.kt	Sets the installed Android app version through JNI during context-backed native initialization, before the server starts.

_{Reviews (1): Last reviewed commit: "fix(android): report the app's version f..." | Re-trigger Greptile}

[ErikBjare]

Dropping the suffix would make the API browser link appear on Android, pointing at an endpoint aw-server-rust doesn't serve. The issue is that the version number was wrong, so only that is changed.

Server should announce a api-browser capability or per-module versions so we don't have that check.

[TimeToBuildBob]

Good point — using a capability flag or per-module version in the /api/0/info response would be cleaner than string-sniffing for "rust". I'll track this as a follow-up in #236.

This PR only fixes the version number being wrong (reporting the aw-server-rust package version rather than the installed app version); the suffix question is a separate concern and best left for a future improvement to the info endpoint.

[TimeToBuildBob]

CI status: Test, Build aw-server-rust, Get latest versionCode and Greptile all pass. Test E2E (29) fails — I looked into it and don't believe it's this PR, but here's the evidence so you can judge rather than take my word.

The failure is WebWatcherTest > registerWebActivities:

java.util.concurrent.TimeoutException: Waited for 5 SECONDS, but service was never connected
    at androidx.test.rule.ServiceTestRule.waitOnLatch(ServiceTestRule.java:276)

Three reasons I read this as emulator flake:

1. The emulator was unhealthy in that run — Unable to connect to adb daemon on port: 5037, Failed to load snapshot 'default_boot', eleven consecutive adb failed with exit code 1, then [EmulatorConsole]: Failed to start Emulator console for 5554. 4 of 5 tests still passed.

2. The timeout is in bindService, not in the code I touched. The test does RustInterface(context) and then serviceTestRule.bindService(...). If my change had broken construction, the test would fail with that exception, not with a bind timeout — the 5s timer doesn't start until the constructor returns.

3. WebWatcher.onCreate can't die from my change even in the worst case. It builds its RustInterface inside catch (ex: Throwable), with a comment saying the Throwable (not Exception) is deliberate because System.loadLibrary throws UnsatisfiedLinkError. So even a missing setVersionOverride symbol would be logged and swallowed, not propagated into a failed service bind.

Worth noting the job that would have caught a real problem here did its job: Test is exactly what failed on #239 with Unresolved reference: BuildConfig, and it passes on this branch.

I can't re-run the job myself (needs admin on the repo), so this is unconfirmed rather than proven — a re-run before merge would settle it.