تحديد إذن مخصَّص للتطبيق

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

خلفية

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

يمكن للتطبيقات إتاحة وظائفها للتطبيقات الأخرى من خلال تحديد الأذونات التي يمكن للتطبيقات الأخرى طلبها. ويمكنهم أيضًا تحديد الأذونات التي يتم توفيرها تلقائيًا لأي تطبيقات أخرى موقَّعة بالشهادة نفسها.

توقيع التطبيق

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

منح أذونات التوقيع بعد وقت تصنيع الجهاز

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

يمكنك الإعلان عن السمة knownCerts واستخدام العلامة knownSigner في السمة protectionLevel لتطبيقك للحصول على إذن معيّن على مستوى التوقيع. بعد ذلك، يمنح النظام هذا الإذن للتطبيق الذي يطلبه إذا كان أي موقِّع في سلسلة توقيع التطبيق الطالب، بما في ذلك الموقِّع الحالي، يتطابق مع أحد الملخّصات التي تم الإعلان عنها مع الإذن في السمة knownCerts.

تتيح علامة knownSigner للأجهزة والتطبيقات منح أذونات التوقيع للتطبيقات الأخرى بدون الحاجة إلى توقيع التطبيقات في وقت تصنيع الجهاز وشحنه.

أرقام تعريف المستخدمين والوصول إلى الملفات

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

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

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

لمزيد من المعلومات حول نموذج الأمان في Android، يُرجى الاطّلاع على نظرة عامة على أمان Android.

تحديد الأذونات وفرضها

لفرض أذوناتك الخاصة، يجب أولاً الإعلان عنها في ملف AndroidManifest.xml باستخدام عنصر واحد أو أكثر من عناصر <permission>.

اصطلاح التسمية

لا يسمح النظام لحزم متعددة بالإعلان عن إذن يحمل الاسم نفسه ما لم يتم توقيع جميع الحزم بالشهادة نفسها. إذا أعلنت حزمة عن إذن، لا يسمح النظام أيضًا للمستخدم بتثبيت حزم أخرى تحمل اسم الإذن نفسه، ما لم يتم توقيع هذه الحزم بالشهادة نفسها التي تحملها الحزمة الأولى.

ننصحك بإضافة بادئة إلى الأذونات باستخدام اسم حزمة التطبيق، وذلك باستخدام تسمية بنمط النطاق العكسي، متبوعة بـ .permission. ثم وصف للوظيفة التي يمثّلها الإذن، بتنسيق SNAKE_CASE بأحرف كبيرة. على سبيل المثال: com.example.myapp.permission.ENGAGE_HYPERSPACE.

يؤدي اتّباع هذه النصيحة إلى تجنُّب تعارض الأسماء ويساعد في تحديد مالك الإذن المخصّص والغرض منه بوضوح.

مثال

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

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

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

السمة android:permissionGroup اختيارية وتُستخدم فقط لمساعدة النظام في عرض الأذونات للمستخدم. في معظم الحالات، يمكنك ضبط هذا الخيار على مجموعة نظام عادية (مُدرَجة في android.Manifest.permission_group)، على الرغم من أنّه يمكنك تحديد مجموعة بنفسك، كما هو موضّح في القسم التالي. ننصحك باستخدام مجموعة حالية، لأنّ ذلك يسهّل واجهة المستخدم الخاصة بالأذونات التي تظهر للمستخدم.

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

في ما يلي مثال على تصنيف ووصف لإذن CALL_PHONE:

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

إنشاء مجموعة أذونات

كما هو موضّح في القسم السابق، يمكنك استخدام السمة android:permissionGroup لمساعدة النظام في وصف الأذونات للمستخدم. في معظم الحالات، يمكنك ضبط هذا الخيار على مجموعة نظام عادية (مُدرَجة في android.Manifest.permission_group)، ولكن يمكنك أيضًا تحديد مجموعتك الخاصة باستخدام <permission-group>.

يحدّد العنصر <permission-group> تصنيفًا لمجموعة من الأذونات، سواء تلك التي تم تضمينها في نموذج البيان باستخدام عناصر <permission> أو تلك التي تم تضمينها في مكان آخر. يؤثر ذلك فقط في كيفية تجميع الأذونات عند عرضها للمستخدم. لا يحدّد العنصر <permission-group> الأذونات التي تنتمي إلى المجموعة، ولكنّه يمنح المجموعة اسمًا.

يمكنك وضع إذن في المجموعة من خلال تعيين اسم المجموعة إلى السمة permissionGroup للعنصر <permission>.

يُعلن العنصر <permission-tree> عن مساحة اسم لمجموعة من الأذونات المحدّدة في الرمز البرمجي.

اقتراحات الأذونات المخصّصة

يمكنك تحديد أذونات مخصّصة لتطبيقاتك وطلب أذونات مخصّصة من تطبيقات أخرى من خلال تحديد عناصر <uses-permission>. ومع ذلك، عليك تقييم ما إذا كان من الضروري إجراء ذلك.

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

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