فلاتر الأهداف والنية

Intent هو عنصر مراسلة يمكنك استخدامه لطلب إجراء من مكوّن تطبيق آخر. على الرغم من أن الأهداف تسهل التواصل بين المكونات بعدة طرق، إلا أن هناك ثلاثة تشمل حالات الاستخدام الأساسية التالية:

  • بدء نشاط

    تمثّل السمة Activity شاشة واحدة في تطبيق. يمكنك بدء حساب جديد مثال لـ Activity من خلال تمرير Intent إلى startActivity(). Intent يصف النشاط للبدء ويحمل أي بيانات ضرورية.

    إذا كنت تريد الحصول على نتيجة من النشاط عند الانتهاء، الاتصال بخدمة startActivityForResult() يتلقّى نشاطك النتيجة باعتباره عنصر Intent منفصل في استدعاء onActivityResult() لنشاطك. لمزيد من المعلومات، اطّلِع على دليل الأنشطة.

  • بدء خدمة

    Service هو مكوّن ينفّذ العمليات في الخلفية بدون واجهة مستخدم. باستخدام الإصدار Android 5.0 (المستوى 21 من واجهة برمجة التطبيقات) والإصدارات الأحدث، يمكنك بدء خدمة مع JobScheduler. لمزيد من المعلومات حول JobScheduler، راجع API-reference documentation

    بالنسبة إلى الإصدارات الأقدم من Android 5.0 (المستوى 21 لواجهة برمجة التطبيقات)، يمكنك بدء خدمة باستخدام لفئة Service. يمكنك بدء خدمة لتنفيذ عملية لمرة واحدة (مثل تنزيل ملف) من خلال تمرير Intent إلى startService(). Intent يصف الخدمة للبدء ويحمل أي بيانات ضرورية.

    إذا تم تصميم الخدمة باستخدام واجهة خادم عميل، يمكنك الربط بالخدمة من مكوّن آخر عن طريق تمرير Intent إلى bindService(). لمزيد من المعلومات، يُرجى الاطّلاع على دليل الخدمات.

  • إرسال بث

    البث هو رسالة يمكن أن يتلقاها أي تطبيق. يُرسِل النظام محتوًى مختلفًا للبثّ لأحداث النظام، مثل بدء تشغيل النظام أو بدء شحن الجهاز. يمكنك إرسال بث إلى تطبيقات أخرى من خلال ضبط Intent. إلى sendBroadcast() أو sendOrderedBroadcast()

توضّح هذه الصفحة آلية عمل الأهداف وكيفية استخدامها. للحصول على معلومات ذات صلة، يُرجى مراجعة التفاعل مع التطبيقات الأخرى ومشاركة المحتوى

أنواع الأهداف

هناك نوعان من النوايا:

  • الأهداف الصريحة تحدد مكوّن التطبيق الذي سيفي بالغرض، من خلال تحديد ComponentName كامل. وسوف هدفًا صريحًا لبدء مكون في تطبيقك الخاص، لأنك تعرف اسم فئة النشاط أو الخدمة التي تريد بدئها. بالنسبة على سبيل المثال، قد تبدأ نشاطًا جديدًا داخل تطبيقك استجابةً لإجراء المستخدم، أو تبدأ خدمة لتنزيل ملف في الخلفية.
  • لا تذكر الأهداف الضمنية مكوّنًا معيّنًا، ولكنها تعلن بدلاً من ذلك عن إجراء عام. تنفيذها، وهو ما يسمح لمكون من تطبيق آخر بمعالجتها. على سبيل المثال، إذا كنت تريد تعرض للمستخدم موقعًا ما على الخريطة، فيمكنك استخدام نية ضمنية لطلب الحصول على إذن يعرض التطبيق موقعًا جغرافيًا محددًا على الخريطة.

يوضح الشكل 1 كيفية استخدام هدف عند بدء نشاط. عندما يقوم الكائن Intent بتسمية مكون نشاط معين بشكل صريح، ويسمي النظام على الفور بهذا المكون.

الشكل 1. كيف يكون الغرض الضمني تسليمه من خلال النظام لبدء نشاط آخر: [1] يُنشئ النشاط أ Intent يتضمن وصف الإجراء ويمرره إلى startActivity() [2] يبحث نظام Android في جميع التطبيقات لفلتر أهداف يتطابق مع الهدف. وعند العثور على مطابقة، [3] يبدأ النشاط المطابق (النشاط ب) باستدعاء طريقة onCreate() وتمريره Intent.

عند استخدام نية ضمنية، يعثر نظام Android على المكوّن المناسب لبدء التطبيق من خلال مقارنة محتوى النية بفلاتر الأهداف المُعلَن عنها في ملف البيان للتطبيقات الأخرى على الجهاز. إذا تطابق الهدف مع فلتر أهداف، يبدأ النظام هذا المكوِّن ويعرضها. كائن Intent. في حال توافق فلاتر الأهداف المتعددة، سيجري النظام عرض مربع حوار حتى يتمكن المستخدم من اختيار التطبيق الذي يريد استخدامه.

فلتر الأهداف هو تعبير في ملف بيان التطبيق يحدد نوع الأهداف التي يريد المكوّن تلقّيها. على سبيل المثال، من خلال الإعلان عن فلتر أهداف لنشاط معيّن، يمكنك السماح للتطبيقات الأخرى ببدء نشاطك مباشرةً باستخدام نوع معيّن من الأهداف. وبالمثل، في حال لم تُعلن عن أي فلاتر أهداف لنشاط معيّن، يمكن عندئذٍ بدئه. بنيّة صريحة فقط

تحذير: لضمان أمان تطبيقك، يجب استخدام Service صريح دائمًا عند بدء Service وعدم تحديد فلاتر Service لخدماتك. يشكّل استخدام نية ضمنية لبدء خدمة خطرًا على الأمن لأنّه لا يمكنك التأكّد من الخدمة التي ستستجيب للنية، ولا يمكن للمستخدم معرفة الخدمة التي يتم بدء تشغيلها. بدءًا من Android 5.0 (مستوى واجهة برمجة التطبيقات 21)، سيركز تطرح استثناء إذا طلبت bindService() بهدف ضمني.

بناء هدف

يحتوي عنصر Intent على معلومات يستخدمها نظام Android. لتحديد المكون الذي سيتم البدء فيه (مثل اسم المكون أو المكون بالضبط فئة يجب أن تتلقى intent)، بالإضافة إلى المعلومات التي يستخدمها مكون المستلم في من أجل تنفيذ الإجراء بشكل صحيح (مثل الإجراء المطلوب اتخاذه والبيانات التي يجب التصرف بناءً عليها).

المعلومات الأساسية التي يتضمّنها Intent هي ما يلي:

اسم المكوِّن
اسم المكوِّن المطلوب البدء.

