Add Bluetooth support for WearOS devices

[SBALAVIGNESH123]

This pull request adds full Bluetooth transport support for WearOS devices in MicroG, enabling basic wearable functionality without relying on Google Play Services. It introduces a new BluetoothWearableConnection class that implements a Bluetooth Classic RFCOMM transport using the standard SPP UUID and handles length-prefixed protobuf messages. The WearableImpl has been updated with a background ConnectionThread that automatically scans bonded devices at startup, attempts to connect using the new Bluetooth transport, and includes a 10-second reconnection loop while preserving existing TCP/IP handling. The Android manifest now includes the required Bluetooth permissions, including the newer Android 12+ BLUETOOTH_SCAN and BLUETOOTH_CONNECT. In testing, the connection successfully paired with a Pixel Watch and logged stable Bluetooth sessions, working alongside the TCP mechanism. Current limitations include broad connection attempts across all bonded devices and reliance on the general SPP UUID, though this foundation can be expanded with device-specific UUID detection, improved state management, and UI integration. This work closes issue microg#2843, relates to the long-standing issue microg#4, and fulfills the bounty request for foundational WearOS functionality such as notification sync, app communication, and media control within the existing MicroG wearable framework.

---

Note

• WearOS Bluetooth transport: New BluetoothWearableConnection (RFCOMM SPP) and connection thread in WearableImpl; manifest gains BLUETOOTH_CONNECT; settings UI lists bonded devices; robust deserialization and permission checks added.
• Identity API enhancements: IAuthorizationService adds revokeAccess/clearToken; implementation persists per-app account via new AccountUtils, returns access/id tokens appropriately, and supports token invalidation.
• Package cleanup + GCM updates: Replace UnregisterReceiver with trusted receiver + PackageIntentOpWorker (WorkManager) to clear GCM/auth data on package changes; GCM broadcast action renamed to CONNECTED and flow adjusted; UI triggers updated.
• Play Integrity controls: New PLAY_INTEGRITY_APP_LIST setting, PlayIntegrityData model, and UI in SafetyNet (renamed to Device Attestation) to view/toggle per-app access; vending-side services track/update visit status; integrity/express services enforce enablement and per-app allow list.
• Vending services: Add in-app review service/activity returning a confirmation intent; asset module service gains thread-safety and session merging; dev-triggered update reports availability.
• Location/Maps fixes: Safer Wi‑Fi info handling, telephony-aware Ichnaea requests, lifecycle/parcelable and projection/UI settings refinements.
• Build/infra: Actions checkout v6; add WorkManager (work-runtime-ktx) dependency and version; minor string/localization updates.

^{Written by Cursor Bugbot for commit 7f8a5d0. This will update automatically on new commits. Configure here.}

[deadYokai]

adopted Wearable lib to Wire 4.9.9, but i unable to test it, cuz i dont have compatable device

https://github.com/deadYokai/Wearable/tree/wire_upd

[SBALAVIGNESH123]

Thanks @deadYokai for the Wire 4.9.9 update! 🙏

I really appreciate you taking the time to adapt the Wearable library. This will be important for keeping everything compatible with the latest protobuf changes.

I don't have a physical WearOS device for testing either at the moment. Would you like me to integrate your changes from your 'wire_upd' branch into this PR? Or would you prefer to submit them separately?

Happy to collaborate on getting this working together!

[deadYokai]

@SBALAVIGNESH123 i already submited PR to microg/Wearable#3 , i'm waiting for approving

You can intergrate changes, but as far as PR not merged, can't be compatable with current version of GmsCore / Wearable

And also, i'm trying to implement BluetoothGatt protocol, as far i know it's used by WearOS 3+ devices

[deadYokai]

found UUID in google's gms

bluetoothSocketCreateRfcommSocketToServiceRecord = this.h.createRfcommSocketToServiceRecord(UUID.fromString("5e8945b0-9525-11e3-a5e2-0800200c9a66"));

maybe i make own implementation of bluetooth stuff?

[SBALAVIGNESH123]

Hey @deadYokai, yes that would be great!
Go ahead with your own implementation of the BluetoothGatt protocol. The UUID you found (5e8945b0-9525-11e3-a5e2-0800200c9a66) is the right one for the RFCOMM socket.

