Android permissions mit Bluetooth LE und Location werden nicht direkt freigeschaltet

[Hofix2004]

... bin gerade selbst darauf gekommen, statt ACCESS_COARSE_LOCATION bracht es jetzt ACCESS_FINE_LOCATION

[philipp.hofmann]

Also ich habe jetzt auch mal intensiv getestet und grundsätzlich funktioniert bei mir sowohl Delphi 10.3.3 als auch 10.4 (Patch 3) mit BLE und zwar sowohl mit Android-9 als auch Android-10.
Nur manchmal funktioniert bei mir
res:=bleManager.ble.SubscribeToCharacteristic(bleD eviceClassic,FMeasurementGattCharact);
nicht. Da bin ich noch am suchen, was dies auslösen kann.

[Rollo62]

Zitat von philipp.hofmann:

Also ich habe jetzt auch mal intensiv getestet und grundsätzlich funktioniert bei mir sowohl Delphi 10.3.3 als auch 10.4 (Patch 3) mit BLE und zwar sowohl mit Android-9 als auch Android-10.

Hattest Du mal mein Demo-Projekt geladen, mit dem aktuellen Android 29 SDK ?
https://en.delphipraxis.net/applicat...nt.php?id=2542

Müsste einfach nur in Rx10.4 geladen und gestartet werden.
Beim ersten Scan wird die Permissions's Abfrage gemacht, aber BLE startet nicht.
Erst wenn die Permissions zu der App in den Settings einmal hin und hergeändert wurde.

Sollte zumindest bei Dir genauso sein, denn ich habe hier auch ein clean installiertes Rx10.4.
Und auch das Android SDK ist 1:1 frisch installiert.

Falls es doch beim ersten Mal scannt, ohne das man in den Android Settings hin- und hersetzen muss,
würde mich das sehr wundern.
Was wäre dann anders in deiner Konfiguration als hier ?
Was jetzt an API-29 hakt weiss ich immer noch nicht, das werde ich nächste Woche weiter untersuchen.

[philipp.hofmann]

Hi Rollo,

jetzt läuft das Demo-Projekt auch bei mir. Ich habe drei Anpassungen vorgenommen:

a) In allen Manifest-Templates die ACCESS_BACKGROUND_LOCATION aufgenommen:

Code:

    <uses-sdk android:minSdkVersion="%minSdkVersion%" android:targetSdkVersion="%targetSdkVersion%" />
    <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
    <%uses-permission%>

b) ACCESS_FINE_LOCATION aufgenommen (war unter Delphi 10.3.3 noch nicht notwendig, ab Delphi 10.4 aber scheinbar schon)

Delphi-Quellcode:

procedure TForm1.Request_LC;
var
    LPermission_LC: String;
    LPermission_LF: String;
    LPermission_LB: String;

begin

    // Location Permissions
    LPermission_LC := JStringToString( TJManifest_permission.JavaClass.ACCESS_COARSE_LOCATION );
    LPermission_LF := JStringToString( TJManifest_permission.JavaClass.ACCESS_FINE_LOCATION );
    LPermission_LB := CPermission_AccessBackgroundLocation;

    if CheckBox1.IsChecked then
    begin
        Memo1.Lines.Insert( 0, 'Request LOCATION permission WITH BG ...' );

        PermissionsService.RequestPermissions(
              [   LPermission_LC
                , LPermission_LF
                , LPermission_LB ]
            , EvOnRequestPermissionsResult_LC
            , nil // DisplayRationale
            );
    end
    else
    begin
        Memo1.Lines.Insert( 0, 'Request LOCATION permission FG only ...' );

        PermissionsService.RequestPermissions(
              [   LPermission_LC, LPermission_LF ]
            , EvOnRequestPermissionsResult_LC
            , nil // DisplayRationale
            );
    end;


end;

c) Die Permission-Result-Methode dementsprechend angepasst:

Delphi-Quellcode:

procedure TForm1.EvOnRequestPermissionsResult_LC(       Sender       : TObject;
                                                  const APermissions : TArray<string>;
                                                  const AGrantResults: TArray<TPermissionStatus>);
