TBluetoothLE: DiscoverServices() erkennt unter Android manchmal keine Services

[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