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

يوضّح هذا المستند كيفية استخدام مطوّري التطبيقات لميزات الأمان التي يوفّرها نظام التشغيل 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>. ومع ذلك، عليك تقييم ما إذا كان من الضروري إجراء ذلك.

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

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