[cursor]

This is the final PR Bugbot will review for you during this billing cycle

Your free Bugbot reviews will reset on February 19

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Double call to nullable function creates race condition

The toWifiDetails() function is called twice on the same connectionInfo object - once in the condition check and again in the body. Since WifiInfo.toWifiDetails() can return null when bssid is null, and WiFi state can change between calls, there's a time-of-check to time-of-use issue. If the bssid becomes null between the two calls, the second call returns null, resulting in listOfNotNull producing an empty list and onWifiDetailsAvailable silently doing nothing. The result should be captured in a variable to ensure atomic evaluation.

 

[cursor]

Bluetooth handshake sends invalid Android ID

The manual Connect message sent during Bluetooth handshake uses peerAndroidId(0L) instead of the actual device Android ID. This contradicts how MessageHandler is configured, which retrieves the real Android ID from device settings via SettingsContract.CheckIn.ANDROID_ID. Sending a hardcoded zero for the Android ID could cause WearOS devices to reject the connection or fail to properly identify the phone during pairing. The handshake should use the same Android ID that MessageHandler uses for consistency.

 

[eepymeowers]

Is this buildable yet? If it is I'll try it out! I have a GW5 I've been wanting to use.

[cursor]

Sign-out callback invoked before async operations complete

High Severity

The signOut method calls callback.onResult(Status.SUCCESS) at line 147 immediately after launching the coroutine, rather than inside it. This means the callback signals success before the actual sign-out operations (performSignOut, removeSelectedAccount) have completed. Comparing with AuthSignInService.kt which correctly places the callback inside the lifecycleScope.launchWhenStarted block, this callback should be moved inside the lifecycleScope.launch block after the sign-out operations finish. Calling apps will incorrectly believe sign-out is complete when it hasn't actually happened yet.

🔬 Verification Test

Why verification test was not possible: This is an Android service implementation that requires the full Android runtime environment, lifecycle management, and IPC mechanisms to test. The bug is clearly visible from static code analysis - comparing line 147 (callback outside the coroutine) with the similar implementation in AuthSignInService.kt lines 134 (callback inside the coroutine).

 

[cursor]

Projection field never updated causing stale fallback data

Medium Severity

The updateProjectionState method accepts a projection parameter that shadows the class field this.projection. While the method correctly uses the parameter to update cached values like visibleRegion, farLeft, etc., it never updates this.projection itself. The previous implementation included projection = newProjection to update the class field. When the fallback paths are taken in fromScreenLocation (lines 74, 87) and toScreenLocation (lines 100, 113)—which happens when isInvalid() returns true or withoutTiltOrBearing is false—the code uses the stale this.projection from initialization rather than the current projection state, leading to incorrect map coordinates.

🔬 Verification Test

Why verification test was not possible: This requires the Huawei HMS Maps SDK runtime environment and actual map interactions to test. The bug is evident from static analysis: the old code updated this.projection = newProjection (visible in the diff's removed line), but the new code removes this assignment while the fallback paths at lines 74, 87, 100, and 113 still reference this.projection.

 

[cursor]

SharedPreferences type mismatch causes ClassCastException on upgrade

High Severity

The getAuthOptions method calls preferences.getStringSet() directly on a key that was previously stored as a String by the old setDefaultSignInInfo method (using putString). When Android's SharedPreferencesImpl loads a String value and the code attempts to read it as a StringSet, it throws a ClassCastException because the internal map contains a String object that cannot be cast to Set<String>. While setAuthInfo uses runCatching to safely attempt reading old String data during migration, getAuthOptions lacks this protection. Users upgrading from older versions who have existing sign-in options stored will crash when calling sign-out or revoke-access operations that invoke getAuthOptions before any new sign-in triggers the migration path in setAuthInfo.

🔬 Verification Test

Why verification test was not possible: This requires testing against a real Android SharedPreferences implementation with pre-existing String data from an older app version. The bug is evident from comparing the old code (which used putString/getString for options) with the new code (which uses getStringSet without type-safe reading). Android's SharedPreferencesImpl.getStringSet performs an unchecked cast (Set<String>) mMap.get(key) that will fail if the stored value is a String.