Hallo Zusammen,

für ein Bluetooth-Projekt in dem unter Androuid die MTU angepasst werden soll ist es für mich notwendig zu erfahren,
auf welchen MTU-Wert sich die verwendeten Geräte nach einem Aufruf der "requestMtu"-Funktion geeinigt haben.

Die "TBluetoothLEDevice.RequestMtu"-Funktion löst dabei im "Android Device Monitor" die folgenden Events aus:

BluetoothGatt: configureMTU() - device: XX:XX:XX:XX:XX:XX mtu: 512
BluetoothGatt: onConnectionUpdated() - Device=XX:XX:XX:XX:XX:XX interval=6 latency=0 timeout=500 status=0
BluetoothGatt: onConfigureMTU() - Device=XX:XX:XX:XX:XX:XX mtu=23 status=0

Nun habe ich gesehen, dass es in der Datei "Androidapi.JNI.Bluetooth.pas" die folgende Deklaration gibt:

markieren

Code:

[JavaSignature('android/bluetooth/BluetoothGattCallback')]
  JBluetoothGattCallback = interface(JObject)
    ['{E07848AC-B968-4C94-9F67-4DC5E62CB8D3}']
 ...
    procedure onMtuChanged(gatt: JBluetoothGatt; mtu: Integer; status: Integer); cdecl;
 ...
  end;

Allerdings gibt es hierzu keine weitere Implementierung.

Meine Idee wäre nun gewesen, in der Klasse "TAndroidBluetoothGattListener" aus "System.Android.Bluetooth" die folgende Prozedur anzulegen:

markieren

Code:

procedure TAndroidBluetoothGattListener.onMtuChanged(gatt: JBluetoothGatt; mtu, status: Integer);

und hier dann den Wert über weitere Funktionen am Vorbild der anderen Funktionsimplementationen nach oben hin durchzuschleifen:

markieren

Code:

  FGatt.DoOnMTUChanged(FGatt, mtu, TBluetoothGattStatus(status))

Zum aktuellen Stand sieht es für mich aber so aus, als wenn die "TAndroidBluetoothGattListener.onMtuChanged"-Funktion gar nicht erst aufgerufen werden würde.
Kann mir jemand von euch einen Tipp geben, wie oder wo ich dieses Event Implementieren kann, sodass ich es durch die verschiedenen Bluetooth-Klassen in meine Logik durchschleifen kann?

Vieleicht hängt es auch einfach von der Implementierung des IoT-Gerätes ab.
https://punchthrough.com/android-ble-guide/

Zitat:

Unfortunately, we’ve also seen the onMtuChanged() callback not getting delivered sometimes when working with closed source firmware, which can put a damper on things if the app is relying on the callback being delivered before proceeding with something. Our advice is to always assume the worst case — that the ATT MTU is at its minimum value of 23 — and to plan around that when working with closed source firmware, with any successful onMtuChanged() calls being considered as added bonuses.

Ich bin nicht sicher ob der Event automatisch bei Verbindung gesendet wird, oder erst auf Anfrage nach requestMTU.