اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
التطبيقات الموقَّعة من النظام الأساسي هي التطبيقات التي تشارك شهادة التوقيع
نفسها (أو المتوافقة) مع حزمة النظام الأساسي (android). ويمكن أن يكون التطبيق الموقَّع من النظام الأساسي
تطبيقًا للنظام (يقع في قسم صورة النظام) أو تطبيقًا غير تابع للنظام.
أذونات توقيع النظام الأساسي هي أذونات تحدّدها حزمة النظام الأساسي
وتتضمّن أيضًا مستوى الحماية signature. الإصدارات القابلة لتصحيح الأخطاء هي إصدارات
يعرض فيها android.os.Build.isDebuggable() القيمة true، مثل إصدارات userdebug أو
eng.
في السابق، لم يكن بإمكان المصنّعين التحكّم كثيرًا في أذونات
signature النظام التي يمكن منحها للتطبيقات غير المُنشأة من نظام التشغيل والتي تم توقيعها من النظام.
بدءًا من Android 15، يمكن للجهات المصنّعة منح أذونات توقيع النظام صراحةً في ملفات XML الخاصة بإعدادات النظام في directory
/etc/permissions. إذا لم تتم
إضافة تطبيق غير نظامي موقَّع على النظام الأساسي إلى القائمة المسموح بها لإذن توقيع النظام الأساسي، يعمل هذا الإذن
كما لو لم يكن التطبيق موقَّعًا على النظام الأساسي في الإصدارات غير القابلة لتصحيح الأخطاء.
إضافة قائمة مسموح بها
يمكنك إدراج قوائم الإذن المسموح بها للتطبيقات في ملف XML واحد أو في ملفات XML متعددة في الدليل frameworks/base/etc/permissions:
لا تنطبق أي قاعدة صارمة على كيفية تنظيم المحتوى. يمكن لمنفّذِي الأجهزة تحديد بنية المحتوى شرط إضافة التطبيقات المناسبة وموافقات
استخدامها إلى القائمة المسموح بها.
للعثور على الأذونات غير المتوفّرة، ثبِّت تطبيقك الموقَّع على المنصة وتحقَّق من سجلّات
الجهاز بحثًا عن تنسيق رسائل التحذير التالي:
Signature permission {PERMISSION_NAME} for package {PACKAGE_NAME} ({PACKAGE_PATH}) not in signature permission allowlist
وسيظل بإمكان النظام منح الإذن على النُسخ القابلة لتصحيح الأخطاء، ولكن ليس على
النُسخ غير القابلة لتصحيح الأخطاء، مثل نُسخ user.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