هذه خطوة اختيارية، ولكنها المعلومة الحاسمة التي تصنع نية فاضحة، ما يعني أنّ نية الشراء يجب تسليمها إلى مكوّن التطبيق فقط. المحددة بواسطة اسم المكون. وبدون اسم المكوِّن، يكون الغرض ضمنيًا يقرر المكون الذي يجب أن يتلقى الغرض بناءً على معلومات النية الأخرى (مثل الإجراء والبيانات والفئة - كما هو موضَّح أدناه). إذا كنت بحاجة إلى بدء مخطط في تطبيقك، فيجب تحديد اسم المكوِّن.

ملاحظة: عند بدء تشغيل Service، حدِّد دائمًا اسم المكوِّن. وبخلاف ذلك، لا يمكنك التأكد من الخدمة وسوف يستجيب للغرض، ولا يمكن للمستخدم معرفة أي خدمة تبدأ.

هذا الحقل من Intent عبارة عن ComponentName، الذي يمكنك تحديده باستخدام اسم الفئة المؤهلة للمكون المستهدف، بما في ذلك اسم حزمة التطبيق، على سبيل المثال، com.example.ExampleActivity يمكنك ضبط اسم المكوِّن باستخدام setComponent() أو setClass() أو setClassName() أو أو باستخدام الدالة الإنشائية Intent.

الإجراء
سلسلة تحدد الإجراء العام المطلوب تنفيذه (مثل عرض أو اختيار).

في ما يتعلق بالغرض من البث، هذا هو الإجراء الذي تم إجراؤه والذي يتم الإبلاغ عنه. يحدد الإجراء إلى حد كبير كيفية تنظيم بقية الهدف، خاصةً المعلومات الموجودة في البيانات والإضافات.

يمكنك تحديد إجراءاتك الخاصة لكي يتم استخدامها حسب الأهداف داخل تطبيقك (أو لاستخدامها من قِبل مستخدمين آخرين). التطبيقات لاستدعاء المكونات في تطبيقك)، ولكنك عادةً ما تحدد ثوابت الإجراء محدّدة في فئة Intent أو فئات إطار عمل أخرى. إليك بعض الأمثلة الإجراءات الشائعة لبدء نشاط وهي:

ACTION_VIEW
استخدِم هذا الإجراء في مقصد لـ startActivity() عندما يكون لديك بعض المعلومات التي نشاط يمكن أن يظهر للمستخدم، مثل صورة لعرضها في تطبيق معرض الصور أو عنوان لعرضها في تطبيق الخرائط
ACTION_SEND
يُعرف أيضًا باسم نية المشاركة، ويجب استخدام هذا الغرض في startActivity()، عندما يكون لديك بعض البيانات التي يمكن للمستخدم استخدامها. مشاركتها من خلال تطبيق آخر، مثل تطبيق البريد الإلكتروني أو تطبيق المشاركة على وسائل التواصل الاجتماعي

اطّلِع على مرجع فئة Intent لمعرفة المزيد. الثوابت التي تحدد الإجراءات العامة. تم تحديد إجراءات أخرى مكان آخر في إطار عمل Android، مثل Settings لتنفيذ الإجراءات تفتح شاشات محدّدة في تطبيق "الإعدادات" على النظام.

ويمكنك تحديد الإجراء لغرض في setAction() أو باستخدام دالة إنشاء Intent.

إذا حدّدت إجراءاتك الخاصة، تأكَّد من تضمين اسم حزمة تطبيقك. كبادئة، كما هو موضح في المثال التالي:

Kotlin

const val ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL"

Java

static final String ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL";
البيانات
معرّف الموارد المنتظم (URI) (عنصر Uri) الذي يشير إلى البيانات التي سيتم اتخاذ إجراء بشأنها و/أو نوع MIME لهذه البيانات. ويعتمد نوع البيانات المقدَّمة بشكل عام على إجراء الغرض. بالنسبة على سبيل المثال، إذا كان الإجراء ACTION_EDIT، يجب أن تحتوي البيانات على السمة معرّف الموارد المنتظم (URI) للمستند المطلوب تعديله.

عند إنشاء نية، من المهم غالبًا تحديد نوع البيانات (نوع MIME) بالإضافة إلى معرّف الموارد المنتظم (URI). على سبيل المثال، قد لا يتمكن أي نشاط يمكنه عرض الصور لتشغيل ملف صوتي، على الرغم من أن تنسيقات معرف الموارد المنتظم (URI) قد تكون متشابهة. يساعد تحديد نوع MIME لبياناتك نظام Android أفضل مكون للحصول على هدفك. ومع ذلك، يمكن أحيانًا استنتاج نوع MIME من معرّف الموارد المنتظم (URI) - خاصةً عندما تكون البيانات معرّف الموارد المنتظم (URI) content: يشير معرّف الموارد المنتظم (URI) content: إلى أنّ البيانات متوفّرة على الجهاز. والتحكم فيه من قِبل ContentProvider، ما يجعل البيانات من نوع MIME مرئية للنظام.

لضبط عنوان URI للبيانات فقط، اتصل بالرقم setData(). لضبط نوع MIME فقط، يمكنك طلب setType(). إذا لزم الأمر، يمكنك ضبط كليهما بشكل صريح باستخدام setDataAndType().

تنبيه: إذا كنت تريد ضبط كل من معرّف الموارد المنتظم (URI) ونوع MIME، عدم الاتصال بـ setData() setType() لأن كل منهما يؤدي إلى إبطال قيمة الآخر. استخدام setDataAndType() دائمًا لضبط كليهما معرّف الموارد المنتظم (URI) ونوع MIME

الفئة
سلسلة تحتوي على معلومات إضافية عن نوع المكوِّن التي ينبغي أن تتعامل مع الهدف. يمكن أن يكون أي عدد من أوصاف الفئات موضوعة في هدف، ولكن معظم الأهداف لا تتطلب فئة. في ما يلي بعض الفئات الشائعة:
CATEGORY_BROWSABLE
يسمح النشاط الهدف ببدء تشغيله بواسطة متصفح ويب لعرض البيانات المشار إليها بواسطة رابط، مثل صورة أو رسالة بريد إلكتروني.
CATEGORY_LAUNCHER
النشاط هو النشاط الأولي لمهمة ما ويتم إدراجه في مشغِّل تطبيقات النظام.

راجِع وصف الصف Intent للحصول على القائمة الكاملة الفئات.

يمكنك تحديد فئة باستخدام addCategory().

تمثل هذه الخصائص المدرجة أعلاه (اسم المكون والإجراء والبيانات والفئة) تحديد خصائص النية. ومن خلال قراءة هذه الخصائص، فإن نظام Android يكون قادرًا على تحديد مكون التطبيق الذي يجب أن يبدأ. ومع ذلك، يمكن أن يحمل النية معلومات إضافية لا تؤثر وكيف يتم حلها إلى مكون التطبيق. يمكن أن يقدم الغرض أيضًا المعلومات التالية:

الإضافات
أزواج المفتاح/القيمة التي تتضمّن المعلومات الإضافية المطلوبة لإنجازها الإجراء المطلوب. تمامًا كما تستخدم بعض الإجراءات أنواعًا معيّنة من عناوين URL للبيانات، تستخدم بعض الإجراءات أيضًا عناصر إضافية معيّنة.