var i:integer;
begin


    if CheckBox1.IsChecked then
    begin

        if Length(AGrantResults) >= 3 then
        begin
            if (AGrantResults[0] = TPermissionStatus.Granted ) and
               (AGrantResults[1] = TPermissionStatus.Granted ) and
               (AGrantResults[2] = TPermissionStatus.Granted ) then
            begin
                 Memo1.Lines.Insert( 0, 'Permission LOCATION w/ BG granted' );

                 FRequestSequence := 1;
            end
            else
            begin
                for i:=Length(AGrantResults)-1 downto 0 do
                begin
                  if (AGrantResults[i] = TPermissionStatus.Granted) then
                    Memo1.Lines.Insert( 0, IntToStr(i)+ ': Permission granted' )
                  else
                    Memo1.Lines.Insert( 0, IntToStr(i)+ ': Permission not granted' );
                end;
                Memo1.Lines.Insert( 0, 'Permission LOCATION w/ BG not fully granted' );
                FRequestSequence := 0;
            end;
        end
        else
        begin
             Memo1.Lines.Insert( 0, 'Permission LOCATION w/ BG error' );

             FRequestSequence := 0;
        end;


    end
    else
    begin

        if Length(AGrantResults) >= 2 then
        begin
            if (AGrantResults[0] = TPermissionStatus.Granted ) and
               (AGrantResults[1] = TPermissionStatus.Granted ) then
            begin
                 Memo1.Lines.Insert( 0, 'Permission LOCATION FG granted' );

                 FRequestSequence := 1;
            end
            else
            begin
                for i:=Length(AGrantResults)-1 downto 0 do
                begin
                  if (AGrantResults[i] = TPermissionStatus.Granted) then
                    Memo1.Lines.Insert( 0, IntToStr(i)+ ': Permission granted' )
                  else
                    Memo1.Lines.Insert( 0, IntToStr(i)+ ': Permission not granted' );
                end;
                Memo1.Lines.Insert( 0, 'Permission LOCATION FG not fully granted' );
                FRequestSequence := 0;
            end;
        end
        else
        begin
             Memo1.Lines.Insert( 0, 'Permission LOCATION FG error' );

             FRequestSequence := 0;
        end;


    end;

end;

Je nach Android-Version bekommt man in der Permission-Result-Methode jetzt auch ein "Not fully granted" zurück und muss dann z.B. intern wissen, dass für Android 5.x nur die erste von hier dreien Permission erlaubt sein muss.

Damit ging der Scan (reicht dir das als Result?) auf einem Android-9 und einem Android-10-Device.

Grüße, Philipp

[Rollo62]

Dankesehr fürs Testen.


a) In allen Manifest-Templates die ACCESS_BACKGROUND_LOCATION aufgenommen:
--> Dafür hatte ich ja zwei Versionen Rx1033/Rx1040 im Projekt drin, ich hatte extra zwei Projekte angelegt (10.3.3, 10.4), mit unterschiedlichen Setups.
--> In Rx10.3.3 sollte das ACCESS_BACKGROUND_LOCATION nicht nötig sein ( ging bisher auch ohne).

b) ACCESS_FINE_LOCATION aufgenommen (war unter Delphi 10.3.3 noch nicht notwendig, ab Delphi 10.4 aber scheinbar schon)
--> Seltsam, ich hatte bisher sowieso immer beide Coarse/Fine Permissions gesetzt.
Wenn das gefehlt hätte wäre das peinlich, ich schau nochmmal nach.
Ich hatte soviel hin- und hergeändert, vielleicht liegt es einfach nur daran.
Deshalb fände ich ein mehr textbasiertes Optionen-Setup besser, dann kann man besser vergleichen.



c) Die Permission-Result-Methode dementsprechend angepasst:
Je nach Android-Version bekommt man in der Permission-Result-Methode jetzt auch ein "Not fully granted" zurück und muss dann z.B. intern wissen, dass für Android 5.x nur die erste von hier dreien Permission erlaubt sein muss.
--> Klar, da hatte ich auch zwei Versionen gemacht.


Sehr seltsam.
Ich werde mir die ganzen Settings nochmal ansehen, vielleicht war es wirklich nur ein Typo.
Das war aber schon die 7. Version, deshalb bin ich mir eigentlich sicher das es OK war.

