Co to jest / storage / emulated / 0 /?


40

Ostatnio doszedłem do wniosku, że jeśli usunę z /sdcard/Downloadniej pliki, usuniesz je /storage/emulated/0/Download. A jeśli dodam do niego pliki /sdcard/Download, duplikuje je /storage/emulated/0/Download.

Więc co to jest /storage/emulated/0/? Do jakich celów mamy go w naszym systemie plików Android?

Odpowiedzi:


40

/storage/emulated/0/Download to rzeczywista ścieżka do plików.

/sdcard/Download jest dowiązaniem symbolicznym do rzeczywistej ścieżki /storage/emulated/0/Download

Jednak rzeczywiste pliki znajdują się w systemie plików w /data/media, który jest następnie montowany do /storage/emulated/0(i często także innych punktów montowania)

Symlink Przy obliczaniu symbolicznego łącze jest określenie dla każdego pliku, który zawiera odnośnik do innego pliku lub katalogu w postaci bezwzględnej lub względnej ścieżki, co wpływa na rozdzielczość ścieżki dostępu. Dowiązania symboliczne były już obecne w 1978 r. W minikomputerowych systemach operacyjnych z DEC i RDOS Data General.


15
Ta odpowiedź byłaby lepsza, gdyby wyjaśniła nieco, dlaczego jest „emulowana”. Wierzę, że Android ma jakiś hack, by sfałszować FAT-a, który jest właściwie poparty czymś lepszym, ale nie znam szczegółów i kliknąłem to pytanie, mając nadzieję na nauczenie się czegoś nowego.
R ..

4
@R .. „emulowany” IMHO wskazuje na fakt, że jest to „emulowana karta SD” (nie prawdziwa).
Izzy

10
@R .. Używa SDCardFS. Oto świetny artykuł na ten temat: xda-developers.com/… ( archiwum )
Nonny Moose

16

/storage/emulated/0/jest faktycznie /data/media/0/udostępniany przez emulowany / wirtualny system plików, a nie rzeczywisty.

Odnosi się to do mojej poprzedniej odpowiedzi tutaj , ale z bardziej odpowiednimi szczegółami.

PRZECHOWYWANIE ANDROIDA:

W systemie Android 5 :

/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media

Na Androidzie 6+ :

# for (Java) Android apps (running inside zygote virtual machine)
# "/storage to VIEW" bind mount is inside a separate mount namespace for every app
/sdcard >S> /storage/self/primary
/storage/self >B> /mnt/user/USER-ID
/mnt/user/USER-ID/primary >S> /storage/emulated/USER-ID
/storage/emulated >B> /mnt/runtime/VIEW/emulated
/mnt/runtime/VIEW/emulated >E> /data/media

# for services/daemons/processes in root/global namespace (VIEW = default)
/sdcard >S> /storage/self/primary
/storage >B> /mnt/runtime/default
/mnt/runtime/default/self/primary >S> /mnt/user/USER-ID/primary
/mnt/user/USER-ID/primary >S> /storage/emulated/USER-ID
/storage/emulated >B> /mnt/runtime/default/emulated
/mnt/runtime/default/emulated >E> /data/media

* >S>dla dowiązania symbolicznego, >E>do emulacji i >B>do podłączenia bind
* USER-IDbieżącego użytkownika w przypadku Multiple Userslub Work Profile, zwykle 0tj. właściciela urządzenia
*, VIEWjest jednym z read(dla aplikacji z uprawnieniami.READ_EXTERNAL_STORAGE) lub write(pozwoleniem.WRITE_EXTERNAL_STORAGE) lub default(dla procesów uruchomionych w katalogu głównym / global przestrzeń nazw montowania, tj. poza zygote)
* Istniały niewielkie różnice w poprzednich wersjach Androida, ale koncepcja emulacji była taka sama od czasu jej wdrożenia.
* Aby uzyskać więcej informacji na temat implementacji przestrzeni nazw montowania Androida, zobacz tę odpowiedź .

W skrócie /sdcardi /storage/emulated/0- które reprezentują system plików FAT / vFAT / FAT32 - wskazują na /data/media/0(lub /mnt/expand/[UUID]/media/0w przypadku Adoptable Storage ) poprzez FUSElub sdcardfsemulację.

Nie jest to specyficzne dla Androida, ale ogólnie związane z Linuksem, łączenie symlink i bind (patrz „Tworzenie wiązania mount”) nie wchodzi w zakres tego pytania, ponieważ pytanie dotyczy głównie części emulacji.

WSPÓŁZAWODNICTWO:

Dlaczego emulacja jest tutaj? Emulowany system plików to warstwa abstrakcji na rzeczywistym systemie plików ( ext4lub f2fs), która służy zasadniczo dwóm celom:

  • Zachowaj łączność USB urządzeń z Androidem z komputerami PC (wdrażane przez MTP teraz kilka dni)
  • Ogranicz nieautoryzowany dostęp aplikacji / procesów do prywatnych mediów użytkownika i danych innych aplikacji na karcie SD.

Przeczytaj szczegółowe informacje o podróży do systemu Android , podsumowanie jest następujące:

