/ storage / emulated / 0 /은 무엇입니까?

최근에 파일을 /sdcard/Download삭제하면에서 파일을 삭제한다는 것을 알았습니다 /storage/emulated/0/Download. 그리고 파일을 추가하면에 파일 /sdcard/Download이 복제됩니다 /storage/emulated/0/Download.

그래서 무엇 /storage/emulated/0/입니까? 우리는 안드로이드 파일 시스템에 어떤 목적을 가지고 있습니까?

/storage/emulated/0/Download 파일의 실제 경로입니다.

/sdcard/Download 실제 경로에 대한 심볼릭 링크입니다 /storage/emulated/0/Download

그러나, 실제 파일의 파일 시스템에있는 /data/media다음에 장착된다 /storage/emulated/0(도 종종 다른 마운트 포인트)

심볼릭 에서 컴퓨팅, 심볼릭 링크 절대 또는 상대 경로의 형태로 다른 파일 또는 디렉토리에 대한 레퍼런스를 포함하고 그 경로의 해상도에 영향을 미치는 임의의 파일을위한 용어이다. 1978 년에는 DEC와 Data General의 RDOS의 미니 컴퓨터 운영 체제에 이미 심볼릭 링크가있었습니다.

/storage/emulated/0/실제로 /data/media/0/실제 파일 시스템이 아닌 에뮬레이트 / 가상 파일 시스템을 통해 노출됩니다.

이것은 내 이전 대답을 참조입니다 여기 하지만 더 관련 세부 사항.

안드로이드 스토리지 :

에 안드로이드 5 :

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

에 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

<sup>* >S>심볼릭 대, >E>에뮬레이션 및 >B>마운트 결합 용
* USER-ID의 경우에는 현재 사용자를 Multiple Users또는 Work Profile보통 0디바이스의 소유자, 즉
* VIEW중 하나 read또는 (permission.READ_EXTERNAL_STORAGE과 앱) write(permission.WRITE_EXTERNAL_STORAGE) 또는 default루트에서 실행되는 프로세스 ( / global mount namespace, 즉 zygote 외부)
* 이전 Android 버전에서는 약간의 차이가 있었지만 에뮬레이션의 개념은 구현 된 이후 동일합니다.
* Android의 마운트 네임 스페이스 구현에 대한 자세한 내용은이 답변을 참조하십시오 .</sup>

단락에서, /sdcard및 /storage/emulated/0는 FAT / VFAT를 / FAT32 파일 시스템을 대표하는 - - 지점을 향해 /data/media/0(또는 /mnt/expand/[UUID]/media/0경우에 채용 저장소 를 통해) FUSE또는 sdcardfs에뮬레이션.

안드로이드에 국한된 것이 아니라 일반적으로 리눅스와 관련된 symlink 및 bind mount ( "바인드 마운트 생성"참조)는 에뮬레이션 부분에 대한 문제이므로이 질문의 범위를 벗어납니다.

에뮬레이션:

에뮬레이션이 왜 여기에 있습니까? 에뮬레이트 된 파일 시스템은 기본적으로 두 가지 목적을 제공 하는 실제 파일 시스템 ( ext4또는 f2fs) 의 추상화 계층입니다 .

• PC에 Android 기기의 USB 연결 유지 (현재 MTP를 통해 구현 됨)
• 앱 / 프로세스에 대한 사용자의 개인 미디어 및 SD 카드의 다른 앱 데이터에 대한 무단 액세스를 제한합니다.

자세한 내용은 Android의 스토리지 여행 을 읽으십시오 . 요약은 다음과 같습니다.

초기 Android 장치는 내부 저장소가 부족했으며 전통적으로 FAT 파일 시스템 제품군을 사용하여 대부분의 PC와의 호환성을 보장하는 (실제로) 외부 SD 카드에 의존했습니다 (PC 세계에서 Microsoft의 지배력 참조).
내부 저장소의 크기가 커지면 동일한 파일 시스템이 내부 (여전히 "외부") SD 카드로 옮겨졌습니다.
그러나 FAT / vFAT 구현에는 Google에서 점진적으로 해결 한 두 가지 주요 문제가있었습니다.

