![]() |
Warum Android-Berechtigungen direkt setzen?
Ich habe mal eine Frage zu „Berechtigungen“ in FMX-Android:
Ich habe eine App mit Delphi 10.4 geschrieben, die sowohl Berechtigungen für „Dateien und Medien“ und „Kamera“ benötigt. Eigentlich bräuchte ich mich dabei um die Berechtigungsverwaltung gar nicht kümmern, da in Delphi bereits entsprechende Berechtigungen voreingestellt sind. In meiner unendlichen Naivität bin ich davon ausgegangen, dass meine App diese Berechtigungen in Android setzt. Pustekuchen. Wenn meine App das erstemal startet, hängt sie, weil die Berechtigungen in Android NICHT !! gesetzt wurden. Erst, wenn ich manuell in den Android-Einstellungen diese Berechtigungen setze, läuft es. Nun frage ich mich, wofür die Berechtigungsverwaltung in Delphi da ist, wenn ich dann doch alles manuell durchführen muss. Viele Apps aus dem Google-Store machen das aber – da muss ich nichts manuell setzen. Was können die, was ich nicht kann? Habe ich irgendwas vergessen/übersehen? |
AW: Warum Android-Berechtigungen direkt setzen?
Rufst du die Berechtigungen denn beim Start ab? In aktuellen Android Versionen muss man diese explizit anfragen, wenn sie benötigt werden. Früher wurden diese bei der Installation abgefragt, was heute nicht mehr passiert.
Ich habe das per IFDEF meistens so gemacht, dass es unter Windows und Android identisch funktioniert, nur dass unter Android die Berechtigungen abgefragt werden. Sprich als Pseudocode:
Delphi-Quellcode:
Auf die Weise werden unter Android die Rechte angefordert und die weitere Initialisierung im Callback RequestPermissionsResult ausgeführt, während unter Windows die Initialisierung direkt im FormActivate passiert.
procedure TXXX.FormActivate...
begin if FAlreadyActivated then Exit; FAlreadyActivated := True; {$IFDEF ANDROID} PermissionsService.RequestPermissions... end; procedure TXXX.RequestPermissionsResult... begin StatusLabel.Text := 'Überprüfe Rechte...'; if (Length(AGrantResults) = 1) and (AGrantResults[0] = TPermissionStatus.Granted) then begin StatusLabel.Text := 'Lade App...'; {$ENDIF} TThread.CreateAnonymousThread... end; |
AW: Warum Android-Berechtigungen direkt setzen?
Nee, Berechtigungen habe ich beim Start nicht abgerufen. Dieses Thema ist neu für mich, aber ich habe weiter recherchiert und gesehen, dass es unter Examples/Object Pascal/Mobile Snippets/Location entsprechenden Beispielcode gibt. Damit werde ich mich erstmal auseinander setzen. Falls ich dann noch Fragen habe, melde ich mich wieder. Vorerst vielen Dank für den Tipp.
|
AW: Warum Android-Berechtigungen direkt setzen?
Die Idee dahinter ist, dass nicht jede App alle ihre Berechtigungen in jedem Fall immer braucht,
sondern manche nur, wenn bestimmte Aktionen ausgeführt werden sollen. Damit kann ein Anwender der diese Funktionen nicht benutzt diese Rechte auch problemlos in den Einstellungen entfernen. |
AW: Warum Android-Berechtigungen direkt setzen?
Ich habe jetzt etwas mit den Permissions herumexperimentiert und herausgefunden, dass die Auflistung der Berechtigungen in Delphi (Haken gesetzt) in „AndroidManifest.xml“ erscheint.
Z.B.: <uses-permission android:name="android.permission.CAMERA" /> Android 13 bietet folgende Berechtigungsliste an: -Anrufliste -Benachrichtigungen -Dateien und Medien -Fotos und Videos -Geräte in der Nähe -Kalender -Kamera -Kontakte -Körperliche Aktivität -Körpersensoren -Mikrofon -Musik und Audio -SMS -Standort -Telefon -Zusätzliche Berechtigungen Was mir jetzt fehlt, ist der Ausdruck für „Dateien und Medien“. Alo sowas ähnliches wie <uses-permission android:name="android.permission.DATEIN_UND_MEDIEN " /> Eine Entsprechung finde ich in der Delphi-Liste leider nicht. Hier ein Auszug dessen, was ich schon alles probiert habe:
Delphi-Quellcode:
Ich bin nach wie vor auf der Suche nach dem Permission-Begriff für "Dateien und Medien". Hat jemand eine Idee?
procedure TForm1.FormActivate(Sender: TObject);
const camera = 'android.permission.CAMERA'; internet = 'android.permission.INTERNET'; read_Calender = 'android.permission.READ_CALENDAR'; Write_Calender = 'android.permission.WRITE_CALENDAR'; READ_EXTERNAL_STORAGE = 'android.permission.READ_EXTERNAL_STORAGE'; WRITE_EXTERNAL_STORAGE = 'android.permission.WRITE_EXTERNAL_STORAGE'; // ... ich habe noch eine Menge mehr versucht, leider war nichts dabei begin {$IFDEF ANDROID} PermissionsService.RequestPermissions([camera, internet, read_Calender, Write_Calender, READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE], procedure(const APermissions: TArray<string>; const AGrantResults: TArray<TPermissionStatus>) begin // vlt. etwas umständlich, ist ja auch nur 'n Versuch if (Length(AGrantResults) = 6) and (AGrantResults[0] = TPermissionStatus.Granted) and (AGrantResults[1] = TPermissionStatus.Granted) and (AGrantResults[2] = TPermissionStatus.Granted) and (AGrantResults[3] = TPermissionStatus.Granted) and (AGrantResults[4] = TPermissionStatus.Granted) and (AGrantResults[5] = TPermissionStatus.Granted) then // StatusLabel.Text := 'Lade App...'; else begin // StatusLabel.Text := 'keine Berechtigung...'; TDialogService.ShowMessage('permission not granted'); end; end); {$ENDIF} end; |
AW: Warum Android-Berechtigungen direkt setzen?
Das war früher READ_EXTERNAL_STORAGE bzw. WRITE_EXTERNAL_STORAGE. Ab SDK-Version 30 heißt das MANAGE_EXTERNAL_STORAGE. Hintergrund ist, dass man den Typ des Speicherzugriffs (Medien, ...) angeben soll statt einfach den Storage-Zugriff allgemein anzufordern. Wenn du das also nicht brauchst, wäre es besser, dir nur den Zugriff auf die einzelnen Dateikategorien zu holen.
Die komplette Liste findest du in der Dokumentation: ![]() Und hier eine Dokumentation zum Speicherzugriff: ![]() Zitat:
Wenn du das IFDEF um alles setzt, solltest du aufpassen, dass du keinen doppelten Quelltext schreibst, falls du auch für Windows kompilierst. Wenn das eine reine Android App ist oder die App beim Laden nichts weiter macht, ist das natürlich egal. |
AW: Warum Android-Berechtigungen direkt setzen?
Willkommen im Club, das Permissions-System ist mein täglicher Sargnagel, deshalb vermeide ich Dangerous Permissions wo es eben nur geht (geht aber nicht immer ).
Fehlende Runtime Permissions kann man in der AndroidManifest.template.xml eintragen. Da wird seitens Android ständig dran geändert und alte/neue Betriebssystemversionen kompatibel zu halten ist alles andere als trivial. ![]() Mit dem einfachen Eintragen der Permissions ist es aber oft nicht getan und man muss Lösungen drumherum suchen. ![]() |
AW: Warum Android-Berechtigungen direkt setzen?
Jetzt hab ich die Lösung:
Ich hab nämlich verschwiegen, dass ich auch eine Firedac-Komponente benutze mit 'nem sqlite-Driver, die die Datei-Berechtigung anfordert. Das Setzen der Berechtigung "READ_EXTERNAL_STORAGE" und "WRITE_EXTERNAL_STORAGE" kam in onFormActivate() zu spät. Ich habe sie jetzt in onbeforConnect der FDConnection gesetzt. Dort auch gleich die Berechtigungen für Camera und Calendar. Und siehe da: alles paletti! Jetzt bin ich restlos zufrieden. |
AW: Warum Android-Berechtigungen direkt setzen?
Zitat:
|
AW: Warum Android-Berechtigungen direkt setzen?
Ich häng hier mal eine Frage an:
READ_EXTERNAL_STORAGE bzw. WRITE_EXTERNAL_STORAGE, hier geht es um EXTERNAL, wie verhält es sich bei z.B. einem S21 Ultra, welches gar keine SD-Karte unterstützt und quasi nur internen Speicher hat? Ciao Stefan |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:53 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz