Fix/android anr advert throttle

[1technophile]

Description:

Summary

Two Android stability fixes for crash clusters seen in 1.5.0, plus diagnostics to measure them. All BLE-advert processing and Android rendering related; validated on two physical phones.

1. IME ANR — per-device BLE advertisement throttle (8b8c440)
2. EGL makeCurrent abort — force the basic render loop on Android (460cca8)
3. Instrumentation — make the throttle's effect + GUI-thread responsiveness readable on any device (9b0d10f)

Reviewable commit-by-commit.

---

1. fix(android): throttle per-device BLE adverts to prevent IME ANR

Symptom: ANR with main (Android UI) thread stack
handleWindowFocusChanged → IME startInput → QtEditText.onCreateInputConnection → QtInputConnection.getExtractedText → QMetaObject::invokeMethodImpl → QMetaMethodInvoker::invokeImpl → futex.
Root cause: getExtractedText() is a Qt::BlockingQueuedConnection round-trip from the Android UI thread into the Qt GUI thread (qtMainLoopThread). bleDevice_updated() decodes + updates the model synchronously on that GUI thread for every
advertisement the OS delivers. In a dense BLE field the flood of queued deviceUpdated events keeps the GUI thread out of its event loop; when a focused text field then triggers the IME round-trip and the GUI thread can't service it within Android's
5 s input-dispatch deadline, the app ANRs.

Fix: coalesce adverts to at most one decode per device per second, so the per-device processing rate — and thus the GUI-thread backlog — is bounded at the source. The first advert from a device always passes (new devices appear immediately); the
nearby/RSSI-finder path (updateNearbyBleDevice) is separate and unaffected; a small prune keeps the map bounded against MAC-rotating devices. Also hoists the per-iteration TheengsDecoder construction to one instance per call.

2. fix(android): force basic render loop to avoid EGL makeCurrent abort

Symptom: hard abort() with QRhi::beginFrame → QOpenGLContext::makeCurrent → libqtforandroid → QMessageLogger::fatal → abort on a render thread (1.5.0 field crashes, Android 16).

Root cause: the threaded Qt Quick render loop races the Android SurfaceView lifecycle across background/foreground transitions. When eglCreateWindowSurface fails mid-transition, QAndroidPlatformOpenGLWindow::ensureEglSurfaceCreated() calls
qFatal(). Still unfixed upstream (present in qtbase v6.10.3 / 6.10 / dev; tracked loosely by QTBUG-142195), so a Qt bump doesn't help. Theengs is unusually exposed because its foreground BLE-scan service keeps the process alive across many surface
destroy/recreate cycles.

Fix: qputenv("QSG_RENDER_LOOP", "basic") on Android (only if unset) before QGuiApplication, moving rendering onto the GUI thread serialized with surface events — removing the race. An explicit override is still respected.

Trade-off: the basic loop renders on the GUI thread, so heavy scenes can show more frame jank than the threaded loop. Accepted in exchange for eliminating the abort; no ANR observed in testing.

3. feat(android): instrument BLE advert throttle + GUI-thread stall

Lightweight, always-on diagnostics (the throttle's benefit only manifests under field BLE density, which a single-radio test bench can't synthesize):

• m_advert_recv / m_advert_throttled → drop rate (how often the throttle actually binds).
• A 250 ms watchdog QTimer on the GUI thread → max event-loop stall (ms), the ANR proxy (a blocked loop can't service the IME round-trip).
• Logged as [ble-perf] adverts recv=… throttled=… (…%) | tracked MACs=… | max GUI-loop stall=… ms ~every 60 s (captured by logcat / debug-log-share), plus bleThrottleStats() / resetBleStats() Q_INVOKABLEs for a debug screen.

---

Validation (physical devices)

	LG H930 (Android 9)	Galaxy S20 FE (Android 13)
Throttle binds (ambient BLE)	recv=317 throttled=99 (31%), 29 MACs	recv=1149 throttled=586 (51%), 39 MACs
Max GUI-loop stall	1211 ms	1095 ms
Decode → display	✅ multiple device types, correct values	✅ multiple device types, correct values
EGL surface-cycle stress (20×)	n/a	✅ PID stable, no qFatal/abort; race caught non-fatally (makeCurrent(): no EGLSurface warnings)
Render under basic loop	✅	✅ no blank screen

The throttle sheds ~⅓–½ of advert-processing load in normal ambient BLE (dozens of devices) — confirming it's active in everyday conditions, not just pathological density. The decode matrix is unaffected (the throttle changes processing rate, not
what decodes).

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.