Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Conservazione

Icona HAL di archiviazione esterna Android

Android si è evoluto nel tempo per supportare un'ampia varietà di tipi e funzionalità di dispositivi di archiviazione. Tutte le versioni di Android supportano dispositivi con archiviazione tradizionale , che include archiviazione portatile ed emulata. L' archiviazione portatile può essere fornita da un supporto fisico, come una scheda SD o USB, ovvero per il trasferimento temporaneo di dati / archiviazione di file. Il supporto fisico può rimanere con il dispositivo per un periodo di tempo prolungato, ma non è collegato al dispositivo e può essere rimosso. Le schede SD sono disponibili come memoria portatile da Android 1.0; Android 6.0 ha aggiunto il supporto USB. L' archiviazione emulata viene fornita esponendo una parte della memoria interna attraverso un livello di emulazione ed è disponibile da Android 3.0.

A partire da Android 6.0, Android supporta l' archiviazione adottabile , fornita da un supporto fisico, come una scheda SD o USB, crittografata e formattata per comportarsi come una memoria interna. L'archiviazione adattabile può memorizzare tutti i tipi di dati dell'applicazione.

Autorizzazioni

L'accesso alla memoria esterna è protetto da varie autorizzazioni Android. A partire da Android 1.0, l'accesso in scrittura è protetto con l'autorizzazione WRITE_EXTERNAL_STORAGE . A partire da Android 4.1, l'accesso in lettura è protetto con l'autorizzazione READ_EXTERNAL_STORAGE .

A partire da Android 4.4, il proprietario, il gruppo e le modalità dei file sui dispositivi di archiviazione esterni sono ora sintetizzati in base alla struttura delle directory. Ciò consente alle app di gestire le directory specifiche del pacchetto sulla memoria esterna senza richiedere che dispongano dell'ampia autorizzazione WRITE_EXTERNAL_STORAGE . Ad esempio, l'app con il nome del pacchetto com.example.foo può ora accedere liberamente ad Android/data/com.example.foo/ su dispositivi di archiviazione esterni senza autorizzazioni. Queste autorizzazioni sintetizzate vengono ottenute avvolgendo i dispositivi di archiviazione non elaborati in un daemon FUSE.

A partire da Android 10, le app che hanno come target Android 9 e versioni inferiori sono predefinite per l'archiviazione legacy e possono optare per l'archiviazione isolata. Le app che prendono di mira Android 10 e impostano l'archiviazione isolata per impostazione predefinita possono disattivarlo temporaneamente . Utilizzare l'attributo manifest requestLegacyExternalStorage , che controlla il modello di archiviazione, per modificare lo stato predefinito.

Poiché entrambe le autorizzazioni READ_EXTERNAL_STORAGE e WRITE_EXTERNAL_STORAGE sono soggette a restrizioni soft, se il programma di installazione non ha autorizzato l'app, l'autorizzazione controlla l'accesso solo alle raccolte acustiche e visive, senza accesso alla scheda SD. Questo vale anche se l'app richiede l'archiviazione legacy. Per ulteriori informazioni sulle restrizioni rigide e flessibili, vedere Restrizioni rigide e flessibili in Android 10 .

Se il programma di installazione ha autorizzato l'autorizzazione, un'app in esecuzione in modalità legacy ottiene il comportamento dell'autorizzazione non isolata. L'autorizzazione controlla l'accesso alla scheda SD e le raccolte acustiche e visive. Ciò accade quando l'app è indirizzata ad Android 9 o versioni precedenti e non attiva l'archiviazione isolata oppure è indirizzata ad Android 10 e disattiva.

Lo stato della whitelist può essere specificato solo al momento dell'installazione e non può essere modificato finché l'app non è stata installata.

Per ulteriori informazioni sull'impostazione dell'autorizzazione READ_EXTERNAL_STORAGE , vedere setWhitelistedRestrictedPermissions() nella classe PackageInstaller.SessionParams .

Autorizzazioni di runtime

Android 6.0 introduce un nuovo modello di autorizzazioni di runtime in cui le app richiedono funzionalità quando necessario in fase di runtime. Poiché il nuovo modello include le autorizzazioni READ/WRITE_EXTERNAL_STORAGE , la piattaforma deve concedere dinamicamente l'accesso allo spazio di archiviazione senza READ/WRITE_EXTERNAL_STORAGE o riavviare le app già in esecuzione. Lo fa mantenendo tre viste distinte di tutti i dispositivi di archiviazione montati:

  • /mnt/runtime/default viene mostrato alle app senza autorizzazioni di archiviazione speciali e allo spazio dei nomi radice in cui adbd e altri componenti di sistema.
  • /mnt/runtime/read viene mostrato alle app con READ_EXTERNAL_STORAGE (Imposta LEGACY_STORAGE per Android 10)
  • /mnt/runtime/write viene mostrato alle app con WRITE_EXTERNAL_STORAGE

Al momento del fork di Zygote, creiamo uno spazio dei nomi di montaggio per ogni app in esecuzione e colleghiamo il montaggio alla vista iniziale appropriata in posizione. Successivamente, quando vengono concesse le autorizzazioni di runtime, vold salta nello spazio dei nomi di montaggio delle app già in esecuzione e bind monta la vista aggiornata in posizione. Tieni presente che i downgrade delle autorizzazioni comportano sempre l'arresto dell'app.

La funzionalità setns() utilizzata per implementare questa funzione richiede almeno Linux 3.8, ma le patch sono state trasferite correttamente su Linux 3.4. Il test CTS PermissionsHostTest può essere utilizzato per verificare il corretto comportamento del kernel.