Case discrepancy in Smart Routing TLV keys between Rust and Kotlin code (PlayingApp/playingApp, HostStreamingState/hostStreamingState)

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.

Compare the Smart Routing TLV construction in linux-rust/src/bluetooth/aacp.rs, especially the named functions and lines 958/962 and 1031/1035, with the corresponding payload code in android/app/src/main/java/me/kavishdevar/librepods/utils/AACPManager.kt. Determine the protocol-required casing and whether the mismatch affects interoperability. Done means the casing decision is established and any required cross-platform changes are covered.