[Fmx, iOS] Bluetooth LE mit Background-central crasht nach 1 Minute

[Rollo62]

Hallo zusammen,

ich habe hier aus dem Doppelpost der DP-EN,
einen eigenen Thread mit den neuesten Erkentnissen gemacht:

Ich habe einige Tests gemacht, kann aber nicht wirklich sagen, dass ich weiß, was hier los ist.
Es geht um Bluetooth auf IOS mit verschiedenen IoT-Geräten im Hintergrundmodus.

Hier sind ein paar Fakten, die ich sehen kann:

• Die App funktioniert im Vordergrund (FG) einwandfrei und kann im Hintergrund (BG) abstürzen.
• Der BG-Absturz tritt auf, wenn das Telefon das IoT-Gerät verliert, während die Verbindung in BG hergestellt ist.
• Der BG-Absturz kommt in meinem Büro nie vor. Ich kann mich sogar außerhalb der Reichweite bewegen, während das IoT die Verbindung ordnungsgemäß trennt.
  Es kann danach wieder verbunden werden (während die App in BG geöffnet werden kann,
  es kein Neustart der App).
• Die App in BG kann eine Benachrichtigung senden, wenn die Verbindung getrennt wird.
  Dies ist alles in Ordnung.
• Wenn ich in FG verbunden bin, kann ich mich ungefähr 15 m bewegen, die Verbindung bleibt weiterhin stabil (keine Trennung, kein Absturz)
  Wenn ich in BG verbunden bin und mich 15 m bewege, wird die Verbindung getrennt (kein Absturz).
• Es scheint, dass der BG-Betrieb möglicherweise weniger Sendenergie oder weniger QoS hat

Das alles wäre in Ordnung, nur

1. An einigen kritischen Orten stürzt dieselbe App auf demselben Telefon direkt bei Eintritt der BG ab
   Diese Orte sind Büros, in denen viel HF-Rauschen zu sehen ist (etwa 50 BLE-Geräte im Scan, viele WiFi-Geräte, ...).
2. Diese Orte enthalten viele umgebende IoT-Geräte wie Smartwatches und mehrere nahe gelegene (<50 m) WLAN-Firmenrouter
3. An normalen Orten habe ich auch ungefähr 20 IoT-Geräte und einige WiFi-Geräte in der Nähe, aber vielleicht nicht so viele wie oben.

Was an diesen kritischen Orten passiert, ist

1. Die App funktioniert gut im Vordergrund (FG) und stürzt kurz nach Betreten Hintergrund (BG) ab
2. Es wurde noch keine Benachrichtigung gesendet. Dies bedeutet, dass OnDisconnect normalerweise nicht ausgelöst wird
3. Die App kann nicht wirklich protokolliert werden, wie es an normalen Orten möglich ist

Ich habe Experimente mit verschiedenen IoT gemacht, eines 2 Sekunden, eines 12 Sekunden Datenrate, das sind beides zwei verschiedene Geräte (Vielleicht haben sie auch noch andere unterschiedliche Einstellungen).


Das Interessante Verhalten kann ich an den kritischen Orten sehen:

1. die 2sec. Geräte arbeiten in BG, OK - kein Absturz
2. die 12sec. Geräte zeigt alle negativen Verhaltensweisen von oben

Dies führt mich zu der Frage:
Wechseln die iOS-Telefone im BG in einen anderen Energiemodus oder Energiesparmodus,
wenn die Datenrate geringer ist (z. B. > 10 Sekunden)?


Dies wäre meine einzige Erklärung für das seltsame Verhalten, dass schneller sendende Geräte iOS aktiver halten (möglicherweise innerhalb des Bereichs von 10 Sekunden).

Das Telefon verfügt also anscheinend über höhere QOS Funktion, um die Verbindung aufrechtzuerhalten.

Gibt es vielleicht ein Dokument oder eine Website von Apple die ein solches Verhalten erklären würde ?

Ich habe das Web gründlich durchsucht, aber keine passenden Informationen zu meiner Annahme gefunden.
Vielleicht gibt es da draußen bei Euch eine Hilfestellung ?

Das ist eine interessante Lektüre
https://github.com/opentrace-communi...e-ios/issues/4


Auch in Bezug auf die Wiederherstellung nach dem Hintergrundzustands (BG).

Ich habe das Wiederherstellen noch nicht implementiert, das könnte natürlich helfen,
aber es wird in FMX nicht unterstützt.
Das Problem ist aber das die App echt abstürzt, was aber auch an meiner Umsetzung in BLE liegen kann (das war ursprünglich nur für FG gedacht).
Jedenfalls scheinen an den kritischen Orten andere Events zu feuern, oder sonst etwas anders zu Laufen als in FG.
Ich kann das aber weder debuggen noch vernünftig loggen, ich versuche gerade eine ganz abgespeckte Version zu bauen.

