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

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

خلفية

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

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

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

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

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

بدءًا من Android 12 (مستوى واجهة برمجة التطبيقات 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> الأذونات التي تنتمي إلى المجموعة، ولكنّه يمنح المجموعة اسمًا.

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

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

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

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

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

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