يمكنك إضافة بيانات إضافية باستخدام طرق putExtra() مختلفة، تقبل كل منهما معلمتين وهما: اسم المفتاح والقيمة. يمكنك أيضًا إنشاء عنصر Bundle يتضمّن كل البيانات الإضافية، ثم إدراج Bundle في Intent باستخدام putExtras().

على سبيل المثال، عند إنشاء نية لإرسال رسالة بريد إلكتروني تحتوي ACTION_SEND، يمكنك تحديد مستلم إلى من خلال EXTRA_EMAIL، وحدد الموضوع المفتاح EXTRA_SUBJECT:

تحدّد فئة Intent العديد من الثوابت EXTRA_* لأنواع البيانات الموحدة. إذا كنت بحاجة إلى الإفصاح عن مفاتيح إضافية خاصة بك (للنوايا التي يتلقّاها تطبيقك)، احرص على تضمين اسم حزمة تطبيقك كبادئة، كما هو موضّح في المثال التالي:

Kotlin

const val EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS"

Java

static final String EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS";

تحذير: لا تستخدم Parcelable أو بيانات Serializable عند إرسال هدف تتوقّعه تنزيل تطبيق آخر. إذا كان التطبيق يحاول الوصول إلى البيانات في كائن Bundle ولكنه لا حق الوصول إلى الفئة المقسمة أو المتسلسلة، يرفع النظام RuntimeException

العلامات
يتم تحديد العلامات في الفئة Intent والتي تعمل كبيانات وصفية والنية. قد تُعلم العلامات نظام Android بكيفية بدء نشاط (على سبيل المثال، المهمة يجب أن ينتمي النشاط إليه) وكيفية التعامل معه بعد إطلاقه (على سبيل المثال، ما إذا كان ينتمي إلى قائمة المواقع الإلكترونية الأنشطة).

لمزيد من المعلومات، يُرجى الاطّلاع على طريقة setFlags().

مثال على نية صريحة

الغرض الصريح هو ذلك الذي تستخدمه لتشغيل مكون تطبيق معين، مثل نشاط أو خدمة معيّنة في تطبيقك لإنشاء نية صريحة، حدد اسم المكوِّن للكائن Intent—كل خصائص intent الأخرى اختيارية.

على سبيل المثال، إذا أنشأت خدمة في تطبيقك باسم DownloadService، مصممة لتنزيل ملف من الويب، يمكنك بدؤه بالرمز التالي:

Kotlin

// Executed in an Activity, so 'this' is the Context
// The fileUrl is a string URL, such as "http://www.example.com/image.png"
val downloadIntent = Intent(this, DownloadService::class.java).apply {
    data = Uri.parse(fileUrl)
}
startService(downloadIntent)

Java

// Executed in an Activity, so 'this' is the Context
// The fileUrl is a string URL, such as "http://www.example.com/image.png"
Intent downloadIntent = new Intent(this, DownloadService.class);
downloadIntent.setData(Uri.parse(fileUrl));
startService(downloadIntent);

Intent(Context, Class) توفر الدالة الإنشائية التطبيق Context كائن Class. وبناءً على ذلك، يبدأ هذا القصد صراحةً فئة DownloadService في التطبيق.

لمزيد من المعلومات حول إنشاء خدمة وبدء تشغيلها، يمكنك الاطلاع على دليل الخدمات.

مثال على هدف ضمني

يحدد الغرض الضمني إجراءً يمكنه استدعاء أي تطبيق على الجهاز يمكنه لتنفيذ الإجراء. يكون استخدام هدف ضمني مفيدًا عندما يتعذّر على التطبيق تنفيذ الإجراء، ولكن ربما يمكن للتطبيقات الأخرى أن يختار المستخدم التطبيق الذي يريد استخدامه.

على سبيل المثال، إذا كان لديك محتوى تريد أن يشاركه المستخدم مع أشخاص آخرين، أنشِئ هدفًا مع إجراء ACTION_SEND وتضيف ميزات إضافية تحدد المحتوى الذي تريد مشاركته. عند الاتصال startActivity() بهذا الغرض، يمكن للمستخدم اختيار تطبيق لمشاركة المحتوى من خلاله.

Kotlin

// Create the text message with a string.
val sendIntent = Intent().apply {
    action = Intent.ACTION_SEND
    putExtra(Intent.EXTRA_TEXT, textMessage)
    type = "text/plain"
}

// Try to invoke the intent.
try {
    startActivity(sendIntent)
} catch (e: ActivityNotFoundException) {
    // Define what your app should do if no activity can handle the intent.
}

Java

// Create the text message with a string.
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);
sendIntent.setType("text/plain");

// Try to invoke the intent.
try {
    startActivity(sendIntent);
} catch (ActivityNotFoundException e) {
    // Define what your app should do if no activity can handle the intent.
}

عند استدعاء الدالة startActivity()، يستخدم النظام جميع التطبيقات المثبتة لتحديد التطبيقات التي يمكنها التعامل مع هذا النوع من الأهداف ( نية في الإجراء ACTION_SEND والتي تتضمن "نص/عادي" البيانات). إذا لم يكن هناك سوى تطبيق واحد يمكنه التعامل مع هذه العملية، فسيتم فتح هذا التطبيق على الفور وسيتم منحه والنية. إذا لم تتمكن أي تطبيقات أخرى من التعامل مع هذا الإجراء، يمكن لتطبيقك التقاط ActivityNotFoundException التي تحدث. إذا كانت هناك أنشطة متعددة تقبل الغرض، سيجري النظام لعرض مربع حوار مثل الذي يظهر في الشكل 2، حتى يتمكن المستخدم من اختيار التطبيق المراد استخدامه.

يتم أيضًا توفير مزيد من المعلومات حول إطلاق تطبيقات أخرى في الدليل. حول إرسال المستخدم إلى لتطبيق آخر.

الشكل 2: مربع حوار أداة الاختيار.

فرض أداة اختيار التطبيقات

عندما يستجيب أكثر من تطبيق واحد لهدفك الضمني، يمكن للمستخدم اختيار التطبيق الذي يريد استخدامه وجعله هو الخيار التلقائي اتخاذ القرار. تُعد القدرة على تحديد خيار افتراضي مفيدة عند تنفيذ إجراء يريد المستخدم من أجله ربما يريد استخدام التطبيق نفسه في كل مرة، على سبيل المثال عند فتح صفحة ويب (المستخدمون يفضلون غالبًا متصفح ويب واحدًا فقط).

ومع ذلك، إذا كان بإمكان تطبيقات متعددة الاستجابة للطلب وقد يريد المستخدم استخدام تطبيق مختلف في كل مرة، يجب عرض مربّع حوار اختيار صراحةً. يسأل مربع حوار المُختار المستخدم لتحديد التطبيق الذي يريد استخدامه في الإجراء (لا يمكن للمستخدم اختيار تطبيق تلقائي الإجراء). على سبيل المثال، عندما ينفِّذ تطبيقك "مشاركة" من خلال الإجراء ACTION_SEND، قد يرغب المستخدمون في المشاركة باستخدام تطبيق مختلف، وذلك حسب ما يلي: على الوضع الحالي، لذا يجب عليك دائمًا استخدام مربع حوار المُختار، كما هو موضح في الشكل 2.