• 요즘 USB 드라이브를 연결하는 것처럼 Android 기기가 PC에 직접 연결되었습니다 ( USB Mass Storage ). UMS는 장치를 블록 레벨로 노출하고 SD 카드를 Android 프레임 워크 (언 마운트 해제)에서 분리하여 전체 데이터를 앱에서 사용할 수 없게하고 많은 기능을 손상시킬 수 있습니다.
• FAT (개발 일에 Windows가 가장 좋아하는)는 UNIX 권한 (mode, uid, gid 및 이와 유사한 symlinks 등 ) 을 적용하도록 설계되지 않았습니다 . 따라서 SD 카드의 모든 데이터는 모든 앱에서 사용할 수 있었으며 (모든 Android 앱은 UNIX / Linux 사용자이며 UID가 있으므로) 개인 정보 보호 및 보안 문제가 심각합니다.ioctlsFS_IOC_FIEMAP

이 두 가지 문제는 모두 에뮬레이션을 통해 해결되었습니다.

• 실제 SD 카드 저장소는 파일 시스템을 /data점유 하는 파티션 (또는 이전에 일부 장치의 독립적 / sdcard 파티션) 으로 옮겨 ext4져서 (권장 적으로로 대체 됨 f2fs) UNIX 권한을 완전히 구현합니다.
• 이 디자인은 전체 /data파티션을 PC에 노출시킬 수 없기 때문에 UMS를 사용할 수 없게 만들었습니다 . (1)여기에는 많은 사용자 설정과 앱 데이터가 포함되어 있으며 이는 사용자뿐만 아니라 다른 앱에서도 보호되어야합니다. (2)Linux 파일 시스템은 Windows에서 지원되지 않습니다.
  따라서 UMS는 이미 설정된 프로토콜 인 PTP에 대한 클라이언트-서버 유형 확장 인 미디어 전송 프로토콜로 대체되었습니다. MTP 는 블록 장치를 공개하지 않지만 소프트웨어 스택을 통해 작동합니다. MTP 호스트는 android.process.mediaAndroid 프레임 워크에서 완전히 샌드 박스 된 앱 ( ) 으로 Android에서 실행되며 , 에스컬레이션 된 작업을 수행 할 수 없습니다.

이제 앱 (및 앱이기도 한 MTP)이 에뮬레이션 된 스토리지와 상호 작용하여 /data/media동시에 두 가지 목적을 달성합니다. 즉, 권한 확인을 수행하고 윗면의 FAT 파일 시스템처럼 보입니다.

구글은 현재 FUSE의 단점을 극복하기 위해 sdcardfs 를 통해 에뮬레이션을 구현하고있다 . 하나의 주요 사항은 입력 / 출력 오버 헤드, 즉 읽기 / 쓰기 속도를 향상시키는 것입니다.

외부 스토리지 권한 : 외부 스토리지
에있는 공개 및 개인 파일의 개념은
Termux 앱 설치 예제를 사용하여 설명 할 수 있습니다 .
디렉토리를 생성 /sdcard/Android/data/com.termux/test_dir하고 /sdcard/test_dir.
파일을 작성 /sdcard/Android/data/com.termux/test_file하고 /sdcard/Android/data/com.termux/test_file.
다음 명령을 실행하십시오.

^{* WhatsApp이 설치되어 있거나 다른 앱의 개인 폴더를 선택해야합니다.}

이제 Termux 앱을 강제 종료하고 스토리지 권한을 부여하십시오 . 명령을 다시 실행하십시오.

동일한 파일 및 디렉토리의 권한 차이를 확인하십시오. 수백 개의 앱 (사용자)이 동시에 처리 될 때 기본 Linux 파일 시스템에서 에뮬레이션없이 단순히 불가능한 것 같습니다. 이것은 실제 파일 시스템에 대한 원래 권한과 무관하게 동일한 파일을 세 가지 다른 권한 세트로 동시에 노출시킬 수있는 파일 시스템 에뮬레이션입니다.

# 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

또한 볼 은 "U # _everybody"UID 무엇입니까?

관련 :

• 'storage / emulated /'디렉토리에 액세스 할 수없는 이유는 무엇입니까?
• / storage / emulated / 0 내에서 심볼릭 링크 (또는 이와 동등한)를 만들려면 어떻게해야합니까?