[philipp.hofmann]

Hi Rollo,

hast du dieses Problem lösen können? Ich habe auch mittlerweile ein paar User, die mir melden, dass meine App manchmal unter iOS abstürzt, wenn sie während der Nutzung in eine andere App wechseln und dann zurückkommen. Dabei sind mehrere BLE-Verbindungen zu einem Leistungsmesser, einem Herzfrequenz-Gurt, u.ä. aufgebaut. NSBluetoothAlwaysUsageDescription und NSBluetoothPeripheralUsageDescription sind natürlich gefüllt und ich habe die UIBackgroundModes audio, bluetooth-central und bluetooth-peripheral aktiviert.

Ich sorge mit dem folgenden Request alle 100 Sekunden, dass die Anwendung auch ohne Interaktion aktiv bleibt:

Delphi-Quellcode:

  UIApp:=TUIApplication.Wrap(TUIApplication.OCClass.SharedApplication);
  UIApp.setIdleTimerDisabled(activate);

Grüße, Philipp

[Rollo62]

Ich habe es meistens so lösen können dass ich möglichst auf echte Background-Modes verzichte.
Die scheinen die Hauptursache von Problemen zu sein.

Trotzdem habe ich Apps die im Bluetooth aktiv bleiben müssen, und die werden durch regelmäßige Sendungen von den IoT Geräten getriggert.
Das bluetooth-peripheral muss ich nicht mehr setzen, das war nur mal ein Test um die App wach zu halten, die App ist aber
ein bluetooth-central.
Es scheint in den letzteren OS Version auch stabiler geworden zu sein hinsichtlich BLE, Hintergrund-Standort brauche ich nicht mehr.

Der Ablauf im Hintergrund funktioniert bei mir so:
- Es muss immer im Vordergrund aufgebaut werden
- Es scheint bluetooth-central zu reichen
- Im Hintergrund kommen regelmäßige Sendungen vom IoT welche die App wach halten, von ca. 4-12 Sek.
- Wenn die App im Hintergrund das Gerät verliert habe ich noch kein automatisches Wiederverbinden vorgesehen, sondern eine Notification.
- Plötzliche Abstürze sehe ich hier selten, es scheint aber immer mal wieder vorzukommen.
Woran das liegt kann ich nicht wirklich sagen.

Ich habe über die Zeit auch an vielen iOS (und Android) Bugs rumgedocktert, oft scheint es einfach am iOS zu liegen.
Ein Neues SDK behebt das dann, ich vermeide trotzdem immer das Neueste einzusetzen, erst nachdem es gut getestet ist.
Eine gleichbleibende Qualität beim Debuggen sehe ich irgendwie nicht, mal fluppt Alles wie es soll, mal klemmt es hier und da und stürzt ab.
Das passiert komischerweise auch von einen Tag auf den Anderen, ohne das man etwas anfasst oder sogar den Rechner neustartet.
Ein Neustart aller Systeme hilft übrigens dann auch nichts, manchmal ist ein und dieselbe App superstabil, mal crasht es, ohne wirkliche Code-Änderung.
Eine Vermutung war schon früher immer, dass ein einfaches Umbauen der uses Units ( in eine andere Reihenfolge ) solche Probleme verhindern kann, also dass es durchaus auf die Linker-Reihenfolge ankommen kann.
Das hatte ich ein paar mal gesehen, dass ein Umstrukturieren von uses Crashes verhindern kann, konnte das aber nie wirklich nachweisen.
Deshalb versuche ich immer möglichst kleine Units zu halten, in der Hoffnung dass der Linker damit besser optimieren kann und vielleicht Bereichsgrenzen vermeiden kann.
Ich habe auch sehr oft kleine Tests und Demos gebaut, die sehr stabil Laufen.
Sobald ich dass dann in größere Anwendungen übernehme kommen wieder sporadische Probleme.
Insbesondere sehe ich immer noch dass bei Verlust der Verbindung die Characteristics oder Devices noch lange verbunden bleiben können und/oder Abstürzen.
Das Verhalten hängt bei mir aber auch stark von den Geräten selbst ab die ich verbinde, da habe ich eine ganze Reihe mit ganz verschiedenen MCU's und BLE-Stacks, wo ich nicht wirklich sagen kann was da der Unterschied bei der Verbindung, Parametern, Timing, usw. ist.
Nur das manche Geräte in derselben App problemlos Laufen und andere nicht, ohne das es einen ersichtlichen Unterschied gäbe.