fix: ConcurrentModificationException in getAudioDeviceStatusMap

[qiixiao]

Fix ConcurrentModificationException caused by iterating audioDevices while it's being modified on another thread.

Copy audioDevices to a new ArrayList before iterating to avoid concurrent modification.

[Copilot]

Pull request overview

This PR aims to prevent a ConcurrentModificationException when building the audio-device status payload (getAudioDeviceStatusMap) by iterating over a snapshot of audioDevices rather than the live set.

Changes:

• Iterate over a copied collection of audioDevices when building availableAudioDeviceList.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[qiixiao]

Thanks for the review — both points are valid.

1. Compile error: right, java.util.ArrayList was missing. Fixed by adding the import.
2. Snapshot doesn't fully prevent CME: agreed. The root cause is that audioDevices is a plain HashSet mutated from multiple threads —start() / chooseAudioRoute() run on the RN bridge thread while updateAudioDeviceState() runs on the UI thread, so even constructing the snapshot iterates a concurrently-modified set.

To fix it properly (and keep the change minimal), I switched audioDevices from HashSet to ConcurrentHashMap.newKeySet(). Iteration / snapshot construction is then weakly consistent and never throws CME. Since the field was previously reassigned (audioDevices = newAudioDevices), I changed that to clear() + addAll() so the concurrent set is updated in place rather than swapped out from under concurrent readers.

The new ArrayList<>(audioDevices) snapshot is retained so the JSON payload reflects a single point-in-time view rather than a live set.

[qiixiao]

switch audioDevices to a concurrent set and update in place