لإظهار أداة الاختيار، أنشِئ Intent باستخدام createChooser() ومرِّرها إلى startActivity()، كما هو موضّح في المثال التالي. يعرض هذا المثال مربّع حوار يتضمّن قائمة بالتطبيقات التي تستجيب للهدف الذي تم تمريره إلى طريقة createChooser() وتستخدم النص المقدّم على أنّه عنوان مربع الحوار.

Kotlin

val sendIntent = Intent(Intent.ACTION_SEND)
...

// Always use string resources for UI text.
// This says something like "Share this photo with"
val title: String = resources.getString(R.string.chooser_title)
// Create intent to show the chooser dialog
val chooser: Intent = Intent.createChooser(sendIntent, title)

// Verify the original intent will resolve to at least one activity
if (sendIntent.resolveActivity(packageManager) != null) {
    startActivity(chooser)
}

Java

Intent sendIntent = new Intent(Intent.ACTION_SEND);
...

// Always use string resources for UI text.
// This says something like "Share this photo with"
String title = getResources().getString(R.string.chooser_title);
// Create intent to show the chooser dialog
Intent chooser = Intent.createChooser(sendIntent, title);

// Verify the original intent will resolve to at least one activity
if (sendIntent.resolveActivity(getPackageManager()) != null) {
    startActivity(chooser);
}

رصد عمليات الإطلاق غير الآمنة حسب نية العميل

قد يطلق تطبيقك أهدافًا للتنقل بين المكونات داخل التطبيق، أو تنفيذ إجراء نيابةً عن تطبيق آخر. لتحسين أمان المنصة، يوفّر Android 12 (المستوى 31 لواجهة برمجة التطبيقات) والإصدارات الأحدث ميزة لتصحيح الأخطاء تحذّرك. إذا نفّذ تطبيقك عملية إطلاق غير آمنة لهدف ما. على سبيل المثال، قد تنفيذ إطلاق غير آمن لهدف مدمج، وهو هدف يتم تمريره كعنصر إضافي في هدف آخر.

إذا نفّذ تطبيقك كلا الإجراءين التاليين، يرصد النظام إجراءً غير آمن. إطلاق intent، ومخالفة قواعد StrictMode يحدث:

  1. يفصل تطبيقك عن الغرض المدمج من العناصر الإضافية لهدف تم إرساله.
  2. يبدأ تطبيقك على الفور في تشغيل تطبيق. باستخدام هذا الغرض المتداخل، مثل تمرير النية إلى startActivity(), startService(), أو bindService()

لمزيد من التفاصيل حول كيفية تحديد هذا الموقف وإجراء تغييرات في تطبيقك، الاطّلاع على مشاركة المدونة حول دمج Android النوايا على Medium.

التحقّق من عمليات الإطلاق غير الآمنة حسب نية العميل

للتحقّق من عمليات تشغيل intent غير الآمنة في التطبيق، يُرجى الاتصال detectUnsafeIntentLaunch() عند ضبط VmPolicy، كما هو موضَّح في مقتطف الرمز التالي. إذا رصد تطبيقك انتهاكًا لـ StrictMode، قد تحتاج إلى إيقاف تنفيذ التطبيق للحماية من المعلومات الحسّاسة المحتملة.

Kotlin

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        // Other StrictMode checks that you've previously added.
        // ...
        .detectUnsafeIntentLaunch()
        .penaltyLog()
        // Consider also adding penaltyDeath()
        .build())
}

Java

protected void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
        // Other StrictMode checks that you've previously added.
        // ...
        .detectUnsafeIntentLaunch()
        .penaltyLog()
        // Consider also adding penaltyDeath()
        .build());
}

استخدام الأهداف بمسؤولية أكبر

لتقليل فرصة الإطلاق غير الآمن لهدف ما وانتهاك السياسة، واتباع أفضل الممارسات هذه.

انسخ العناصر الإضافية الأساسية فقط ضمن الأهداف، ونفِّذ أي إجراءات ضرورية والصحة والتحقق من الصحة قد ينسخ تطبيقك الميزات الإضافية من intent إلى نية أخرى تُستخدم لإطلاق مكون جديد. يحدث هذا عندما مكالمات التطبيقات putExtras(Intent) أو putExtras(Bundle) فإذا كان التطبيق يجري إحدى هذه العمليات، فانسخ فقط الميزات الإضافية التي يتوقعه مكون الاستقبال. إذا كان الغرض الآخر (الذي يتلقّى النسخة) يشغّل مكوّنًا لم يتم تصديره، عليك إزالة البيانات غير الصالحة من ملف extras و التحقّق منه قبل نسخه إلى الغرض الذي يشغّل المكوّن.

لا تصدِّر مكوّنات تطبيقك بدون داعٍ. على سبيل المثال، إذا كنت تنوي إطلاق مكوّن تطبيق باستخدام هدف مُدمَج داخلي، اضبط سمة android:exported للمكوّن على false.

استخدِم PendingIntent بدلاً من نية متداخلة. وبهذه الطريقة، عندما يزيل تطبيق آخر PendingIntent من التي تشتمل على Intent، يمكن للتطبيق الآخر تشغيل PendingIntent باستخدام هوية تطبيقك. تسمح هذه الإعدادات للتطبيق الآخر بالتشغيل بأمان. أي مكوّن في تطبيقك، بما في ذلك أي مكوّن لم يتم تصديره.

يوضّح المخطّط البياني في الشكل 2 كيفية نقل النظام التحكّم من تطبيقك (العميل) إلى تطبيق آخر (خدمة)، ثم إعادته إلى تطبيقك:

  1. ينشئ تطبيقك هدفًا يستدعي نشاطًا في تطبيق آخر. ضمن هذا الغرض، تضيف كائن PendingIntent كعنصر إضافي. هذا الطلب في انتظار المراجعة يستدعي مكونًا في تطبيقك؛ لا يتم تصدير هذا المكون.
  2. وعند تلقّي هدف التطبيق، يعمل التطبيق الآخر على استخراج البيانات المدمجة عنصر PendingIntent.
  3. يستدعي التطبيق الآخر الطريقة send() على الكائن PendingIntent.
  4. بعد إعادة عنصر التحكّم إلى تطبيقك، يستدعي النظام الطلب الذي كانت في انتظار المراجعة. نية الشراء باستخدام سياق التطبيق.

الشكل 2. مخطّط بياني للتواصل بين التطبيقات عند استخدام عملية تعليق متداخلة والنية.

تلقّي هدف ضمني

للإعلان عن الأهداف الضمنية التي يمكن أن يتلقّاها تطبيقك، اذكر فلترًا واحدًا أو أكثر من فلاتر الأهداف بالنسبة إلى كل مكوّن من مكوّنات تطبيقك مع <intent-filter> عنصر في ملف البيان. يحدد كل فلتر أهداف نوع الأهداف التي يقبلها بناءً على إجراء intent، والبيانات والفئة. لا يقدِّم النظام هدفًا ضمنيًا لمكوِّن تطبيقك إلا إذا يمكن أن يمرّ intent عبر أحد فلاتر الأهداف.

