TBluetoothLE: DiscoverServices() erkennt unter Android manchmal keine Services

[philipp.hofmann]

Hi,

ich habe das Problem, dass
TBluetoothLE.DiscoverServices()
bei einem verbundenen Geräte keine Services erkennt. Ich kann die Suche auch wiederholen, das hilft leider nicht. Es scheint mir bisher nur unter Android ein Problem zu sein. Hat da jemand eine Idee?

Grüße, Philipp

[TurboMagic]

Welche Delphi version? 10.3.0, 10.3.1 oder 10.3.2?
Welches Android?
Finden ggf. andere Apps die BLE können diesen Dienst?
Werden andere BLE Dienste von der Komponente gefunden?

[philipp.hofmann]

Delphi 10.3.2, sowohl bei einem Samsung S4-Tab (Android 9.0, dort aber selten) als auch bei einem Amazon Fire HD 10 (basiert auf Android 5.1, dort passiert es häufiger).
Ich habe es jetzt auch mal mit dem BLE-Scanner-Projekt ausprobiert, um meine Fehler auszuschließen.

Dort kommt er in folgendem Aufruf für DiscoverServices mit false zurück und das deutlich schneller als die in der Android-BLE-Implementierung definierten 15 Sekunden:
TThread.CreateAnonymousThread(procedure begin
if not BluetoothLE1.DiscoveredDevices[ListBox1.ItemIndex].DiscoverServices then
TThread.Synchronize(nil, procedure begin
Listbox2.Items.Add('- Discover services not allow');
Listbox1.Enabled := True;
end);
end).Start;

Mal passiert es, mal nicht, jetzt bin ich gerade wieder im Modus, es funktioniert auf beiden Devices.
Ich kann keine Gesetzmässigkeit nach dem Motto Android-Device neu gestartet oder BLE-Device neu gestartet erkennen.
Sobald er es einmal geschafft hat, geht es auch reproduzierbar.

Ich habe jetzt mal log-Ausgaben dazugepackt, auch in die Android BLE-Implementierung (System.Android.Bluetooth.pas) um vielleicht besser zu verstehen, was da schief geht. Noch habe ich nicht so richtig die Idee, v.a. weil es nicht reproduzierbar ist, aber so oft schief geht, dass es dem Enduser nicht zumutbar ist.

[knaeuel]

Möglicherweise ist das noch dasselbe Problem, wie mit 10.2 vor etwa einem Jahr. Für mich hats damals funktioniert, wenn ich einfach nur die BLE-Komponente einmal disabled hab.

in etwa so:
- BLE ist unsere TBluetoothLE-Komponente

Code:

BLE.enabled:=true
Geräte_suchen
if Gerät_gefunden then
begin
  Services_suchen
  if services_nicht_gefunden then
  begin
    BLE.Enabled:=false;
    und nochmal von vorn
  end
end
else
begin
  BLE.enabled:=false; 
  und nochmal von vorn
end

vielleicht hilfts ja immer noch

[philipp.hofmann]

Danke, hört sich einfach an, probiere ich aus und poste dann das Ergebnis.

[knaeuel]

Problem gelöst?

[TurboMagic]

Ich glaube nicht, aber ist es in QP erfasst?
(sorry, habe nicht den ganzen Thread nochmal nach dieser Info abgesucht)
Falls noch nicht erfasst umgehend erfassen!
Lt. Roadmap soll ja im in Entwicklung befindlichen 10.3.3 das AppThethering
verbessert werden, evtl. könnten in dem Rahmen auch andere Fioxes zu BLE einfließen?

[philipp.hofmann]

Hi,

Ich habe einen anderen Workaround für das Problem gefunden.
Zwischen
res:=bleDevice.Connect();
und
res:=bleDevice.DiscoverServices();
muss für Android bei langsamen Tablets (oder Tablets mit Android <6.0, kann den echten Grund nicht wirklich benennen) ein
Sleep(1000)
eingetragen werden und dann findet er auch stabil Services. Es reicht auch nicht aus, nach einer Pause ein zweites DiscoverServices nachzuschießen, es musste bei mir zwingend vor dem ersten sein, damit es funktioniert. Mit dem Workaround kann ich gut leben.

Grüße, Philipp

[TurboMagic]

Wurde das Problem schon in QP erfasst? Falls nein bitte tun und falls ja den Workaround von heute als Kommentar oder als Textänderung hinzufügen, damit wir das in Zukunft mal "out of the box" gefixed bekommen.

[AuronTLG]

Zitat:

Wie ich weiter oben schon schrieb, damit schlage ich mich auch manchmal rum. Eine Besserung hat mein Workaround aus
https://www.delphipraxis.net/201976-...-services.html
gebracht. Du kannst ja mal ausprobieren, ob es auch bei dir hilft.

Basierend auf diesem Thread mache ich mal hier weiter:

Ich habe das Ganze mal so ausprobiert, wie hier beschrieben mit einem Connect -> Sleep(1000) -> DiscoverServices, hat aber leider nicht geholfen.
Das Problem ist bei mir auch anders:

Es ist nicht so, dass das DiscoverServices nichts findet, sondern dass es direkt false zurückliefert.
Auf meinem S10 mit Android 10 schlägt das DiscoverServices jedes Mal auf diese Weise fehl in meiner App. Die Demo "BLEScanner" findet die Services jedoch jedesmal, obwohl der Code praktisch 1 zu 1 identisch ist.