Wczesne urządzenia z Androidem miały mało pamięci wewnętrznej i polegały na (fizycznie) zewnętrznych kartach SD, które tradycyjnie korzystają z rodziny systemów plików FAT, aby zapewnić zgodność z większością komputerów (patrz dominacja Microsoftu w świecie komputerów).
Gdy pamięć wewnętrzna powiększyła się, ten sam system plików został przeniesiony na wewnętrzną (wciąż nazywaną „zewnętrzną”) kartę SD.
Ale wdrożenie FAT / vFAT miało dwa główne problemy, które były stopniowo rozwiązywane przez Google:

  • Urządzenia z Androidem były podłączone bezpośrednio do komputerów PC ( USB Mass Storage ), podobnie jak obecnie podłączamy dysk USB. UMS ujawnia urządzenie na poziomie bloku i odłącza kartę SD od frameworka Android (un-mounts), dzięki czemu całe dane są niedostępne dla aplikacji i możliwe uszkodzenie wielu funkcji.
  • FAT (będąc Okna ulubiony w dniach rozwoju) nie został zaprojektowany, aby egzekwować uprawnienia UNIX (tryb, UID i GID i również dowiązania symboliczne , i ioctlsjakFS_IOC_FIEMAP ). Zatem wszystkie dane na karcie SD były dostępne dla wszystkich aplikacji (ponieważ każda aplikacja na Androida jest użytkownikiem systemu UNIX / Linux i ma identyfikator użytkownika) bez żadnych ograniczeń, co budzi poważne obawy dotyczące prywatności i bezpieczeństwa.

Oba te problemy rozwiązano za pomocą emulacji:

  • Rzeczywista pamięć karty SD została przeniesiona na /datapartycję (lub partycję niezależną / sdcard na niektórych urządzeniach wcześniej), która przechowuje ext4system plików (stopniowo zastępowany przez f2fs), w pełni implementując uprawnienia UNIX.
  • Ten projekt uniemożliwiał korzystanie z UMS, ponieważ cała /datapartycja nie mogła być narażona na działanie komputera z dwóch dodatkowych powodów: (1)zawiera wiele ustawień i danych aplikacji, które należy chronić przed innymi aplikacjami, a także od ludzi. (2)Systemy plików Linux nie są obsługiwane przez system Windows.
    Tak więc UMS został zastąpiony Media Transfer Protocol, który jest rozszerzeniem typu klient-serwer na PTP - już ustanowiony protokół. MTP nie ujawnia urządzenia blokowego, ale działa poprzez stos oprogramowania. Host MTP działa na Androidzie jako aplikacja (android.process.media ) w pełni piaskownicy w systemie Android, nie jest w stanie wykonywać żadnych eskalowanych zadań.

Teraz aplikacje (i MTP, która jest również aplikacją) współdziałają z emulowaną pamięcią zamiast /data/media , osiągając oba cele jednocześnie, np. Wymuszając sprawdzenie uprawnień pod spodem i wyglądając jak system plików FAT na górnej powierzchni.

Google wdraża teraz emulację za pomocą sdcardfs, aby wyeliminować niedociągnięcia FUSE ; jednym z głównych jest narzut wejściowy / wyjściowy, tj. poprawa prędkości odczytu / zapisu.

ZEZWOLENIA DOTYCZĄCE PRZECHOWYWANIA ZEWNĘTRZNEGO:
Pojęcie publicznych i prywatnych plików na zewnętrznej pamięci można zademonstrować na przykładzie:
Zainstaluj aplikację Termux.
Utwórz katalogi /sdcard/Android/data/com.termux/test_diri /sdcard/test_dir.
Utwórz pliki /sdcard/Android/data/com.termux/test_filei /sdcard/Android/data/com.termux/test_file.
Wykonaj następujące polecenia:

bez_storage_perm * Powinieneś mieć zainstalowany WhatsApp lub wybrać prywatny folder innej aplikacji.

Teraz wymuś zatrzymanie aplikacji Termux i udziel pozwolenia na przechowywanie . Wykonaj ponownie polecenia:

with_storage_perm

Zobacz różnicę w uprawnieniach tych samych plików i katalogów. Wydaje się, że nie jest to po prostu możliwe bez emulacji na macierzystym systemie plików Linux, gdy istnieją setki aplikacji (użytkowników), którymi należy się jednocześnie zajmować. Jest to emulacja systemu plików, która pozwala na ujawnienie tego samego pliku z trzema różnymi zestawami uprawnień w tym samym czasie, niezależnie od oryginalnych uprawnień w rzeczywistym systemie plików:

# touch /data/media/0/test_file

# stat -c '%a %u %g %n' /data/media/0/test_file
644 1023 1023 /data/media/0/test_file

# stat -c '%a %u %g %n' /mnt/runtime/*/emulated/0/test_file
660 0 1015 /mnt/runtime/default/emulated/0/test_file
640 0 9997 /mnt/runtime/read/emulated/0/test_file
660 0 9997 /mnt/runtime/write/emulated/0/test_file

Zobacz także Co to jest identyfikator UID „u # _everybody”?

Związane z:


2
+1. Myślę, że źle zrozumiałem część dotyczącą MTP. Czy MTP wymaga systemu plików FAT na urządzeniu docelowym do pracy? Jeśli nie, to czy Google nie może użyć systemu plików ext4 do implementacji FUSE, ponieważ może to również wymusić kontrolę uprawnień wymaganych dla aplikacji, aby uzyskać dostęp tylko do swoich danych w pamięci współdzielonej?
Firelord

1
@Firelord przy omawianiu emulacji nie skupia się na implementacji MTP. Google dokonało już zmian w protokole MTP, aby zaspokoić określone potrzeby Androida, i być może mogłyby go zaimplementować za pośrednictwem rodzimego systemu plików Linux. Chodzi o to, że potrzebowaliśmy takiego, FAT-like permission-less filesystemktóry istniał we wczesnych dniach Androida, aby zapewnić kompatybilność wsteczną i który odpowiada koncepcji zewnętrznej pamięci masowej Androida. Dokonałem edycji, aby rozwinąć mój punkt widzenia.
Irfan Latif,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.