يوضّح هذا المستند كيفية استخدام مطوّري التطبيقات لميزات الأمان التي يوفّرها نظام التشغيل 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>
أو تلك التي تمّ الإعلان عنها في مكان آخر. ولا يؤثر ذلك إلا في كيفية groupedgrouped تجميع الأذونات عند عرضها للمستخدم. لا يحدِّد العنصر
<permission-group>
الأذونات التي تنتمي إلى المجموعة، ولكنه
يمنح المجموعة اسمًا.
يمكنك وضع إذن في المجموعة عن طريق منح اسم المجموعة لسمة
<permission>
permissionGroup
العنصر.
يُعلن العنصر
<permission-tree>
عن مساحة اسم لمجموعة من الأذونات التي يتم تحديدها في
الرمز البرمجي.
اقتراحات مخصّصة للأذونات
يمكنك تحديد أذونات مخصّصة لتطبيقاتك وطلب أذونات مخصّصة
من تطبيقات أخرى من خلال تحديد عناصر <uses-permission>
.
ومع ذلك، عليك تقييم ما إذا كان من الضروري إجراء ذلك.
- إذا كنت بصدد تصميم مجموعة من التطبيقات التي توفّر وظائف بعضها لبعض، حاوِل تصميم التطبيقات بحيث يتم تحديد كل إذن مرّة واحدة فقط. يجب إجراء ذلك إذا لم يتم توقيع جميع التطبيقات باستخدام الشهادة نفسها. حتى إذا تم توقيع جميع التطبيقات باستخدام الشهادة نفسها، من أفضل الممارسات تحديد كل إذن مرة واحدة فقط.
- إذا كانت الوظيفة متاحة للتطبيقات التي تم توقيعها باستخدام توقيع التطبيق الموفّر نفسه فقط، قد تتمكّن من تجنُّب تحديد أذونات مخصّصة باستخدام عمليات التحقّق من التوقيع. عندما يقدّم أحد تطبيقاتك طلبًا إلى تطبيق آخر من تطبيقاتك، يمكن للتطبيق الثاني التحقّق من توقيع كلا التطبيقين بالشهادة نفسها قبل الامتثال للطلب.
إذا كان إذن مخصّص ضروريًا، ننصحك بالتفكير في ما إذا كان يجب أن يحصل عليه فقط التطبيقات التي وقّعها المطوِّر نفسه الذي وقّع التطبيق الذي يجري عملية التحقّق من الإذن، مثلما هو الحال عند تنفيذ اتصالات آمنة بين العمليات بين تطبيقَين من المطوِّر نفسه. إذا كان الأمر كذلك، ننصحك باستخدام أذونات التوقيع. تكون أذونات التوقيع شفافة للمستخدم وتتجنّب الأذونات التي يؤكدها المستخدم، والتي قد تؤدي إلى إرباك المستخدمين.
اطّلِع على مزيد من المعلومات عن:
<uses-permission>
- مرجع واجهة برمجة التطبيقات لعلامة البيان التي توضّح أذونات النظام المطلوبة لتطبيقك
قد تهمّك أيضًا المقالات التالية:
- نظرة عامة على أمان Android
- مناقشة تفصيلية حول نموذج الأمان في نظام Android الأساسي