ملاحظة: دائمًا ما يتمّ تحقيق النية الصريحة في الهدف المحدّد لها. بصرف النظر عن فلاتر الأهداف التي يفصح عنها المكوِّن.

يجب أن يفصح مكوّن التطبيق عن فلاتر منفصلة لكل مهمة فريدة يمكنه تنفيذها. على سبيل المثال، قد يحتوي نشاط واحد في تطبيق معرض الصور على فلترَين: فلتر واحد. لعرض الصورة، وفلتر آخر لتعديل الصورة. عندما يبدأ النشاط، يفحص "Intent" ويقرِّر كيفية التصرف بناءً على المعلومات المطلوبة في Intent (مثل عرض عناصر تحكُّم المحرِّر أو عدم عرضها)

يتم تحديد كل فلتر أهداف من خلال <intent-filter> عنصر في ملف بيان التطبيق، ويكون مدمجًا في مكون التطبيق المقابل (على سبيل المثال بصفتك <activity> العنصر).

في كل مكون تطبيق يتضمن عنصر <intent-filter>، قم بتعيين قيمة android:exported تشير هذه السمة إلى ما إذا كان يمكن للتطبيقات الأخرى الوصول إلى مكوِّن التطبيق. في بعض مثل الأنشطة التي تتضمن فلاتر الأهداف LAUNCHER الفئة، من المفيد تعيين هذه السمة على true. وإلا، فمن الآمن ضبط هذه السمة على false.

تحذير: إذا كان هناك نشاط أو خدمة أو بث يستخدم المستلِم في تطبيقك فلاتر الأهداف ولا يُحدِّد القيمة بشكلٍ صريح بالنسبة إلى android:exported، لا يمكن تثبيت تطبيقك على جهاز يعمل بنظام التشغيل Android 12 أو إصدار أحدث.

داخل <intent-filter>، يمكنك تحديد نوع النوايا التي تريد قبولها باستخدام واحد أو أكثر من هذه العناصر الثلاثة:

<action>
يوضح إجراء الهدف المقبول في السمة name. القيمة أن يكون قيمة السلسلة الحرفية لإجراء ما، وليس ثابت الفئة.
<data>
تعريف نوع البيانات المقبولة باستخدام سمة واحدة أو أكثر من السمات التي تحدد المتعلقة بمعرّف الموارد المنتظم (URI) للبيانات (scheme، وhost، وport، path) ونوع MIME.
<category>
يُعلن عن قبول فئة الغرض في سمة name. القيمة يجب أن يكون قيمة السلسلة الحرفية لأحد الإجراءات، وليس ثابت الفئة.

ملاحظة: لتلقّي أغراض ضمنية، يجب إجراء ما يلي: يجب أن يتضمن الفئة CATEGORY_DEFAULT في فلتر الأهداف. الطرق startActivity() و تتعامل startActivityForResult() مع كل الأهداف كما لو كانوا قد أعلنوا عن الفئة CATEGORY_DEFAULT. في حال عدم تعريف هذه الفئة في فلتر الأهداف، لن يتم حلّ أي نوايا ضمنية إلى نشاطك.

على سبيل المثال، في ما يلي بيان نشاط يتضمّن فلتر نية لتلقّي نية ACTION_SEND عندما يكون نوع البيانات نصًا:

<activity android:name="ShareActivity" android:exported="false">
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
</activity>

يمكنك إنشاء فلتر يتضمن أكثر من مثيل واحد <action>، <data> <category> وفي هذه الحالة، يجب التأكّد من أنّ المكوّن يمكنه التعامل مع أي تركيبة من عناصر الفلترة.

عندما تريد التعامل مع أنواع متعددة من الأهداف، ولكن فقط في مجموعات محددة من الإجراء والبيانات ونوع الفئة، فستحتاج إلى إنشاء فلاتر أهداف متعددة.

يتم اختبار هدف ضمني مقابل فلتر من خلال مقارنة الغرض من كل نوع ثلاثة عناصر. ليتم تسليمه إلى المكوِّن، يجب أن يجتاز الغرض جميع الاختبارات الثلاثة. فإذا لم يتطابق مع أي منها، لن يتمكن نظام Android من تسليم هدف المكون. ومع ذلك، ونظرًا لأن أحد المكونات قد يحتوي على فلاتر أهداف متعددة، فإن الغرض من ذلك عدم المرور عبر أحد فلاتر المكون قد ينجح في عامل تصفية آخر. يمكنك الاطّلاع على مزيد من المعلومات حول الطريقة التي يتّبعها النظام لحلّ الأهداف في القسم أدناه. حول تحليل الأهداف.

تحذير: لا يُعدّ استخدام فلتر الأهداف طريقة آمنة لمنع التطبيقات الأخرى من بدء مكوناتك. على الرغم من أنّ فلاتر الأهداف تحظر مكوّنًا معيّنًا للاستجابة إلى أنواعًا معيّنة من الأهداف الضمنية، قد يبدأ تطبيق آخر في تشغيل مكوّن تطبيقك باستخدام نية واضحة إذا حدَّد مطوّر البرامج أسماء المكوّنات. إذا كان من المهم أن يتمكّن تطبيقك فقط من بدء أحد مكوّناتك، يجب عدم الإفصاح عن فلاتر الأهداف في البيان. بدلاً من ذلك، اضبط سمة exported على "false" لهذا المكوّن.

وبالمثل، لتجنب تشغيل تطبيق مختلف عن غير قصد Service، يُرجى دائمًا استخدام نية صريحة لبدء الخدمة الخاصة بك.

ملاحظة: بالنسبة إلى جميع الأنشطة، يجب الإفصاح عن فلاتر الأهداف في ملف البيان. ومع ذلك، يمكن تسجيل فلاتر لأجهزة استقبال البث ديناميكيًا من خلال الاتصال بـ registerReceiver(). يمكنك بعد ذلك إلغاء تسجيل المُستلِم في "unregisterReceiver()". يؤدي ذلك إلى السماح لتطبيقك للاستماع إلى رسائل بث محدّدة خلال فترة زمنية محدّدة فقط أثناء استخدام تطبيقك قيد التشغيل.

أمثلة على الفلاتر

لتوضيح بعض سلوكيات فلاتر الأهداف، إليك مثال من ملف البيان الخاص بتطبيق مشاركة على الشبكات الاجتماعية:

<activity android:name="MainActivity" android:exported="true">
    <!-- This activity is the main entry, should appear in app launcher -->
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

<activity android:name="ShareActivity" android:exported="false">
    <!-- This activity handles "SEND" actions with text data -->
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
    <!-- This activity also handles "SEND" and "SEND_MULTIPLE" with media data -->
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <action android:name="android.intent.action.SEND_MULTIPLE"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="application/vnd.google.panorama360+jpg"/>
        <data android:mimeType="image/*"/>
        <data android:mimeType="video/*"/>
    </intent-filter>
