Android BluetoothAdapter.setName() gibt „true“ zurück, aber die ACTION_LOCAL_NAME_CHANGED-Übertragung wird nie ausgelöst ⇐ Android

[Anonymous]

Ich arbeite an einer Android-App, die den Bluetooth-Gerätenamen mithilfe von BluetoothAdapter.setName() programmgesteuert ändert. Die App muss wissen, wann die Namensänderung abgeschlossen ist, um nachfolgende Aktionen auszulösen (Starten von BLE-Werbung).
Erwartetes Verhalten:

• Call mBtAdapter.setName("NEW_NAME")
• Methodenrückgaben 

  Code: Select all

  true

   (Erfolg)
• ACTION_LOCAL_NAME_CHANGED Broadcast wird ausgelöst
• Fahren Sie mit den nächsten Schritten fort

Beobachtetes Verhalten auf einigen Geräten:

• setName() gibt zurück 

  Code: Select all

  true

• Aber ACTION_LOCAL_NAME_CHANGED Broadcast wird NIEMALS ausgelöst

Betroffene Geräte/Szenarien:

• Beobachtet auf OnePlus Nord 4 und mehreren anderen Geräten
• Scheint häufiger auf Android 10+-Geräten aufzutreten
• Hängt möglicherweise mit schnellen aufeinanderfolgenden Namensänderungen zusammen
• Möglicherweise hängt es mit den Bluetooth-Datenschutzverbesserungen von Android zusammen

**Aktuelle Problemumgehung/Lösung:
Ich habe einen Hybridansatz implementiert, der Broadcast-Listening mit einem Fallback-Timeout-Mechanismus kombiniert:**

Code: Select all

// 1. Store expected name and set timeout handler
mExpectedBTName = name;
boolean success = mBtAdapter.setName(name);
if (!success) {
// Immediate failure - handle it
sendEvent(EVENT_BT_ADVERTISING_FAILED, null);
return;
}

// 2. Set fallback timeout (3 seconds)
mNameChangeTimeoutHandler = new Handler(Looper.getMainLooper());
mNameChangeTimeoutHandler.postDelayed(new Runnable() {
@Override
public void run() {
String updatedName = mBtAdapter.getName();
if (name.equalsIgnoreCase(updatedName)) {
// Name was changed, broadcast just didn't fire
startAdvertising();
} else {
// Name change actually failed
sendEvent(EVENT_BT_ADVERTISING_FAILED, null);
}
mNameChangeTimeoutHandler = null;
}
}, 3000);

// 3. Broadcast receiver
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equalsIgnoreCase(BluetoothAdapter.ACTION_LOCAL_NAME_CHANGED)) {
// Cancel timeout if broadcast is received
if (mNameChangeTimeoutHandler != null) {
mNameChangeTimeoutHandler.removeCallbacksAndMessages(null);
mNameChangeTimeoutHandler = null;
}

String currentBTName = intent.getExtras().getString(BluetoothAdapter.EXTRA_LOCAL_NAME);
if (mExpectedBTName != null && currentBTName.equalsIgnoreCase(mExpectedBTName)) {
mExpectedBTName = null;
startAdvertising();
}
}
}

Fragen:

• Ist das ein bekanntes Android-Bluetooth-Stack-Problem? Ist das noch jemandem aufgefallen?
• Gibt es eine bessere Möglichkeit, zuverlässig zu erkennen, wann die Bluetooth-Namensänderung abgeschlossen ist?
• Gibt es irgendwelche Risiken? mit dem Fallback-Polling-Ansatz? Könnte die Überprüfung von getName() in bestimmten Zuständen unzuverlässig sein?

Umgebung:

• Min. SDK: 24
• Ziel-SDK: 33
• React Native App mit nativem Bluetooth-Modul
• Verwendung der Berechtigungen „BLUETOOTH_CONNECT“, „BLUETOOTH_SCAN“, „BLUETOOTH_ADVERTISE“

Jeder Einblick oder alternative Ansätze wäre sehr dankbar!