اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
إذن إرسال الإشعارات للموافقة على تلقّيها
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تستخدم الإشعارات في Android 13 نموذجًا للموافقة، وهو
تغيير عن إصدارات Android السابقة التي تستخدم نموذجًا لإيقاف الميزة. في نظام التشغيل
Android 13، على جميع التطبيقات أن تطلب من المستخدمين الإذن قبل
إرسال طلبات الإشعارات. يساعد هذا النموذج في تقليل انقطاعات الإشعارات، والحدّ من كثرة المعلومات، ويساعد المستخدمين في التحكّم في الإشعارات التي تظهر لهم استنادًا إلى ما يهمّهم. لدعم أسلوب الموافقة، على المصنّعين الأصليّين للأجهزة إجراء تغييرات في أنظمة أذونات الإشعارات وأذونات وقت التشغيل.
توضّح هذه الصفحة الإجراءات التي يجب أن تتّخذها المصنّعين الأصليّين للأجهزة لتفعيل هذا التغيير وكيفية
التحقّق من صحة التنفيذ.
تنفيذ التغييرات على الإشعارات التي تتطلب الموافقة
بدءًا من Android 13، على التطبيقات الإفصاح عن
نيتها لإرسال الإشعارات من خلال طلب
android.permission.POST_NOTIFICATION
إذن التشغيل من النظام قبل أن تتمكّن من إرسال الإشعارات.
في نظام التشغيل Android 13 والإصدارات الأحدث، يتم تخزين الإعداد الذي يحدِّد
ما إذا كان بإمكان التطبيق إرسال إشعارات إلى المستخدم في نظام الأذونات.
قبل الإصدار 13 من Android، كان يتم تخزين هذا الإعداد في
نظام الإشعارات. وبالتالي، على المصنّعين الأصليين للأجهزة نقل بيانات الإشعارات الحالية
التي تحدد ما إذا كان يُسمح للتطبيق بإرسال إشعارات، من نظام الإشعارات
إلى نظام أذونات التشغيل. على المصنّعين الأصليّين للأجهزة أيضًا الاحتفاظ بواجهات برمجة التطبيقات الحالية
في نظام الإشعارات الذي يعرض هذه البيانات لمطوّري التطبيقات.
تستند التغييرات التي تطرأ على نظامَي الإشعارات والأذونات إلى
نموذج الموافقة على سلوك إشعارات المستخدمين، ويتم
وصفها في قسم إرشادات التنفيذ.
سلوك إشعارات المستخدمين في نموذج الموافقة
يوضّح الجدول التالي سلوك الإشعارات لإصدارات التطبيقات المختلفة على جهاز يعمل بنظام التشغيل Android 13:
جهاز يعمل بنظام التشغيل Android 13 |
التطبيقات التي تستهدف الإصدار 13 من نظام التشغيل Android أو إصدارًا أحدث |
التطبيقات التي تستهدف إصدارات أقل من Android 13 |
مثبَّت حديثًا
|
يتم حظر الإشعارات إلى أن يطلب منك التطبيق إعادة تفعيلها.
تتحكّم التطبيقات في وقت طلب الأذونات.
|
يتم حظر الإشعارات إلى أن يطلب منك نظام التشغيل عرضها.
يتم طلب الإذن عند تشغيل التطبيق لأول مرة.
|
التطبيق الحالي (ترقية)
|
يُسمح بظهور الإشعارات إلى أن يطلب التطبيق ذلك.
يتم منح الإذن المؤقت إلى أن يطلب التطبيق الإذن في أول عملية تشغيل مؤهلة.
|
يتم السماح بالإشعارات إلى أن يطلب منك نظام التشغيل ذلك.
يتم منح الإذن المؤقت حتى التشغيل الأول للتطبيق.
|
إرشادات التنفيذ
للاطّلاع على مرجع التنفيذ، يُرجى الرجوع إلى
خدمة الإشعارات و
خدمة الأذونات و
خدمة السياسات. لتنفيذ استثناءات
لمعالِجي الأذونات التلقائية، يُرجى الاطّلاع على
أذونات التشغيل.
أثناء التنفيذ، اتّبِع الإرشادات التالية بشأن سلوك إعلامات المستخدمين في التطبيقات التي تستهدف الإصدار 13 من نظام التشغيل Android أو إصدارات حِزم SDK الأقدم:
- يجب ألا تُرسِل التطبيقات المثبَّتة حديثًا على جهاز Android 13 إشعارًا بدون موافقة المستخدم على طلب الحصول على الإذن.
- إذا كان التطبيق يستهدف الإصدار 13 من Android
والإصدارات الأحدث، يجب حظر الإشعارات إلى أن يطلب التطبيق ذلك، لأنّ التطبيق هو الذي يتحكم في وقت طلب إذن المستخدم وما إذا كان سيطلبه.
- إذا كان التطبيق يستهدف إصدارات أقل من Android 13، يجب حظر الإشعارات إلى أن يطلب نظام التشغيل ذلك. يجب أن يعرض نظام التشغيل طلب الحصول على الإذن عند تشغيل
التطبيق لأول مرة.
يجب السماح لأي تطبيق كان مثبَّتًا على الجهاز قبل الترقية إلى Android 13، أو أي تطبيق تم استعادته من خلال ميزة "الاحتفاظ بنسخة احتياطية"
واسترجاعها، بإرسال الإشعارات إلى أن يشغِّل المستخدم
نشاطًا من هذا التطبيق لأول مرة.
بالنسبة إلى التطبيقات التي تستهدف حزمة تطوير البرامج (SDK) لإصدارات Android 13
والإصدارات الأحدث، إذا لم يخصِّص المستخدم في السابق إعدادات الإشعارات
لهذا التطبيق على مستوى التطبيق أو NotificationChannel
، يجب إبطال منح الإذن المؤقت. ويجب أن تطلب التطبيقات إذنًا من المستخدم قبل أن تتمكّن
من مواصلة إرسال الإشعارات.
إذا كان التطبيق الذي تم ترقيته لاستهداف Android 13 لا يملك
في الوقت الحالي إذن الإشعارات من خلال منح الموافقة على الترقية المؤقتة
، وكان المستخدم قد شغّله مرة واحدة على الأقل، يجب أن يعرض التطبيق
طلب إذن الإشعارات قبل السماح له بتشغيل أي خدمات أخرى تعمل في المقدّمة.
بالنسبة إلى التطبيقات التي تستهدِف إصدارات حزمة SDK أقل من
Android 13،
اعترض
إطلاق النشاط الأول بعد أن ينشئ التطبيق NotificationChannel
واحدًا على الأقل لعرض طلب إذن يسأل المستخدم عما إذا كان يريد تلقّي إشعارات
من التطبيق.
إذا خصّص المستخدم في السابق إعدادات الإشعارات على مستوى
التطبيق أو NotificationChannel
لتطبيق على الجهاز الذي يتم ترقيته أو في
ملف احتياطي تتم استعادته على الجهاز، يجب نقل الإعداد على مستوى التطبيق إلى
نظام الأذونات باستخدام العلامة FLAG_PERMISSION_USER_SET
. يجب عدم عرض أي مزيد من الطلبات بشأن إذن إرسال الإشعارات إلى المستخدم ما لم يطلب التطبيق ذلك تحديدًا.
يجب أن تكون ميزة "الاحتفاظ بنسخة احتياطية من البيانات واستعادتها" متوافقة مع الإصدارات السابقة واللاحقة من نظام التشغيل بين
جهاز Android 13 وجهاز يعمل بإصدار سابق من نظام التشغيل. يجب استعادة البيانات الاحتياطية التي تم إنشاؤها من جهاز Android 13
على إصدار أقدم من نظام التشغيل، ويجب استعادة البيانات الاحتياطية من إصدار أقدم
من نظام التشغيل على جهاز Android 13.
يجب أن تكون إشعارات الوسائط المرتبطة بتشغيل الوسائط الجارية معفاة
من إذن الإشعارات.
التحقّق من صحة التغييرات في نظامَي الإشعارات والأذونات
للتحقّق من صحة التنفيذ، عليك إجراء الاختبارات التالية:
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Notification permission for opt-in notifications\n\nNotifications in Android 13 use an opt-in model, which\nis a change from previous Android versions, which use an opt-out model. In\nAndroid 13, all apps must ask users for permission before\nsending notification prompts. This model helps reduce notification\ninterruptions, minimizes information overload, and helps users control what\nnotifications appear based on what's important to them. To support the\nopt-in model, OEMs must implement changes in the notification and runtime\npermission systems.\n\nThis page describes what OEMs must implement to support this change and how\nto validate the implementation.\n\nImplement changes for opt-in notifications\n------------------------------------------\n\nStarting with Android 13, apps must declare their\nintent to send notifications by requesting the\n[`android.permission.POST_NOTIFICATION`](https://developer.android.com/about/versions/13/changes/notification-permission)\nruntime permission from the system before they can send notifications.\n\nIn Android 13 and higher, the setting that determines\nif an app can send notifications to the user is stored in the permission system.\nPrior to Android 13, this setting was stored in the\nnotification system. Hence, OEMs must migrate the existing notification data\nabout whether an app is allowed to send notifications, from the notification\nsystem into the runtime permission system. OEMs must also maintain existing APIs\nin the notification system that surface that data to app developers.\n\nChanges to the notification and permission systems are based on the\n[opt-in model of user notification behavior](#behavior-optin) and are\ndescribed in the [Guidelines for implementation](#guidelines-impl) section.\n\n### Behavior of user notifications in an opt-in model\n\nThe following table illustrates the notification behavior for various app\nversions on a device running Android 13:\n\n| Device on Android 13 | Apps targeting Android 13 or higher | Apps targeting versions lower than Android 13 |\n|------------------------|--------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|\n| New install | Notifications are blocked until prompted by the app. Apps control when to ask for permission. | Notifications are blocked until prompted by the OS. Permission is asked on the first run of the app. |\n| Existing app (upgrade) | Notifications are allowed until prompted by the app. Temporary permission is granted until the app asks on the first qualifying run. | Notifications are allowed until prompted by the OS. Temporary permission is granted until the first run of the app. |\n\n### Guidelines for implementation\n\nFor reference implementation, refer to\n[notification service](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/notification/),\n[permission service](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/pm/permission/) and\n[policy service](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/policy). To implement exceptions\nfor default permission handlers see\n[Runtime Permissions](/docs/core/permissions/runtime_perms#integration).\n\nDuring implementation, use the following guidelines on user notification\nbehavior for apps targeting Android 13 or lower SDKs:\n\n- Freshly installed apps on an Android 13 device must not send a notification without the user approving a permission prompt.\n - If the app targets versions Android 13 and higher, notifications must be blocked until prompted by the app as the app controls when and if to ask for user permission.\n - If the app targets versions lower than Android 13, notifications must be blocked until prompted by the OS. The OS must show the permission prompt on the first run of the app.\n- Any app that existed on the device prior to an upgrade to\n Android 13, or any app that was restored through backup\n and restore, must be allowed to send notifications until the first time the user\n launches an activity from that app.\n\n - For apps that target SDK of versions Android 13\n and higher, if the user hasn't previously customized notification settings for\n this app at the app or `NotificationChannel` level, revoke the temporary\n permission grant. Apps must then ask the user for permission before being\n allowed to continue to send notifications.\n\n If an upgraded app targeting Android 13 doesn't\n currently have the notification permission through the temporary upgrade\n grant, and the user has launched it at least once, the app must show a\n notification permission prompt before it's allowed to run any further foreground\n services.\n - For apps that have a target SDK of versions lower than\n Android 13,\n [intercept](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/wm/ActivityInterceptorCallback.java)\n the first activity launch after the app has created at least one `NotificationChannel`\n to show a permission prompt asking if the user wants to receive notifications\n from the app.\n\n If a user previously customized notification settings at the\n app or `NotificationChannel` level for an app on the upgrading device or in a\n backup being restored to the device, the app level setting must be migrated into\n the permission system with the `FLAG_PERMISSION_USER_SET` flag. No further\n notification permission prompt must be shown to the user unless the app\n specifically asks it to be.\n- Backup and restore must be backward and forward compatible between an\n Android 13 device and a device from an earlier OS\n version. Backup data generated from an Android 13\n device must restore onto an earlier OS version, and backup data from an earlier\n OS version must restore onto an Android 13 device.\n\n- Media notifications associated with ongoing media playback must be exempt\n from the notification permission.\n\nValidate changes to the notification and permission systems\n-----------------------------------------------------------\n\nTo validate the implementation, run the following tests:\n\n- Unit tests as specified in [`PreferencesHelperTest`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/tests/uiservicestests/src/com/android/server/notification/PreferencesHelperTest.java),\n [`NotificationManagerServiceTest`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/tests/uiservicestests/src/com/android/server/notification/NotificationManagerServiceTest.java).\n\n- Any manual test that tests upgrades and backup and restore.\n\n- Any CTS Permission and Notification system test that sends notifications.\n Some of these tests are located in [cts/tests/tests/permission/](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Permission/tests/cts/permission/src/android/permission/cts/),\n [NotificationManagerTest.java](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/tests/notification/src/android/app/notification/current/cts/NotificationManagerTest.java?q=NotificationManagerTest.java),\n and [cts/tests/tests/notificationlegacy/](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/tests/notificationlegacy/)."]]