2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
기존 저장소
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android는 변경 불가능한 POSIX 권한 클래스와 모드를 포함하고 대소문자를 구분하지 않는 파일 시스템으로 정의되는 기존 저장소가 있는 기기를 지원합니다.
기존 저장소의 개념은 에뮬레이션된 저장소와 휴대용 저장소를 포괄합니다.
휴대용 저장소는 시스템에 의해 채택되지 않은 모든 외부 저장소로 정의되며, 따라서 형식이 지정되거나 암호화되지 않고 특정 기기에 연결되지 않습니다.
기존 외부 저장소는 저장된 데이터에 최소의 보호 기능을 제공합니다. 따라서 시스템 코드는 민감한 데이터를 외부 저장소에 저장하면 안 됩니다. 특히 구성 및 로그 파일은 효과적으로 보호될 수 있는 내부 저장소에만 저장되어야 합니다.
멀티 사용자 외부 저장소
Android 4.2부터는 기기에서 여러 사용자를 지원할 수 있으며, 외부 저장소가 다음과 같은 제약 조건을 충족해야 합니다.
- 각 사용자는 격리된 기본 외부 저장소를 자체적으로 보유해야 하며, 다른 사용자의 기본 외부 저장소 액세스 권한을 보유하면 안 됩니다.
/sdcard
경로가 프로세스의 사용 주체(사용자)에 따라 올바른 사용자별 기본 외부 저장소를 확인해야 합니다.
Android/obb
디렉터리에 있는 대용량 OBB 파일을 위한 저장소는 최적화를 위해 여러 사용자 간에 공유될 수 있습니다.
- 보조 외부 저장소는 앱에 의한 작성이 불가능해야 하지만 합성 권한에 의해 허용되는 패키지 전용 디렉터리에서는 예외입니다.
이 기능의 기본적인 플랫폼 구현에서는 Linux 커널 네임스페이스를 활용하여 Zygote로 포크된 각 프로세스에 격리된 마운트 테이블을 생성한 다음 바인드 마운트를 사용하여 올바른 사용자별 기본 외부 저장소를 비공개 네임스페이스 안으로 제공합니다.
부팅 시 시스템은 에뮬레이션된 단일 외부 저장소 FUSE 데몬을 앱에서 숨김 처리된 EMULATED_STORAGE_SOURCE
에 마운트합니다. 분기된 Zygote는 적절한 사용자별 하위 디렉터리를 FUSE 데몬 아래에서 EMULATED_STORAGE_TARGET
로 바인드 마운트하므로 외부 저장소 경로가 앱에서 올바르게 확인됩니다. 앱은 다른 사용자 저장소의 액세스 가능한 마운트 지점이 없으므로 앱이 시작된 사용자의 저장소에만 액세스할 수 있습니다.
또한 이러한 구현은 공유된 하위 트리 커널 기능을 사용하여 기본 루트 네임스페이스의 마운트 이벤트를 앱 네임스페이스로 전파합니다. 그러면 ASEC 컨테이너와 OBB 마운팅 등의 기능이 계속해서 정상적으로 작동할 수 있으며, 이때 rootfs를 공유된 상태로 마운트한 다음 각 Zygote 네임스페이스가 생성되면 이를 하위로 다시 마운트합니다.
여러 외부 저장소 기기
Android 4.4부터 여러 외부 저장소 기기는 Context.getExternalFilesDirs()
, Context.getExternalCacheDirs()
, Context.getObbDirs()
를 통해 개발자에게 표시됩니다.
이러한 API를 통해 표시된 외부 저장소 기기는 기기의 반영구적 일부여야 합니다(예: 배터리 칸의 SD 카드 슬롯). 개발자는 이러한 위치에 저장된 데이터를 장기간에 걸쳐 사용할 수 있을 것으로 기대합니다. 따라서 일시적인 저장소 기기(USB 대용량 저장소 드라이브 등)는 이러한 API를 통해 표시되면 안 됩니다.
WRITE_EXTERNAL_STORAGE
권한은 기기의 기본 외부 저장소 쓰기 액세스 권한만 부여해야 합니다. 앱은 보조 외부 저장소 기기에 작성 작업을 실행할 수 없어야 하지만 합성 권한에 의해 허용되는 패키지 전용 디렉터리에서는 예외입니다. 이러한 방식으로 쓰기를 제한하면 애플리케이션을 제거할 때 파일을 정리할 수 있습니다.
Android 6.0은 USB 플래시 드라이브처럼 잠깐만 기기에 연결되는 휴대용 저장소 기기를 지원합니다. 사용자가 새로운 휴대용 기기를 삽입하면 플랫폼에는 이 기기의 콘텐츠를 복사하거나 관리할 수 있도록 허용하는 알림이 표시됩니다.
Android 6.0에서는 채택되지 않은 모든 기기가 휴대용으로 간주됩니다. 휴대용 저장소는 잠깐만 연결되므로 플랫폼에서 미디어 스캔과 같은 과도한 작업을 피합니다. 타사 앱은 저장소 액세스 프레임워크를 거쳐야만 휴대용 저장소의 파일과 상호작용할 수 있습니다. 직접적인 액세스는 개인 정보 보호 및 보안을 이유로 명시적으로 차단됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-04-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-04-27(UTC)"],[],[],null,["# Traditional storage\n\nAndroid supports devices with traditional storage, which is defined to be a\ncase-insensitive filesystem with immutable POSIX permission classes and modes.\nThe notion of traditional storage encompasses emulated and portable storage.\nPortable storage is defined as any external storage that is not [adopted](/docs/core/storage/adoptable) by the\nsystem and therefore not formatted and encrypted or tied to a specific device.\nBecause traditional external storage offers minimal protection for stored data,\nsystem code should not store sensitive data on external storage. Specifically,\nconfiguration and log files should only be stored on internal storage where\nthey can be effectively protected.\n\nMulti-user external storage\n---------------------------\n\nStarting in Android 4.2, devices can support multiple users, and external\nstorage must meet the following constraints:\n\n- Each user must have their own isolated primary external storage, and must not have access to the primary external storage of other users.\n- The `/sdcard` path must resolve to the correct user-specific primary external storage based on the user a process is running as.\n- Storage for large OBB files in the `Android/obb` directory may be shared between multiple users as an optimization.\n- Secondary external storage must not be writable by apps, except in package-specific directories as allowed by synthesized permissions.\n\nThe default platform implementation of this feature leverages Linux kernel\nnamespaces to create isolated mount tables for each Zygote-forked process,\nand then uses bind mounts to offer the correct user-specific primary external\nstorage into that private namespace.\n\nAt boot, the system mounts a single emulated external storage FUSE daemon\nat `EMULATED_STORAGE_SOURCE`, which is hidden from apps. After\nthe Zygote forks, it bind mounts the appropriate user-specific subdirectory\nfrom under the FUSE daemon to `EMULATED_STORAGE_TARGET` so that\nexternal storage paths resolve correctly for the app. Because an app lacks\naccessible mount points for other users' storage, they can only access\nstorage for the user it was started as.\n\nThis implementation also uses the shared subtree kernel feature to\npropagate mount events from the default root namespace into app namespaces,\nwhich ensures that features like ASEC containers and OBB mounting continue\nworking correctly. It does this by mounting the rootfs as shared, and then\nremounting it as slave after each Zygote namespace is created.\n\nMultiple external storage devices\n---------------------------------\n\nStarting in Android 4.4, multiple external storage devices are surfaced\nto developers through `Context.getExternalFilesDirs()`,\n`Context.getExternalCacheDirs()`, and\n`Context.getObbDirs()`.\n\n\u003cbr /\u003e\n\nExternal storage devices surfaced through these APIs must be a semi-permanent part of the device (such as an SD card slot in a battery compartment). Developers expect data stored in these locations to be available over long periods of time. For this reason, transient storage devices (such as USB mass storage drives) should not be surfaced through these APIs.\n\n\u003cbr /\u003e\n\nThe `WRITE_EXTERNAL_STORAGE` permission must only grant write\naccess to the primary external storage on a device. Apps must not be\nallowed to write to secondary external storage devices, except in their\npackage-specific directories as allowed by synthesized\npermissions. Restricting writes in this way ensures the system can clean\nup files when applications are uninstalled.\n\nUSB media support\n-----------------\n\nAndroid 6.0 supports portable storage devices which are only connected to the\ndevice for a short period of time, like USB flash drives. When a user inserts a\nnew portable device, the platform shows a notification to let them copy or\nmanage the contents of that device.\n\nIn Android 6.0, any device that is not adopted is considered portable. Because\nportable storage is connected for only a short time, the platform avoids heavy\noperations such as media scanning. Third-party apps must go through the [Storage Access Framework](https://developer.android.com/guide/topics/providers/document-provider.html) to interact with files on portable storage; direct access is explicitly\nblocked for privacy and security reasons."]]