</activity>

النشاط الأول، MainActivity، هو نقطة الدخول الرئيسية للتطبيق - النشاط الذي عندما يشغِّل المستخدم التطبيق للمرة الأولى الذي يحمل رمز مشغّل التطبيقات:

  • الإجراء ACTION_MAIN تشير إلى أن هذه هي نقطة الدخول الرئيسية ولا تتوقع أي بيانات نية.
  • تشير الفئة CATEGORY_LAUNCHER إلى أن هذا النشاط في مشغّل تطبيقات النظام. إذا كان العنصر <activity> في تحديد رمز من خلال icon، فسيستخدم النظام الرمز من واجهة برمجة التطبيقات <application> العنصر.

يجب إقران هذين العنصرَين معًا لكي يظهر النشاط في مشغّل التطبيقات.

يهدف النشاط الثاني، ShareActivity، إلى تسهيل مشاركة النصوص والوسائط. المحتوى. رغم أنّ المستخدمين قد يدخلون هذا النشاط من خلال الانتقال إليه من MainActivity، يمكنه أيضًا الدخول إلى ShareActivity مباشرةً من تطبيق آخر يصدر رسالة إلكترونية أهداف تتطابق مع أحد فلترَي الأهداف.

ملاحظة: يتم اعتبار نوع MIME application/vnd.google.panorama360+jpg، هو نوع بيانات خاص يحدد من الصور البانورامية، والتي يمكنك التعامل معها باستخدام عدسة Google واجهات برمجة تطبيقات بانوراما.

مطابقة الأهداف مع التطبيقات الأخرى فلاتر الأهداف

إذا كان تطبيق آخر يستهدف Android 13 (المستوى 33 لواجهة برمجة التطبيقات) أو إصدارًا أحدث، يمكنه التعامل مع الغرض من التطبيق فقط إذا تطابق هدفك مع إجراءات وفئات العنصر <intent-filter> في ذلك التطبيق الآخر. وإذا لم يعثر النظام على تطابق، تطرح ActivityNotFoundException يجب أن يتعامل تطبيق الإرسال مع بهذا الاستثناء.

وبالمثل، عند تحديث تطبيقك بحيث يستهدف Android 13 أو أعلى، يتم تسليم جميع الأهداف الناشئة من تطبيقات خارجية إلى الذي تم تصديره من تطبيقك فقط إذا تطابق هذا الغرض مع الإجراءات فئات عنصر <intent-filter> التي يفصح عنها تطبيقك. هذا السلوك بغض النظر عن إصدار حزمة تطوير البرامج (SDK) المستهدَف للتطبيق المُرسَل.

في الحالات التالية، لا يتم فرض مطابقة الأهداف:

  • الأهداف التي يتم إرسالها إلى المكوّنات التي لا تشير إلى أي فلاتر أهداف.
  • الأهداف التي تنشأ من داخل التطبيق نفسه
  • الأهداف التي تنشأ من النظام أي الأهداف التي يتم إرسالها من "المعرّف الفريد للنظام" (uid=1000). تشمل تطبيقات النظام system_server والتطبيقات التي تضبط android:sharedUserId على android.uid.system.
  • النوايا التي تنشأ من الجذر.

اطّلِع على مزيد من المعلومات عن مطابقة الرغبة في الشراء.

استخدام هدف في انتظار المراجعة

الكائن PendingIntent هو التفاف حول كائن Intent. الغرض الأساسي من PendingIntent هو منح إذن لتطبيق أجنبي لاستخدام Intent المتضمّنة كما لو تم تنفيذها من عملية التطبيق الخاصة.

تشمل حالات الاستخدام الرئيسية للنوايا المعلّقة ما يلي:

  • الإعلان عن نية للتنفيذ عندما يتّخذ المستخدم إجراءً من خلال الإشعار (NotificationManager الخاص بنظام Android لتنفيذ Intent).
  • الإعلان عن نية التنفيذ عندما يتخذ المستخدم إجراءً من خلال أداة التطبيق (ينفِّذ تطبيق "الشاشة الرئيسية" علامة Intent).
  • إعلان نية التنفيذ في وقت محدّد في المستقبل (نظام التشغيل ينفذ AlarmManager في النظام Intent).

وتمامًا كما تم تصميم كل عنصر من عناصر Intent للتعامل معه من خلال مجموعة محدّدة من العناصر نوع مكوِّن التطبيق (إما Activity أو Service أو BroadcastReceiver)، لذا يجب أيضًا أن يكون PendingIntent أنشأناها بنفس الاعتبارات. وعند استخدام هدف في انتظار المراجعة، لا يمكن تنفيذ الغرض باستخدام طلب مثل startActivity(). بدلاً من ذلك، عليك تحديد نوع المكوّن المقصود عند إنشاء PendingIntent من خلال استدعاء طريقة الإنشاء ذات الصلة:

ما لم يكن تطبيقك يتلقّى الأهداف المعلّقة من تطبيقات أخرى من المحتمل أن تكون الطرق أعلاه لإنشاء PendingIntent هي الوحيدة ستحتاج إلى PendingIntent طريقة.

تأخذ كل طريقة التطبيق الحالي Context، علامة Intent التي تريد التفافها، وعلامة واحدة أو أكثر تحدد طريقة استخدام الغرض (مثلاً، تحديد ما إذا كان بالإمكان استخدام الغرض أكثر من مرة)

لمزيد من المعلومات عن استخدام الأهداف التي في انتظار المراجعة، اطّلِع على المستندات لكلّ من حالات الاستخدام المعنية، كما هو الحال في الإشعارات والتطبيقات المصغّرة للتطبيقات.

تحديد قابلية التغيّر

إذا كان تطبيقك يستهدف الإصدار 12 من نظام التشغيل Android أو إصدارًا أحدث، عليك تحديد قابلية التغيّر لكل عناصر PendingIntent ينشئها تطبيقك للإقرار بأنّ كائن PendingIntent محدد قابل للتغيير أو غير قابل للتغيير، استخدم PendingIntent.FLAG_MUTABLE أو PendingIntent.FLAG_IMMUTABLE على التوالي.

إذا حاول تطبيقك إنشاء عنصر PendingIntent بدون تعيين أيٍ من علامات قابلية التغيّر، يعرض النظام IllegalArgumentException، ستظهر الرسالة التالية في Logcat:

PACKAGE_NAME: Targeting S+ (version 31 and above) requires that one of \
FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.

Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if \
some functionality depends on the PendingIntent being mutable, e.g. if \
it needs to be used with inline replies or bubbles.

إنشاء أهداف في انتظار المراجعة غير قابلة للتغيير متى أمكن

في معظم الحالات، يجب أن ينشئ تطبيقك عناصر PendingIntent غير قابلة للتغيير، على النحو التالي: كما هو موضح في مقتطف الرمز التالي. إذا كان عنصر PendingIntent غير قابل للتغيير، لا يمكن للتطبيقات الأخرى تعديل النية لتعديل نتيجة استدعاء النية.

Kotlin

