لا تُستخدم الأذونات لطلب وظائف النظام فقط. كما يمكنك تقييد كيفية تفاعل التطبيقات الأخرى مع مكونات تطبيقك.
يشرح هذا الدليل كيفية التحقق من مجموعة الأذونات التي أعلن عنها تطبيق آخر. يشرح الدليل أيضًا طريقة ضبط الأنشطة والخدمات وموفِّري المحتوى وأجهزة استقبال البث لفرض قيود على كيفية تفاعل التطبيقات الأخرى مع تطبيقك.
التأكّد من أذونات تطبيق آخر
للاطّلاع على مجموعة الأذونات التي يعلنها تطبيق آخر، استخدِم جهازًا أو محاكيًا لإكمال الخطوات التالية:
- افتح شاشة معلومات التطبيق لتطبيق معيَّن.
انقر على الأذونات. يتم تحميل شاشة أذونات التطبيق.
تعرض هذه الشاشة مجموعة من مجموعات الأذونات. ينظم النظام مجموعة الأذونات التي أعلنها التطبيق في هذه المجموعات.
وهناك بعض الطرق المفيدة الأخرى للتحقّق من الأذونات:
- أثناء مكالمة إلى خدمة، أدخِل سلسلة أذونات إلى
Context.checkCallingPermission(). تعرض هذه الطريقة عددًا صحيحًا يشير إلى ما إذا كان قد تم منح هذا الإذن لعملية الاستدعاء الحالية أم لا. لا يمكن استخدام هذا إلا عند تنفيذ مكالمة واردة من عملية أخرى، وعادةً ما يتم ذلك من خلال واجهة IDL منشورة من خدمة أو بطريقة أخرى ممنوحة لعملية أخرى. - للتحقق مما إذا تم منح عملية أخرى إذنًا معيّنًا،
عليك تمرير العملية (PID) إلى
Context.checkPermission(). - للتحقق مما إذا تم منح حزمة أخرى إذنًا معيّنًا،
عليك تمرير اسم الحزمة إلى
PackageManager.checkPermission().
تقييد التفاعلات مع أنشطة تطبيقك
استخدِم السمة android:permission إلى العلامة
<activity> في البيان لتحديد التطبيقات الأخرى التي يمكنها تشغيل Activity. يتم
التحقق من الإذن خلال
Context.startActivity() وActivity.startActivityForResult().
إذا لم يكن المتصل لديه الإذن المطلوب، ستظهر
SecurityException.
تقييد التفاعلات مع خدمات تطبيقك
يمكنك استخدام السمة android:permission
إلى العلامة
<service> في ملف البيان لتقييد
التطبيقات الأخرى التي يمكنها تشغيلها أو ربطها برمز
Service المرتبط.
يتم التحقق من الإذن خلال Context.startService() وContext.stopService() وContext.bindService().
إذا لم يكن المتصل لديه الإذن المطلوب، سيتم
عرض SecurityException.
تقييد التفاعلات مع موفّري محتوى تطبيقك
استخدِم السمة android:permission للعلامة
<provider> لتقييد التطبيقات الأخرى التي يمكنها الوصول إلى البيانات في ContentProvider.
(لدى موفّري المحتوى ميزة أمان إضافية مهمة متاحة لهم باسم
أذونات معرّف الموارد المنتظم (URI)، والموضّحة في
القسم التالي).
وعلى عكس المكونات الأخرى، تتوفر سمتان منفصلتان للأذونات
يمكنك ضبطهما لموفّري المحتوى:
android:readPermission
تفرض قيودًا على التطبيقات الأخرى التي يمكنها القراءة من مقدّم الخدمة، و
android:writePermission تفرض قيودًا على التطبيقات الأخرى التي يمكنها الكتابة إلى موفّري المحتوى. يُرجى العِلم بأنّه إذا كان موفّر الخدمة محميًا بإذن بالقراءة والكتابة معًا،
لا يسمح الحصول على إذن الكتابة فقط للتطبيق بالقراءة من الموفّر.
يتم التحقق من الأذونات عند استرداد موفِّر الخدمة لأول مرة وعندما
ينفِّذ تطبيق عمليات على موفِّر الخدمة. وفي حال لم يكن لدى التطبيق الذي قدّم الطلب
أي من الإذنَين، يتم عرض SecurityException. إنّ استخدام
ContentResolver.query() يتطلّب
الحصول على إذن بالقراءة، في حين أنّ استخدام
ContentResolver.insert()
أو
ContentResolver.update() أو
ContentResolver.delete()
يتطلّب الحصول على إذن بالكتابة. في جميع هذه الحالات، يؤدي عدم الحصول
على الإذن المطلوب إلى ظهور SecurityException.
منح حق الوصول على أساس كل معرّف موارد منتظم (URI)
يزودك النظام بتحكم إضافي أكثر دقة في كيفية وصول التطبيقات الأخرى إلى موفري محتوى التطبيق. وعلى وجه الخصوص، يمكن لموفّر المحتوى حماية نفسه باستخدام أذونات القراءة والكتابة مع السماح للعملاء المباشرين في الوقت نفسه بمشاركة عناوين URI محدَّدة مع تطبيقات أخرى. لتأكيد أنّ تطبيقك يدعم هذا النموذج، استخدِم السمة android:grantUriPermissions أو العنصر <grant-uri-permission>.
يمكنك أيضًا منح أذونات على أساس كل معرّف موارد منتظم (URI). عند بدء
نشاط أو عرض نتيجة إلى أحد الأنشطة، اضبط علامة
القصد في Intent.FLAG_GRANT_READ_URI_PERMISSION
أو علامة النية في
Intent.FLAG_GRANT_WRITE_URI_PERMISSION
أو كلتا العلامتين. يمنح ذلك التطبيقات الأخرى أذونات للقراءة أو الكتابة أو
القراءة/الكتابة، على التوالي، لمعرّف الموارد المنتظم (URI) للبيانات المُضمَّن في
القصد. تحصل التطبيقات الأخرى على هذه الأذونات لعنوان URI محدّد بغض النظر عمّا إذا كان لديها إذن بالوصول إلى البيانات في موفِّر المحتوى بشكل عام.
على سبيل المثال، لنفترض أن أحد المستخدمين يستخدم تطبيقك لعرض رسالة إلكترونية تحتوي على مرفق صورة. وينبغي ألا تتمكن التطبيقات الأخرى من الوصول إلى محتوى البريد الإلكتروني بشكل عام، إلا أنها قد تهتم بعرض الصورة.
يمكن أن يستخدم تطبيقك حالة Intent وعلامة
النية Intent.FLAG_GRANT_READ_URI_PERMISSION للسماح لتطبيق عرض الصور برؤية الصورة.
هناك اعتبار آخر هو مستوى ظهور التطبيقات. إذا كان تطبيقك يستهدف Android 11 (مستوى واجهة برمجة التطبيقات 30) أو إصدارًا أحدث، يجعل النظام بعض التطبيقات مرئية لتطبيقك تلقائيًا ويخفي التطبيقات الأخرى تلقائيًا. إذا كان تطبيقك مزوّدًا بمزوّد محتوى وقد منح أذونات معرّف الموارد المنتظم (URI) لتطبيق آخر، سيكون تطبيقك مرئيًا تلقائيًا لهذا التطبيق الآخر.
لمزيد من المعلومات، يُرجى الاطّلاع على المواد المرجعية للطرق
grantUriPermission()
وrevokeUriPermission()
و
checkUriPermission().
تقييد التفاعلات مع أجهزة استقبال البث في تطبيقك
يمكنك استخدام السمة android:permission
للعلامة
<receiver> لتقييد التطبيقات الأخرى التي يمكنها إرسال
أحداث البث إلى BroadcastReceiver المرتبطة.
يتم
التحقّق من الإذن بعد إرجاع Context.sendBroadcast()، حيث يحاول النظام إرسال
البث الذي تم إرساله إلى المستلِم المحدّد. ويعني هذا أنّ تعذُّر الحصول على الإذن لا يؤدي إلى إرجاع استثناء إلى
المتصل، بل أنّه لا يرسل Intent.
وبالطريقة نفسها، يمكنك توفير إذن إلى
Context.registerReceiver()
للتحكّم في التطبيقات الأخرى التي يمكن بثها إلى
جهاز استقبال مسجَّل آليًا. في المقابل، يمكنك توفير
إذن عند الاتصال بـ
Context.sendBroadcast()
لفرض قيود على أجهزة استقبال البث التي يمكنها تلقّي البث.
ملاحظة: يمكن أن يتطلب كل من جهاز الاستقبال والقائم بالبث إذنًا. وفي هذه الحالة، يجب أن يجتاز عملا التحقّق من الأذونات للوصول إلى الهدف المرتبط. لمزيد من المعلومات، يُرجى الاطّلاع على حظر عمليات البث باستخدام الأذونات.