hostStreamingState) #223

New issue

Open

opened 2026-03-02 12:04:34 +03:00 by kerem · 0 comments

kerem commented

2026-03-02 12:04:34 +03:00

Owner

Originally created by @carsond135 on GitHub (Feb 3, 2026).
Original GitHub issue: https://github.com/kavishdevar/librepods/issues/446

Summary

A case discrepancy has been found between TLV key strings in the Rust and Kotlin source code, specifically for Smart Routing fields such as PlayingApp vs playingApp and HostStreamingState vs hostStreamingState.

Details

Rust source (linux-rust/src/bluetooth/aacp.rs):
- In send_media_information_new_device, keys are used with lower-case starts: "playingApp" and "hostStreamingState".
- In send_media_information, the same keys are used with capitalized case: "PlayingApp", "HostStreamingState".
Kotlin source (android/app/src/main/java/me/kavishdevar/librepods/utils/AACPManager.kt, main branch):
- Similar inconsistencies or choices appear in the TLV/string keys used for Smart Routing.

Questions/clarification sought

Is this difference in case intentional or a typo?
Should the case of these field names be normalized across platforms (Rust and Kotlin), or does the protocol require specific casing in each context?
Are there potential interop issues or device behavior changes if this case mismatch persists?

Related snippets:

Rust, lines 958/962 vs 1031/1035 in aacp.rs.
Kotlin, in AACPManager.kt, Smart Routing payload code (details can be provided if needed).

Steps to reproduce

Compare both implementations: Rust module versus Kotlin source for Smart Routing payload construction.
Observe the difference for PlayingApp/playingApp and similar field names.

Main goal:
Seeks clarification on protocol field casing, and whether normalization/fix is required.

CC: maintainers & anyone with protocol reverse engineering experience.

Originally created by @carsond135 on GitHub (Feb 3, 2026). Original GitHub issue: https://github.com/kavishdevar/librepods/issues/446 ## Summary A case discrepancy has been found between TLV key strings in the Rust and Kotlin source code, specifically for Smart Routing fields such as `PlayingApp` vs `playingApp` and `HostStreamingState` vs `hostStreamingState`. ## Details - **Rust source** (`linux-rust/src/bluetooth/aacp.rs`): - In `send_media_information_new_device`, keys are used with lower-case starts: `"playingApp"` and `"hostStreamingState"`. - In `send_media_information`, the same keys are used with capitalized case: `"PlayingApp"`, `"HostStreamingState"`. - **Kotlin source** (`android/app/src/main/java/me/kavishdevar/librepods/utils/AACPManager.kt`, main branch): - Similar inconsistencies or choices appear in the TLV/string keys used for Smart Routing. ## Questions/clarification sought - Is this difference in case intentional or a typo? - Should the case of these field names be normalized across platforms (Rust and Kotlin), or does the protocol require specific casing in each context? - Are there potential interop issues or device behavior changes if this case mismatch persists? --- **Related snippets:** - Rust, lines 958/962 vs 1031/1035 in `aacp.rs`. - Kotlin, in `AACPManager.kt`, Smart Routing payload code (details can be provided if needed). ## Steps to reproduce 1. Compare both implementations: Rust module versus Kotlin source for Smart Routing payload construction. 2. Observe the difference for `PlayingApp`/`playingApp` and similar field names. --- **Main goal:** Seeks clarification on protocol field casing, and whether normalization/fix is required. --- CC: maintainers & anyone with protocol reverse engineering experience.