Höchst unschöne Änderung bei der Storage-Permission!

[Tuxgamer12]

[developer.android.com]

Ernsthaft - WRITE_EXTERNAL_STORAGE gibt einem nicht mehr die Permission auf dem internen Speicher. Sondern jediglich auf Photo, Video und Audio collection!

Für sämtliche andere Dateizugriffe (außerhalb des privaten Ordners) ist man gezwungen Storage Access Framework zu nutzen - wieso das schlecht ist, siehe Kommentar auf xda-developers.

Natürlich betrifft die Änderung zur Zeit keine alten Apps - aber das ist auch nur eine Frage der Zeit. Und ja: In diesem Bereich hat Android Nachholbedarf; hätte mir z.B. (zusätzliche!) Permission "(READ/WRITE)_(PHOTO/VIDEO/AUDIO)" gewünscht - weil der Musik-Player keinen Zugriff auf meine Bilder braucht.

Aber in dieser Form, finde diese Änderung einfach nicht gut. Brauche ich dann in Zukunft selbst für einen brauchbaren File Manager zwingend root?

[bofhl]

Du scheinst da was komplett falsch verstanden zu haben ;-))
Du sollst laut Google einfach keinen File Manager für den wahlfreien Zugriff auf die Dateien benutzen! Da das ja für Google an deren Scan- und Track-Möglichkeiten vorbei geht, darf man das nun eben nicht mehr. D.h. jede Datei muss durch Googles Überwachungs-System geschleust werden um auch ja alles korrekt für deren Werbesystem zuordnen zu können.

Wie schön waren da die alten Android-Versionen, wo man noch wirklich das tun konnte, was man auch wirklich programmtechnisch tun wollte...

[blackbirdone]

Was auch Nachteile hat. Z.B dir massenhaft Daten auszuleiten. Es hat schon Sinn das einzuschränken, aber die Performance ist schrecklich. Da wurde sich absolut keine Mühe gegeben und das nachgeplapper von Google nutzt das für Werbezwecke macht es nicht wahrer nur weil man es wiederholt.

[Thaodan]

Tuxgamer12 schrieb:
--------------------------------------------------------------------------------
> developer.android.com
> Für sämtliche andere Dateizugriffe (außerhalb des privaten Ordners) ist man
> gezwungen Storage Access Framework zu nutzen - wieso das schlecht ist,
> siehe Kommentar auf xda-developers.
>
> Natürlich betrifft die Änderung zur Zeit keine alten Apps - aber das ist
> auch nur eine Frage der Zeit. Und ja: In diesem Bereich hat Android
> Nachholbedarf; hätte mir z.B. (zusätzliche!) Permission
> "(READ/WRITE)_(PHOTO/VIDEO/AUDIO)" gewünscht - weil der Musik-Player keinen
> Zugriff auf meine Bilder braucht.
Doch für Alben-Cover zb.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[Thaodan]

Da man will das SAF genutzt wird statt dessenn, für solche Fälle wird das Ziel was du sagst nicht erreicht. Ganz im Gegenteil es wird langsamer.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[redmord]

Liest so als hätte man sich eher auf ein Dateisystem mit access control list usw. konzentrieren sollen...

Was für ein Dateisystem nutzt Android überhaupt?



1 mal bearbeitet, zuletzt am 04.09.19 11:20 durch redmord.

[Thaodan]

Je nach Vendor. Aber ACL unterstützt fast jedes Dateisystem abgesehen von VFAT.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[Tuxgamer12]

Thaodan schrieb:
--------------------------------------------------------------------------------
> > hätte mir z.B. (zusätzliche!) Permission
> > "(READ/WRITE)_(PHOTO/VIDEO/AUDIO)" gewünscht - weil der Musik-Player
> keinen
> > Zugriff auf meine Bilder braucht.
> Doch für Alben-Cover zb.

Kannst dir Alben-Cover doch auch über MediaStore.Audio ausgeben - also die Unterscheidung "Bild gehört als Alben-Cover zu Musik" oder "Bild ist Bild" wäre nun nicht das Problem...

[Thaodan]

Also auch welche nur als Bild vorhanden sind?

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[logged_in]

Na super, so ein Scheiß!

Hab's gerade mal ausprobiert, und es ist echt zum kotzen. Darf jetzt 6 Apps an zig Stellen umschreiben, obwohl sie immer ganz brav in das von ihnen angeforderte Verzeichnis schrieben

```
<provider
android:name="androidx.core.content.FileProvider"
android:authorities="de.blablabla.files"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/my_paths" />
</provider>
```

```
<?xml version="1.0" encoding="utf-8"?>
<paths>
<external-path name="files" path="blablabla/" />
</paths>
```

Die machen mit Scoped Storage also genau das, was ich von iOS verabscheut habe, was mich meinen ließ, dass man dort wie im Kindergarten oder wie in der Irrenanstalt mit einer Zwangsjacke leben würde.

FML



2 mal bearbeitet, zuletzt am 04.09.19 12:59 durch logged_in.

[bofhl]

blackbirdone schrieb:
--------------------------------------------------------------------------------
> Was auch Nachteile hat. Z.B dir massenhaft Daten auszuleiten. Es hat schon

Das bitte soll zuerst mal jemand genauer beweisen, dass dem so war! Welche Apps machen das genau? Google sagt nur, dass das so ist. Und wenn, warum hat man dann nicht besser einschränkbares Security-Setting geschaffen? Ups, und warum genau ist es Google-System-Apps erlaubt all das zu umgehen?

> Sinn das einzuschränken, aber die Performance ist schrecklich. Da wurde

Die Perfomance ist eine schlichte Katastrophe!

> sich absolut keine Mühe gegeben und das nachgeplapper von Google nutzt das
> für Werbezwecke macht es nicht wahrer nur weil man es wiederholt.

Na, dann geh mal her und sieh dir mal das nette Google Framework das mit dem Media Framework verknüpft ist genauer an (hängt sich schneller als man Ups sagen kann hinein)! Wozu bitte muss Google jede einzelne Datei durchsuchen wenn diese über dieses Schwachsinns-Framework geladen wird? Warum wird von jeder einzelnen Datei ein Hashwert errechnet und netterweise über das Track-API sowohl anderen Apps als auch ins Google-Servernetz (genauer Google-Analytics-Netwerk) hochgeladen?

[Truster]

Wie sieht es hier eigentlich bei AOSP aus? Ich denke jetzt da mal an Lineage & Co.

[Thaodan]

Es geht doch gerade um AOSP. AOSP ist upstream für alle Hersteller.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm