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

يوضّح هذا المستند كيفية استخدام مطوّري التطبيقات لميزات الأمان التي يوفّرها نظام التشغيل 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> أو تلك التي تمّ الإعلان عنها في مكان آخر. لا يؤثر ذلك إلا في كيفية groupedالأذونات عند عرضها على المستخدم. لا يحدِّد العنصر <permission-group> الأذونات التي تنتمي إلى المجموعة، ولكنه يمنح المجموعة اسمًا.

يمكنك وضع إذن في المجموعة عن طريق منح اسم المجموعة لسمة <permission> permissionGroup العنصر.

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

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

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

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

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