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

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

خلفية

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

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

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

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

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

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

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

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

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

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

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

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