Le modifiche allo storage con ambito in Android Q sono un grattacapo da affrontare, perché lo Storage Access Framework presenta alcuni difetti in questo momento.
Android Q sta cambiando radicalmente il modo in cui funziona l'archiviazione sul tuo telefono. In ogni versione fino a Pie, lo spazio di archiviazione di Android funzionava come un computer desktop: puoi utilizzare qualsiasi app desideri per leggere o scrivere qualsiasi file (se concedi a un'app l'autorizzazione per farlo). Con Q, Google introduce (e richiede) "Archiviazione con ambito," che rende Android più simile a un iPhone, dove lo spazio di archiviazione è isolato per ciascuna app. Un'app può accedere solo ai propri file e, se viene disinstallata, tutti i suoi file vengono eliminati.
Per fortuna Android Q conserva ancora parte del comportamento originale di Android di un filesystem centrale. Sfortunatamente, ora è complicato per l'utente configurare le app per accedervi e le prestazioni e le capacità sono significativamente ridotte. E gli sviluppatori dovranno ricodificare sostanzialmente le app per supportarlo.
App che necessitano di accesso generale al filesystem, ad es. una suite per ufficio, un editor di immagini o un file manager, ora dovrà utilizzare un'API Android chiamata "Quadro di accesso all'archiviazione" (SAF), per tutte le operazioni sui file. SAF è disponibile a partire da Android 5.0 Lollipop, ma gli sviluppatori tendono a non usarlo se non richiesto, poiché ha un funzionamento difficile e poco efficace. API documentata, esperienza utente scadente, prestazioni scadenti e scarsa affidabilità (in gran parte sotto forma di implementazione specifica del fornitore del dispositivo problemi). A causa della difficoltà nel passaggio a SAF, Google ha deciso di consentire le app che non lo indicano ancora Il supporto di Android Q funzionerà come prima, ma ciò cambierà quando il Play Store richiederà che tutte le app supportino Q l'anno prossimo.
Il cambiamento più evidente per l'utente con SAF è l'esperienza di concedere a un'app l'accesso allo spazio di archiviazione. Per ottenere l'accesso, un'app effettua una richiesta al sistema operativo, che quindi visualizza una schermata di selezione della directory. In questa schermata l'utente seleziona la radice di una gerarchia di cartelle in cui l'app sarà in grado di leggere e scrivere file. L'utente deve eseguire questo processo per ciascuna app che richiede l'accesso ai file locali o due volte per app se deve concederle anche l'accesso a una scheda SD esterna.
Google ha almeno migliorato questo processo per Qbeta3, poiché le versioni beta precedenti non consentivano a un'app nemmeno di suggerire all'utente una posizione da selezionare, quale richiedeva all'utente di fare un bel po' di lavoro per trovare effettivamente la memoria principale del proprio dispositivo.
Le prestazioni di I/O sui file subiscono un certo calo in SAF, ma il problema più evidente risiede nel file operazioni di directory, dove è da circa 25 a 50 volte più lento dell'accesso ai file convenzionale possibile in Torta. Nel caso dei file manager, ciò significa che occorrerà molto più tempo per eseguire ricerche e calcoli sull'utilizzo dello spazio di archiviazione. Una segnalazione di bug con un'app dimostrativa è disponibile qui.
Un problema di prestazioni ancora maggiore è che alcune app dovranno copiare i file nella loro area di "archiviazione con ambito" locale prima di poter lavorare con essi. Ciò può essere problematico quando tali file hanno dimensioni multiple di gigabyte, ad es. nel caso di file video o archivi compressi. Molte app Android sfruttano l'incredibile numero di librerie Java open source nella comunità degli sviluppatori e queste librerie richiedono comunemente l'accesso diretto al filesystem per funzionare. Non sono specifici per Android e richiederebbero una riscrittura per funzionare con SAF. Ancora peggio, molte delle librerie interne di Android non funzioneranno con esso, come il gestore pacchetti o l'API zip. Ad esempio, un file manager non sarà nemmeno in grado di visualizzare l'icona di un file APK (utilizzando l'API Android standard) senza prima copiare l'intero APK nella propria area di archiviazione. Riportare un errore.
Per le persone tecnicamente inclini, è attualmente possibile disabilitare lo "Scoped Storage" di Android Q per app tramite ADB utilizzando un comando appops. Gli utenti root possono eseguire i comandi direttamente sul proprio dispositivo senza un computer desktop. Tali comandi sono descritti nella documentazione come funzionalità per sviluppatori e pertanto possono essere rimossi in qualsiasi momento.
Abilita l'accesso generale allo spazio di archiviazione per un'app:
adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-nameDisattiva l'accesso generale allo spazio di archiviazione per un'app:
adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-nameGoogle pubblicizza i vantaggi in termini di sicurezza e privacy di questo cambiamento, ma tecnicamente parlando non vi è alcun miglioramento. Le app hanno la possibilità di archiviare file privatamente a partire da Android 1.0 e quasi tutte le app utilizzano questa funzionalità. Quando concedi a un'app l'accesso alla directory root del tuo spazio di archiviazione tramite SAF, può leggere, scrivere e inviare qualsiasi file vuole il suo malvagio sviluppatore esattamente nello stesso modo in cui lo farebbe quando concedessi a un'app l'accesso allo spazio di archiviazione in Pie.
L'unico "miglioramento della sicurezza" avviene perché ora è un processo più arduo per un utente farlo. A meno che, ovviamente, un'app non voglia solo rubare le tue informazioni più personali, come foto e video che hai preso, per il quale Google ha aggiunto una soluzione di accesso alternativa che utilizza un semplice pop-up di sicurezza clicca-sì dialogo.
Non è noto quali vantaggi Google spera di ottenere con questo cambiamento. Il motivo ufficiale dichiarato nella documentazione beta di Android Q è quello di "dare agli utenti un maggiore controllo sui propri file e limitare i file ingombrare." L'archiviazione con ambito, nella sua forma attuale, è una nuova limitazione di ciò che l'utente può fare, non un'estensione delle stesse controllo. L'affermazione di ridurre il disordine può essere in qualche modo valida, ma solo perché la modifica riduce del tutto la possibilità di utilizzare i file. E il “disordine” aumenta se si considera il problema di alcune app che ora devono duplicare i file per funzionare con loro.
Se Google fosse veramente interessato a dare agli utenti un maggiore controllo sui file e sul disordine, dovrebbe progettare a soluzione che affronta direttamente questo problema, piuttosto che marchiare falsamente l'attuale design di Android Q come tale miglioramento. La risposta più semplice sarebbe lasciare che gli utenti decidano se desiderano che un'app abbia accesso generale o con ambito al filesystem, utilizzando la finestra di dialogo di richiesta di autorizzazione di archiviazione esistente. Se qui c’è una preoccupazione particolare per gli utenti che prendono decisioni sbagliate, è certamente possibile farlo rendere la finestra di dialogo più evidente e richiedere un'ulteriore interazione da parte dell'utente per approvare completamente un'app accesso.
La risposta a come Android può offrire agli utenti un maggiore controllo sui propri file è dare effettivamente agli utenti maggiore controllo, non toglierlo e limitare fondamentalmente le capacità della piattaforma Android.
Nota del redattore: questo è un articolo ospite scritto dal membro senior di XDA Tliebeck, meglio conosciuto per il suo lavoro su Esplora file FX. I contenuti di questo articolo riflettono la sua opinione e analisi delle restrizioni di archiviazione con ambito di Android Q, con input e modifiche minime da parte di Mishaal Rahman, redattore capo di XDA-Developers. Abbiamo contattato Google per chiedere loro alcune di queste preoccupazioni, ma non abbiamo ricevuto risposta dall'azienda al momento della pubblicazione.