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

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

خلفية

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

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

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

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

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

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

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

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

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

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

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

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

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

تحذير: يمكن استخدام سمة sharedUserId في علامة <manifest> ملف AndroidManifest.xml لكل حزمة لتحديد هوية مستخدم واحدة لعدة حِزم. ومع ذلك، تؤدي أرقام تعريف المستخدمين المشترَكة إلى سلوك غير محدّد ضمن مدير الحِزم. وبناءً على ذلك، لا يُنصح بشدة باستخدامها وقد تتم إزالتها في لإصدار 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> إلى الأذونات التي تنتمي إلى المجموعة، غير أن فإنه يعطي المجموعة اسمًا.

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

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

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

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

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

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

متابعة القراءة حول:

<uses-permission>

مرجع واجهة برمجة التطبيقات لعلامة البيان التي توضّح أذونات النظام المطلوبة لتطبيقك

قد يهمّك أيضًا ما يلي:

نظرة عامة على أمان Android

مناقشة تفصيلية حول نموذج الأمان في نظام Android الأساسي