Nachtrag:

Ich hab das Demoprojekt "BLEScanner" nahtlos als Form in meine App eingefügt, woraufhin damit haargenau dasselbe Problem auftritt. Es muss also irgendwas mit der App sein, was das Problem verursacht...

Nachtrag 2:

Demoprojekt "BLEScanner" mit 10.3.3 und brandneuer SDK kompiliert funktioniert ebenfalls nicht mehr mit dem S10. Mit dem S9+ weiterhin problemlos. Was ein Schwachsinn...

[philipp.hofmann]

Das ist leider das Verhalten: das Sleep vor dem DiscoverServices sorgt in den meisten Fällen nur dafür, dass danach auch wirklich etwas zurückkommt. Mit der Schnelligkeit der Antwort von DiscoverServices hat es nichts zu tun. Das antwortet immer schnell, auch wenn es (noch) nichts zu antworten hat.

[AuronTLG]

Und bei euch funktioniert das alles auch mit Android 10 Smartphones?

Dann würde mich nämlich mal eure Konfiguration interessieren (SDK, NDK etc...), denn so langsam gehen mir die Ideen aus.

Ich benutze Delphi 10.3.3 mit der Android SDK 25.2.5 32bit. Alles, was man über Android Tools bekommen ist, ist auf dem neusten Stand, d.h. NDK, Build Tools, Platform Tools, Bibliotheken etc.
AndroidManifest.Templates sind auch sicherheitshalber gelöscht, Projekt bereinigt worden etc...

Sobald ich mit dem Samsung S10 das DiscoverServices ausführe, liefert es false zurück. Lustigerweise, wenn ich die App direkt danach komplett schließe und wieder aufmache, funktioniert es einmal. Nach weiterem Schließen und wieder aufmachen nicht etc...
Völlig bekloppt. Und ich finde keine Möglichkeit, festzustellen, warum DiscoverServices false liefert.
Mehrmals versuchen mit Sleep dazwischen bringt nichts, die hier erwähnte Konstruktion mit Connect -> Sleep -> DiscoverServices bringt auch nichts, aus dem Thread rausnehmen und im Hauptthread ausführen bringt nichts.

[TurboMagic]

Hallo,

schon mal die Berechtigungen verlgichen?
In neueren Android versionen braucht's für BT discovery zumindest "coarse location".

Grüße
TurboMagic

[AuronTLG]

Das neue Berechtigungsmodell hab ich schon seit 10.3.1 integriert. Darunter auch die Permissions Coarse Location und Fine Location.

[TurboMagic]

Berechtigungen: gut. Ist das schon in QP erfasst?
Und falls Subscribtion Kunde: ruhig einen Supportfall
im EMBT Supportportal (nicht QP) erfassen. Dann meldet
sich jemand von EMBT direkt!

Nur falls uns hier die Ideen ausgehen...

[AuronTLG]

Ich werde nach einem letzten Test wohl ein Ticket aufmachen, wobei ich jetzt noch einen Anhaltspunkt gefunden habe.

Im Prinzip habe ich in den Original-Java-Quelltext von Android hineingeschaut und DiscoverServices gesucht.
Diese sieht folgendermaßen aus:

Code:

public boolean discoverServices() {
        if (DBG) Log.d(TAG, "discoverServices() - device: " + mDevice.getAddress());
        if (mService == null || mClientIf == 0) return false;
        mServices.clear();
        try {
            mService.discoverServices(mClientIf, mDevice.getAddress());
        } catch (RemoteException e) {
            Log.e(TAG, "", e);
            return false;
        }
        return true;
    }

Wie man sehen kann, liefert diese Methode unter zwei Umständen "false" zurück.
Da bei der zweiten Option im try-catch-Block eine Error-Nachricht ins Debuglog geschrieben wird, habe ich das Ganze mit dem Android Device Monitor mal überprüft und siehe da, es wird keine Error-Nachricht geschrieben, was bedeutet, dass die erste Option jene ist, die bei mir eintritt:

Code:

if (mService == null || mClientIf == 0) return false;

Jetzt bin ich gerade dabei, mühsam zu überprüfen, warum das auftritt. In jedem Fall habe ich dann aber auch eine umfangreiche Informationskette für ein etwaiges Support-Ticket.
Sollte jemandem basierend auf diesen Informationen ein Geistesblitz kommen, wäre ich aber auch dafür natürlich sehr dankbar.

[Peter Baudisch]

Hallo zusammen,

ich auch dieses Problem, DiscoverServices() liefert nach gewisser Zeit "false" zurück.

Meine Applikation ist so, dass ich das BLE Modul immer wieder trenne um mich dann neu zu verbinden,
aus Sicherheitgründen, wenn von meinem BLE keine Daten mehr kommen.

Unter IOS liefert DiscoverServices()sofort nach dem Start hin und wieder mal false. Ich rufe es dann erneut aus, und dann klappt alles wieder.

Unter Android (getestet 6.0 oder 7.1) tritt der Fehler nach etlichen Verbindungs-Neustarts auf, und bleibt dann kontinuierlich bis zum Neustart der App. Die hier beschriebene Maßnahme mit Enable false-true nutzt da nichts.
Auch Verzögerungszeiten ergaben keine Lösung.

@AuronTLG: Hast Du Dein Problem vom 23.01.2020 mittlerweile gelöst ?

Besten Dank
Peter