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

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

الخلفية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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