Könntest Du mir bitte die Version, welche bei Dir unter Rx10.4 läuft nochmal zurückschicken ?
Damit ich das hier direkt 1:1 Tresten kann.

[philipp.hofmann]

Bitte schön.

[philipp.hofmann]

Die Version läuft so übrigens auch mit Delphi 10.3.3. Das man zwei Permissions erfragt, die man dort noch nicht "braucht" tut nicht weh. Wie gesagt, diese werden nur je nach Android-OS-Version nicht bestätigt, was aber die Funktionalität nicht einschränkt. Dies muss einem bei der Ausgabe, wenn man etwas "not granted" war, nur klar sein, denn auch dort kommen dann drei Permissions zurück und die "unbekannten" sind einfach nicht bestätigt.

[Rollo62]

Dankesehr für die Unterstützung Phillip,

Ich glaube ich habe das Problem gefunden ( das war wohl meiner Einer ).

Ich habe früher immer beide Permissions COARSE und FINE gesetzt, um Bluetooth zu aktivieren.
Jetzt wollte ich mal optimieren und bin ziemlich felsenfest davon ausgegangen das BLE mit COARSE reicht.

Woher ich diese fixe Idee hatte kann ich gar nicht mehr nachvollziehen (ich könnte schwören aus den Android Specs.),
jedenfalls sagt die Android-Doku was Anderes aus:

Zitat:

The other permission that you must declare is ACCESS_FINE_LOCATION. Your app needs this permission because a Bluetooth scan can be used to gather information about the location of the user. This information may come from the user's own devices, as well as Bluetooth beacons in use at locations such as shops and transit facilities.

Also sollte nur FINE reichen, .... Puuuh

Naja, ich ändere es jetzt so bei mir ab das auch COARSE oder FINE akzeptiert wird,
aber FINE auf jeden Fall immer da sein muss.

Irgendwie waren da wohl zu viele Bäume und zu wenig Wald

P.S.: Was mich wieder mal bestärkt in Regel 1: "neven change a running system"

Ich habe jetzt die letzen Updates im PlayStore unter Rx10.3.3 soweit erledigt.
Jetzt wollte ich mich dem Problem unten widmen, scheint dann aber schon gelöst dank der Erkenntnisse hier,
und ich kann mit gutem Gewissen auf Rx10.4 wechseln.
Das es ansonsten unter 10.4 läuft hatte ich schon getestet, dann wird nächste Woche Einiges an Updates auf mich zukommen.

[philipp.hofmann]

Meine Erfahrung sagt auch, dass bisher FINE nicht notwendig war und auch ich hatte da optimiert und dies nun geändert. Mein Problem mit dem Subscribe habe ich auch lösen können. Android mage es nicht, wenn noch ein ReadCharacteristic läuft und man parallel ein Subscribe abschickt. Normalerweise kein Problem. In einem Fall nutze ich aber zwei Services von dem gleichen BLE-Device und beim zweiten Service braucht ich das Subscribe, beim ersten hatte ich nur ein paar Daten abgefragt. Da muss der erste Service zuerst inklusive der ReadCharacteristic-Antworten (welche ja asynchron kommen) abgearbeitet sein, bevor ich mit dem zweiten beginnen darf.

[Rollo62]

Damit meinst Du wohl wenn eine Verbindung getrent wird / werden soll, oder gelöscht werden soll.
Das Verbinden geht meist einfach und direkt, aber wenn ein Gerät wegfällt oder disconnected wird ...
Das kann dann extrem tricky werden wenn da noch Kommandos irgendwo hängen,
ich denke man muss auch einfach warten bis die Phones Ressourcen freigeben und einem wieder den Zugriff erlauben.

Um das zu Beschleunigen habe ich schon alles Mögliche versucht (fällt bei mir unter Stichwort Kill BLE), und auch gewisse Timings zwischen Befehlen sind dabei einzuhalten.

Ich arbeite auch noch ein einem neuen, großen Update meiner Libraries, die 6. BLE Version jetzt,
aber da komme ich erst zu wenn ich noch 1000 Dinge vorher erledigt habe.

Solange es stabil läuft, besser Finger davon lassen, sonst passiert am Ende das siehe unten