권한이 있는 앱은 시스템 이미지 파티션의 priv-app 디렉터리에 위치한 시스템 앱입니다. Android 출시에 사용되는 파티션은 다음과 같습니다.
Android 9 이상: /system, /product, /vendor
Android 8.1 이하: /system
지금까지 기기 제조업체에는 어떤 signature | privileged 권한을 권한 있는 앱에 부여할 수 있는지를 제어하는 권한이 부족했습니다. Android 8.0부터는 제조업체가 /etc/permissions 디렉터리의 시스템 구성 XML 파일에서 독점 권한을 명시적으로 부여할 수 있습니다. Android 9부터는 구현자가 모든 독점 권한을 명시적으로 부여하거나 거부할 수 있습니다. 권한이 부여되지 않으면 기기가 부팅되지 않습니다.
privapp-permissions.xml 파일은 동일한 파티션의 권한 있는 앱에만 권한을 부여하거나 거부할 수 있습니다. 예를 들어 /product 파티션의 앱이 독점 권한을 요청하면 요청은 /product의 privapp-permissions.xml 파일에 의해서만 승인 또는 거부될 수 있습니다.
허용 목록 추가
앱의 권한 허용 목록은 다음과 같이 frameworks/base/etc/permissions 디렉터리에 있는 단일 XML 또는 여러 XML 파일에 나열할 수 있습니다.
콘텐츠 구성 방법에는 엄격한 규칙이 적용되지 않습니다. /system/priv-app의 모든 앱이 허용 목록에 있는 한 기기 구현자는 콘텐츠 구조를 파악할 수 있습니다. 예를 들어 Google에서는 권한이 있는 모든 앱의 단일 허용 목록을 개발했습니다.
다음 구성이 권장됩니다.
Android 오픈소스 프로젝트(AOSP) 트리에 이미 포함된 앱의 권한이 /etc/permissions/privapp-permissions-platform.xml에 나열됩니다.
다른 앱에서는 /etc/permissions/privapp-permissions-DEVICE_NAME.xml 형식의 파일을 사용합니다.
허용 목록 맞춤설정
AOSP에는 필요에 따라 맞춤설정 가능한 허용 목록 구현이 포함되어 있습니다.
권한을 거부해야 하는 경우 permission 태그가 아닌 deny-permission 태그를 사용하도록 XML을 수정합니다. 예:
새 기기를 시작할 때 누락된 권한을 찾으려면 다음과 같이 전환 로그 모드를 사용 설정합니다.
ro.control_privapp_permissions=log
위반사항은 로그 파일에서 보고됩니다. 독점이 아닌 권한이 부여됩니다.
이렇게 하면 계속 위반 목록을 제공하면서 기기가 작동 상태를 유지합니다. 오류 메시지 형식은 다음과 같습니다.
PackageManager: Privileged permission {PERMISSION_NAME} for package {PACKAGE_NAME} - not in privapp-permissions allowlist
모든 위반은 누락된 권한을 적절한 허용 목록에 추가하는 방식으로 해결해야 합니다.
다음에 유의하세요.
Android 9 이상에서는 독점 권한을 위반하면 기기가 시작되지 않습니다. 대신 모든 독점 권한을 명시적으로 허용하거나 거부해야 합니다.
Android 8.0 이하에서는 priv-app 경로에 있어도 영향을 받는 앱에 누락된 권한이 부여되지 않습니다.
허용 목록 적용
허용 목록을 만든 후에는 빌드 속성 ro.control_privapp_permissions=enforce를 설정하여 런타임 적용을 사용 설정합니다.
허용 목록은 package="android"가 포함된 앱에서 선언한 권한에만 필요합니다. ro.control_privapp_permissions 속성 상태는 호환성 정의 문서(CDD)의 섹션 9.1 권한을 준수해야 합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-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"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Privileged permission allowlist\n\nPrivileged apps are system apps located in a `priv-app` directory on a\nsystem image partition. The partitions used for Android releases are:\n\n- Android 9 and higher: `/system, /product, /vendor`\n- Android 8.1 and lower: `/system`\n\n| **Note:** On this page, `/etc/permissions/priv-app` resolves to \u003cvar translate=\"no\"\u003epartition\u003c/var\u003e`/etc/permissions/priv-app`.\n\nHistorically, device manufacturers had little control over which\n**signature \\| privileged** permissions could be granted to\nprivileged apps. Starting in Android 8.0, manufacturers can explicitly grant\nprivileged permissions in the system configuration XML files in the\n`/etc/permissions` directory. As of Android 9, implementors can\nexplicitly grant or deny all privileged permissions. If privileged permissions are not granted,\nthe device won't boot.\n\nThe `privapp-permissions.xml` file can only grant or deny\npermissions for privileged apps on the same partition. For example, if\nan app on the `/product` partition requests privileged permissions,\nthe request can only be granted or denied by a `privapp-permissions.xml`\nfile on `/product`.\n| **Note:** Permissions defined by the core platform (the `android` package) and `CarService` (`com.android.car.updatable`) must be allowlisted. Privileged permissions defined by device manufacturers are automatically granted. Only list apps in the `privapp-permissions.xml` file that actually exist on the partition. When an app isn't on the partition, the entry is ignored. Privileged apps on the `/vendor` partition can only have privileged permissions whose protection level is set to `vendorPrivileged`.\n\nAdd an allowlist\n----------------\n\n\nPermission allowlists for apps can be listed in a single XML file or in multiple\nXML files located in the `frameworks/base/etc/permissions` directory:\n\n- `/etc/permissions/privapp-permissions-`\u003cvar translate=\"no\"\u003eOEM_NAME\u003c/var\u003e`.xml`\n- `/etc/permissions/privapp-permissions-`\u003cvar translate=\"no\"\u003eDEVICE_NAME\u003c/var\u003e`.xml`\n\nNo strict rule applies to how content is organized. Device implementers can\ndetermine content structure as long as all apps from `/system/priv-app`\nare allowlisted. For example, Google has developed a single allowlist for all privileged apps.\nWe recommend the following organization:\n\n- Permissions for apps already included in the [Android Open Source Project (AOSP)](https://cs.android.com/android/platform/superproject/main) tree are listed in `/etc/permissions/privapp-permissions-platform.xml`.\n- For other apps, use files of the form, `/etc/permissions/privapp-permissions-`\u003cvar translate=\"no\"\u003eDEVICE_NAME\u003c/var\u003e`.xml`.\n\n### Customize an allowlist\n\n\nAOSP includes an allowlist implementation that can be customized as needed.\n\n\nIf a permission must be denied, edit the XML to use a `deny-permission` tag\ninstead of a `permission`tag. For example: \n\n```carbon\n\u003c!-- This XML file declares which signature|privileged permissions to grant to\nprivileged apps that come with the platform --\u003e\n\n \u003cpermissions\u003e\n \u003cprivapp-permissions package=\"com.android.backupconfirm\"\u003e\n \u003cpermission name=\"android.permission.BACKUP\"/\u003e\n \u003cpermission name=\"android.permission.CRYPT_KEEPER\"/\u003e\n \u003c/privapp-permissions\u003e\n\n \u003cprivapp-permissions package=\"com.android.cellbroadcastreceiver\"\u003e\n\n \u003c!-- Don't allow the application to interact across users --\u003e\n\n \u003cdeny-permission name=\"android.permission.INTERACT_ACROSS_USERS\"/\u003e\n \u003cpermission name=\"android.permission.MANAGE_USERS\"/\u003e\n \u003cpermission name=\"android.permission.MODIFY_PHONE_STATE\"/\u003e\n \u003cpermission name=\"android.permission.READ_PRIVILEGED_PHONE_STATE\"/\u003e\n \u003cpermission name=\"android.permission.RECEIVE_EMERGENCY_BROADCAST\"/\u003e\n \u003c/privapp-permissions\u003e\n ...\n```\n\n### Find missing permissions\n\n\nTo find missing permissions when starting a new device, enable transitional log mode: \n\n```\nro.control_privapp_permissions=log\n```\n\n\nViolations are reported in the log file. Non-privileged permissions are granted.\nDoing so ensures the device remains in a working state while still providing the list of\nviolations. The error message format is as follows: \n\n```\nPackageManager: Privileged permission {PERMISSION_NAME} for package {PACKAGE_NAME} - not in privapp-permissions allowlist\n```\n\n\nAll violations must be addressed by adding the missing permissions to the appropriate allowlists.\nNote that in:\n\n- Android 9 and higher, violations of privileged permissions prevent the device from starting. Instead, you must explicitly allow or deny all privileged permissions.\n- Android 8.0 and lower, missing permissions are not granted to the affected apps despite being in the `priv-app` path.\n\nEnforce an allowlist\n--------------------\n\n\nAfter you create your allowlists, enable runtime enforcement by setting the build\nproperty `ro.control_privapp_permissions=enforce`.\n\n\nAllowlisting is required only for permissions declared by apps with\n`package=\"android\"`. The `ro.control_privapp_permissions`\nproperty state must adhere to\n[Section 9.1 Permissions](/docs/compatibility/14/android-14-cdd#91_permissions)\nin the Compatibility Definition Document (CDD)."]]