val pendingIntent = PendingIntent.getActivity(applicationContext,
        REQUEST_CODE, intent,
        /* flags */ PendingIntent.FLAG_IMMUTABLE)

Java

PendingIntent pendingIntent = PendingIntent.getActivity(getApplicationContext(),
        REQUEST_CODE, intent,
        /* flags */ PendingIntent.FLAG_IMMUTABLE);

ومع ذلك، تتطلّب بعض حالات الاستخدام عناصر PendingIntent قابلة للتغيّر بدلاً من ذلك:

  • إتاحة إجراءات الرد المباشر في الإشعارات تشير رسالة الأشكال البيانية يجب إدخال تغيير على بيانات المقطع في الكائن PendingIntent المرتبط بالرد. عادةً، تطلب هذا التغيير من خلال تمرير FILL_IN_CLIP_DATA كعلم إلى fillIn() .
  • ربط الإشعارات بإطار عمل Android Auto باستخدام مثيلات CarAppExtender
  • وضع المحادثات في فقاعات تفسيرية باستخدام المثيلات من أصل PendingIntent. يسمح كائن PendingIntent القابل للتغيير للنظام بتطبيق العلامات الصحيحة، مثل FLAG_ACTIVITY_MULTIPLE_TASK أو FLAG_ACTIVITY_NEW_DOCUMENT
  • جارٍ طلب معلومات الموقع الجغرافي للجهاز من خلال الاتصال requestLocationUpdates() أو واجهات برمجة تطبيقات مشابهة يسمح كائن PendingIntent القابل للتغيير للنظام بإضافة إضافات الأهداف التي تمثّل أحداث مراحل نشاط الموقع الجغرافي. تتضمن هذه الأحداث التغيير في الموقع الجغرافي وسيصبح مقدّم الخدمة متاحًا.
  • جدولة المنبّهات باستخدام AlarmManager. يسمح عنصر PendingIntent القابل للتغيير للنظام بإضافة EXTRA_ALARM_COUNT intent extra. تمثل هذه القيمة الإضافية عدد المرات التي يظهر فيها منبّه متكرر تم تحفيزه. ومن خلال تضمين هذه المعلومات الإضافية، يمكن للIntent إبلاغ التطبيق بدقة بشأن ما إذا تم تشغيل تنبيه متكرر عدة مرات، مثلاً عندما كان الجهاز في وضع السكون.

إذا أنشأ تطبيقك عنصر PendingIntent قابل للتغيّر، ننصحك بشدة باستخدام استخدام هدف صريح وملء ComponentName بهذه الطريقة، كلما شغّل تطبيق آخر PendingIntent ونقل التحكّم مرة أخرى إلى تطبيقك، يبدأ المكوّن نفسه في تطبيقك دائمًا.

استخدام النوايا الصريحة ضمن النوايا التي في انتظار المراجعة

لتحديد الطريقة التي يمكن بها للتطبيقات الأخرى استخدام أغراضها التي في انتظار المراجعة، يُرجى دائمًا إحاطة هدف في انتظار المراجعة بنيّة صريحة للمساعدة في اتّباع أفضل الممارسات هذه، اتّبِع الخطوات التالية:

  1. تحقَّق من أنّ حقول الإجراء والحزمة والمكوِّن خاصة بالهدف الأساسي تحديدها.

  2. يمكنك استخدام FLAG_IMMUTABLE التي تمت إضافتها في Android 6.0 (المستوى 23 من واجهة برمجة التطبيقات) لإنشاء أهداف في انتظار المراجعة. هذه العلامة لمنع التطبيقات التي تتلقّى الرمز PendingIntent من الملء السمات غير المعبأة. إذا كان minSdkVersion لتطبيقك: 22 أو أقل، يمكنك توفير الأمان والتوافق معًا باستخدام التعليمة البرمجية التالية:

    if (Build.VERSION.SDK_INT >= 23) {
  // Create a PendingIntent using FLAG_IMMUTABLE.
} else {
  // Existing code that creates a PendingIntent.
}

دقة النية بالشراء

عندما يتلقى النظام نية ضمنية لبدء نشاط ما، فإنه يبحث عن أفضل نشاط للهدف من خلال مقارنته بفلاتر الأهداف بناءً على ثلاثة جوانب:

  • الإجراء
  • البيانات (كل من معرّف الموارد المنتظم (URI) ونوع البيانات)
  • الفئة.

توضّح الأقسام التالية كيفية مطابقة الأهداف مع المكوّنات المناسبة، وذلك تبعًا لبيان فلتر الأهداف في ملف بيان التطبيق.

اختبار الإجراء

لتحديد إجراءات النية المقبولة، يمكن لفلتر الأهداف الإعلان عن صفر أو أكثر <action>، كما هو موضّح في المثال التالي:

<intent-filter>
    <action android:name="android.intent.action.EDIT" />
    <action android:name="android.intent.action.VIEW" />
    ...
</intent-filter>

لاجتياز هذا الفلتر، يكون الإجراء المحدّد في Intent يجب أن يتطابق مع أحد الإجراءات المدرَجة في الفلتر.

إذا لم يُدرِج الفلتر أي إجراءات، لن يتطابق أي قصد، وبالتالي لن يجتاز جميع الأغراض الاختبار. ومع ذلك، إذا كانت Intent لا يحدد أي إجراء، فإنه يجتاز الاختبار طالما أن عامل التصفية يحتوي على إجراء واحد على الأقل.

اختبار الفئة

لتحديد فئات الأهداف المقبولة، يمكن أن يذكر فلتر الأهداف صفرًا أو أكثر <category>، كما هو موضّح في المثال التالي:

<intent-filter>
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    ...
</intent-filter>

لكي تتمكّن من اجتياز اختبار الفئات، يجب أن تكون كل فئة من Intent يجب أن تتطابق مع فئة في الفلتر. العكس ليس ضروريًا، إذ قد يعمل فلتر الأهداف الإعلان عن فئات أكثر من الفئات المحدّدة في Intent لا يزال هناك Intent بطاقات محفوظة. لذلك، لا يكون الغرض من الغرض بدون فئات يجتاز هذا الاختبار دائمًا، بغض النظر عن الفئات المعلنة في الفلتر.

ملاحظة: يطبِّق Android الفئة CATEGORY_DEFAULT تلقائيًا. إلى جميع الأهداف الضمنية التي تم تمريرها إلى startActivity() وstartActivityForResult(). إذا كنت تريد أن يتلقّى نشاطك نوايا ضمنية، يجب أدرِج فئة للموقع الإلكتروني "android.intent.category.DEFAULT" في فلاتر الأهداف، باعتبارها كما هو موضح في مثال <intent-filter> السابق.

اختبار البيانات

لتحديد بيانات الأهداف المقبولة، يمكن لفلتر الأهداف الإعلان عن القيمة صفر أو أكثر <data>، كما هو موضّح في المثال التالي:

<intent-filter>
    <data android:mimeType="video/mpeg" android:scheme="http" ... />
    <data android:mimeType="audio/mpeg" android:scheme="http" ... />
    ...
</intent-filter>

