از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
برنامه‌های امضاشده پلتفرم، برنامه‌هایی هستند که گواهی امضای یکسان (یا سازگار) را با بسته پلتفرم ( android ) به اشتراک می‌گذارند. یک برنامه امضا شده با پلتفرم می تواند یک برنامه سیستمی (واقع در یک پارتیشن تصویر سیستم) یا یک برنامه غیر سیستمی باشد. مجوزهای امضای پلتفرم مجوزهایی هستند که توسط بسته پلتفرم تعریف شده اند که سطح حفاظت signature را نیز دارند. بیلدهای قابل اشکال زدایی بیلدهایی هستند که android.os.Build.isDebuggable()true را برمی گرداند، مانند userdebug یا eng .
از لحاظ تاریخی، سازندگان دستگاه کنترل کمی بر مجوزهای signature پلتفرم می‌توانستند به برنامه‌های غیرسیستم امضاشده پلتفرم اعطا کنند. با شروع اندروید 15، سازندگان می‌توانند به صراحت مجوزهای امضای پلتفرم را در فایل‌های XML پیکربندی سیستم در فهرست /etc/permissions اعطا کنند. اگر یک برنامه غیرسیستمی با امضای پلتفرم به لیست مجاز برای مجوز امضای پلتفرم اضافه نشود، این مجوز به گونه‌ای عمل می‌کند که گویی برنامه روی پلتفرم امضا شده در ساخت‌های غیراشکال‌پذیر نیست.
یک لیست مجاز اضافه کنید
می‌توانید لیست‌های مجاز مجوز برای برنامه‌ها را در یک فایل XML یا در چندین فایل XML واقع در فهرست frameworks/base/etc/permissions فهرست کنید:
هیچ قانون سختگیرانه ای در مورد نحوه سازماندهی محتوا اعمال نمی شود. پیاده‌کننده‌های دستگاه می‌توانند ساختار محتوا را تعیین کنند تا زمانی که برنامه‌های مناسب و مجوزهای آن‌ها به لیست مجاز اضافه شوند.
یک لیست مجاز را سفارشی کنید
AOSP شامل یک اجرای لیست مجاز است که می توانید در صورت نیاز آن را سفارشی کنید، شبیه به لیست مجوزهای ممتاز . به عنوان مثال:
برای یافتن مجوزهای از دست رفته، برنامه امضا شده با پلتفرم خود را نصب کنید و گزارش‌های دستگاه را برای قالب پیام‌های هشدار زیر بررسی کنید:
Signature permission {PERMISSION_NAME} for package {PACKAGE_NAME} ({PACKAGE_PATH}) not in signature permission allowlist
این سیستم همچنان می‌تواند مجوزهای ساخت‌های قابل اشکال‌زدایی را اعطا کند، اما برای ساخت‌های غیراشکال‌پذیر مانند ساخت‌های user نه.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Signature permission allowlist\n\nPlatform signed apps are apps sharing the same (or compatible) signing\ncertificate with the platform package (`android`). A platform signed app can be\na system app (located on a system image partition), or a nonsystem app.\nPlatform signature permissions are permissions defined by the platform package\nthat also have the `signature` protection level. Debuggable builds are builds\nwhose `android.os.Build.isDebuggable()` return `true`, such as `userdebug` or\n`eng` builds.\n| **Note:** On this page, `/etc/permissions` resolves to \u003cvar translate=\"no\"\u003epartition\u003c/var\u003e`/etc/permissions`.\n\nHistorically, device manufacturers had little control over which platform\n`signature` permissions could be granted to platform signed nonsystem apps.\nStarting in Android 15, manufacturers can explicitly\ngrant platform signature permissions in the system configuration XML files in\nthe `/etc/permissions` directory. If a platform signed nonsystem app isn't\nadded to the allowlist for a platform signature permission, that permission acts\nas if the app isn't platform signed on nondebuggable builds.\n| **Note:** The allowlist isn't enforced on debuggable builds to facilitate easier testing.\n| **Note:** platform signed system apps and their requested permissions aren't affected by this change, however permissions newly requested by a system app update (but not requested by the original system app) still need to be added to the allowlist.\n\nAdd an allowlist\n----------------\n\nYou can list permission allowlists for apps in a single XML file or in multiple\nXML files located in the `frameworks/base/etc/permissions` directory:\n\n- `/etc/permissions/signature-permissions-`\u003cvar translate=\"no\"\u003eOEM_NAME\u003c/var\u003e`.xml`\n- `/etc/permissions/signature-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 the appropriate apps and their\npermissions are added to the allowlist.\n\nCustomize an allowlist\n----------------------\n\nAOSP includes an allowlist implementation that you can customize as needed,\nsimilar to the\n[privileged permission allowlist](/docs/core/permissions/perms-allowlist). For\nexample: \n\n \u003c!--\n ~ This XML file declares which platform signature permissions to grant to\n ~ platform signed nonsystem apps.\n --\u003e\n\n \u003cpermissions\u003e\n \u003csignature-permissions package=\"com.android.example\"\u003e\n \u003cpermission name=\"android.permission.READ_DEVICE_CONFIG\"/\u003e\n ...\n \u003c/signature-permissions\u003e\n ...\n \u003c/permissions\u003e\n\nFind missing permissions\n------------------------\n\nTo find missing permissions, install your platform signed app and inspect device\nlogs for the following format of warning messages: \n\n Signature permission {PERMISSION_NAME} for package {PACKAGE_NAME} ({PACKAGE_PATH}) not in signature permission allowlist\n\nThe system can still grant the permission on debuggable builds, but not on\nnondebuggable builds such as `user` builds."]]