كل <data> تحديد عنوان URI ونوع البيانات (نوع وسائط MIME). يُعد كل جزء من معرف الموارد المنتظم (URI) منفصلاً السمة: scheme، host، port، وpath:

<scheme>://<host>:<port>/<path>

يوضّح المثال التالي القيم المحتملة لهذه السمات:

content://com.example.project:200/folder/subfolder/etc

في معرّف الموارد المنتظم هذا، يكون المخطّط هو content والمضيف هو com.example.project والمنفذ هو 200 والمسار هو folder/subfolder/etc.

كل سمة من هذه السمات اختيارية في العنصر <data>، ولكن هناك تبعيات خطية:

  • في حال عدم تحديد مخطط، يتم تجاهل المضيف.
  • في حال عدم تحديد مضيف، سيتم تجاهل المنفذ.
  • في حال عدم تحديد كل من المخطط والمضيف، سيتم تجاهل المسار.

فعند مقارنة عنوان URI في الغرض بمواصفات معرف موارد منتظم (URI) في أحد الفلاتر، إلا أنه تتم مقارنته فقط بأجزاء عنوان URI المضمّنة في الفلتر. مثلاً:

  • إذا حدّد أحد الفلاتر مخططًا فقط، تتطابق جميع معرّفات الموارد المنتظمة (URI) التي تتضمّن هذا المخطط عامل التصفية.
  • إذا حدّد الفلتر مخطّطًا وهيئة ولكن بدون مسار، تمرّ جميع عناوين URL التي تتضمّن المخطّط والهيئة نفسها من الفلتر بغض النظر عن مساراتها.
  • إذا كان الفلتر يحدد مخططًا ومرجعًا ومسارًا، ستلاحظ أنّ معرفات الموارد المنتظمة (URI) هي التي تستخدم نفس المخطط فقط، وسلطة المسار واجتياز عامل التصفية.

ملاحظة: يمكن أن يحدد مواصفات المسار أن يحتوي على علامة نجمية حرف بدل (*) لطلب تطابق جزئي فقط لاسم المسار.

يقارن اختبار البيانات كلاً من معرّف الموارد المنتظم (URI) ونوع MIME في الغرض بمعرّف الموارد المنتظم (URI) ونوع MIME المحدد في الفلتر. القواعد على النحو التالي:

  1. ينفي الغرض الذي لا يحتوي على معرّف موارد منتظم (URI) أو نوع MIME لاختباره فقط إذا لم يحدد الفلتر أي معرّفات موارد منتظمة (URI) أو أنواع MIME.
  2. غرض يحتوي على معرّف موارد منتظم (URI) ولكن بدون نوع MIME (ليس صريحًا ولا يمكن استنتاجه من URI) يجتاز الاختبار فقط إذا كان عنوان URI يتوافق مع تنسيق معرّف الموارد المنتظم (URI) للفلتر وبالمثل، لا يحدد الفلتر نوع MIME.
  3. يجتاز الغرض الذي يشتمل على نوع MIME ولكن ليس معرّف موارد منتظم (URI) الاختبار فقط إذا كان الفلتر يعرض نوع MIME نفسه ولا يحدد تنسيق معرّف موارد منتظم (URI).
  4. لا يجتاز الإجراء الذي يحتوي على معرّف موارد منتظم ونوع MIME (سواء كان صريحًا أو يمكن الاستدلال عليه من المعرّف) جزء نوع MIME من الاختبار إلا إذا كان هذا النوع يتطابق مع نوع مُدرَج في الفلتر. يجتاز الاختبار جزء معرّف الموارد المنتظم (URI) إما إذا كان معرّف الموارد المنتظم يتطابق مع معرّف موارد منتظم في الفلتر أو إذا كان يحتوي على معرّف موارد منتظم content: أو file: ولم يحدّد الفلتر معرّف موارد منتظمًا. بعبارة أخرى، يُفترض أنّ المكوّن متوافق مع بيانات content: وfile: إذا كانت قائمة الفلتر تتضمّن نوع MIME فقط.

ملاحظة: إذا حدّد الغرض من نوع معرّف الموارد المنتظم (URI) أو نوع MIME، فسيحدّد اختبار البيانات وسيتعذّر تنفيذ الإجراء إذا لم تتوفّر عناصر <data> في <intent-filter>.

تعكس هذه القاعدة الأخيرة، القاعدة (د)، التوقع أن المكونات يمكنها الحصول على بيانات محلية من موفر ملف أو محتوى. وبالتالي، يمكن للفلاتر التي يُجريها إدراج نوع بيانات فقط ولا تحتاج إلى إدراجها بشكل صريح لتسمية المخططَين content: وfile:. يعرض المثال التالي حالة نموذجية يعرض فيها العنصر <data>. يخبر Android أنه يمكن للمكوِّن الحصول على بيانات الصور من المحتوى المستخدم وعرضها: 

<intent-filter>
    <data android:mimeType="image/*" />
    ...
</intent-filter>

إنّ الفلاتر التي تحديد نوع البيانات ولكن ليس عنوان URL هي على الأرجح الأكثر شيوعًا لأنّ معظم البيانات المتاحة يتم توزيعها من قِبل مقدّمي المحتوى.

هناك تكوين شائع آخر وهو عامل تصفية بمخطط ونوع بيانات. بالنسبة مثال: <data> مثل ما يلي يخبر Android أنه يمكن للمكوِّن استرداد بيانات الفيديو من الشبكة لتنفيذ الإجراء: 

<intent-filter>
    <data android:scheme="http" android:mimeType="video/*" />
    ...
</intent-filter>

مطابقة الأهداف

تتم مطابقة الأهداف مع فلاتر الأهداف، ليس فقط لاكتشاف هدف لتنشيطه، وكذلك لاكتشاف شيء ما عن مجموعة المكونات على الجهاز. على سبيل المثال، يملأ تطبيق Home مشغّل التطبيقات. من خلال العثور على جميع الأنشطة باستخدام فلاتر الأهداف التي تحدّد إجراء ACTION_MAIN الفئة CATEGORY_LAUNCHER. لا تنجح المطابقة إلا إذا كانت الإجراءات والفئات في "الهدف" متطابقة مع الفلتر، كما هو موضّح في مستندات فئة IntentFilter .

يمكن أن يستخدم تطبيقك ميزة "مطابقة الأهداف" بطريقة مشابهة لتلك التي يستخدمها تطبيق Home. يحتوي PackageManager على مجموعة من query...() methods التي تعرض جميع المكوّنات التي يمكنها قبول نية معيّنة، وسلسلة مماثلة من طرق resolve...() التي تحدّد أفضل مكوّن للردّ على نية معيّنة. على سبيل المثال: تعرض الدالة queryIntentActivities() قائمة بجميع الأنشطة التي يمكن تنفيذها. تم تمرير الغرض كوسيطة، وستعرض queryIntentServices() قائمة مشابهة من الخدمات. لا تعمل أي من الطريقتين على تنشيط المكونات؛ فإنهم فقط يسردون تلك التي الاستجابة. هناك طريقة مماثلة، queryBroadcastReceivers()، لمستلمي البث