أذونات النظام android
للحفاظ على أمان النظام والمستخدمين، يتطلب أندرويد من التطبيقات طلب الإذن قبل أن تتمكن التطبيقات من استخدام بيانات نظام وميزات معينة. اعتمادا على مدى حساسية المنطقة، قد يمنح النظام الإذن تلقائيا، أو قد يطلب من المستخدم الموافقة على الطلب.
ملاحظة: هذه الأذونات هي أذونات الروبوت. أنها تمنح الوصول إلى ميزات الجهاز. إذا كنت تبحث عن أذونات غوغل أبي، مثل الأذونات المستخدمة للتفاعل مع غوغل دريف، فاطلع على أذونات خدمات غوغل بلاي .
يصف هذا القسم كيف يمكن للتطبيقات طلب الوصول إلى أذونات النظام. ويصف أيضا كيف يمكن للتطبيقات تحديد الأذونات الخاصة بهم، بحيث يمكن للتطبيقات مشاركة آمن البيانات والميزات مع تطبيقات أخرى
طلب الأذونات
الروبوت هو نظام التشغيل مفصولة بامتيازات، حيث كل التطبيق يعمل مع هوية نظام متميز (معرف المستخدم لينكس ومعرف المجموعة). كما يتم فصل أجزاء من النظام إلى هويات متميزة. لينكس بالتالي يعزل التطبيقات من بعضها البعض ومن النظام.
نظرا لأن كل تطبيق أندرويد يعمل في وضع الحماية، يجب أن تطلب التطبيقات بشكل صريح الوصول إلى الموارد والبيانات خارج وضع الحماية. يطلبون هذا الوصول عن طريق إعلان الأذونات التي يحتاجونها للحصول على قدرات إضافية لا توفرها رمل الأساسي. اعتمادا على مدى حساسية المنطقة، قد يمنح النظام الإذن تلقائيا، أو قد يطالب المستخدم بالموافقة على الطلب أو رفضه.
تصف هذه الصفحة كيف يمكن للتطبيقات طلب أذونات النظام القياسية. توضح الوثيقة التالية، تعريف الأذونات ، كيف يمكن للتطبيقات تعريف الأذونات الخاصة بها، حتى يتمكنوا من مشاركة بياناتهم وإمكانياتهم بشكل آمن مع تطبيقات أخرى.
انظر أيضا دليل نمط المواد للأذونات .
استخدام الأذونات
لا يحتوي تطبيق أندرويد الأساسي على أية أذونات مقترنة به بشكل افتراضي، مما يعني أنه لا يمكنه فعل أي شيء من شأنه أن يؤثر سلبا على تجربة المستخدم أو أي بيانات على الجهاز. للاستفادة من الميزات المحمية للجهاز، يجب تضمين علامة أو أكثر من <uses-permission> في بيان التطبيق .
على سبيل المثال، التطبيق الذي يحتاج إلى مراقبة الرسائل القصيرة سمز سوف يحدد:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.app.myapp" >
<uses-permission android:name="android.permission.RECEIVE_SMS" />
...
</manifest>
لمزيد من المعلومات حول مستويات الحماية المختلفة للأذونات، راجع أذونات عادية وخطرة .
إذا كان تطبيقك يسرد الأذونات العادية في بيانه (أي الأذونات التي لا تشكل خطرا كبيرا على خصوصية المستخدم أو تشغيل الجهاز)، فإن النظام يمنح هذه الأذونات تلقائيا. إذا كان تطبيقك يسرد أذونات خطيرة في بيانه (أي الأذونات التي قد تؤثر على خصوصية المستخدم أو التشغيل العادي للجهاز)، يطلب النظام من المستخدم منح هذه الأذونات صراحة. تعتمد طريقة عمل أندرويد على إصدار النظام وإصدار النظام الذي يستهدفه تطبيقك:
إذا كان الجهاز يعمل بنظام التشغيل أندرويد 6.0 (مستوى واجهة برمجة التطبيقات 23) أو أعلى، و targetSdkVersion هو 23 أو أعلى، فإن التطبيق يطلب أذونات من المستخدم في وقت التشغيل. يمكن للمستخدم إبطال الأذونات في أي وقت، لذلك يحتاج التطبيق للتحقق ما إذا كان لديه أذونات في كل مرة فإنه الوصول إلى واجهات برمجة التطبيقات المحمية إذن. لمزيد من المعلومات حول طلب الأذونات في تطبيقك، راجع دليل التدريب على العمل مع أذونات النظام .
إذا كان الجهاز يعمل بنظام التشغيل أندرويد 5.1.1 (أبي targetSdkVersion 22) أو أقل، أو targetSdkVersion في التطبيق هو 22 أو أقل، فإن النظام يطلب من المستخدم منح الأذونات عند قيام المستخدم بتثبيت التطبيق. إذا أضفت إذنا جديدا إلى إصدار محدث من التطبيق، فإن النظام يطلب من المستخدم منح هذا الإذن عندما يقوم المستخدم بتحديث التطبيق. مرة واحدة المستخدم بتثبيت التطبيق، والطريقة الوحيدة التي يمكن إبطال إذن هو عن طريق إلغاء تثبيت التطبيق.
غالبا ما يؤدي فشل إذن يؤدي إلى إرجاع SecurityException إلى التطبيق. ومع ذلك، هذا ليس مضمونا أن يحدث في كل مكان. على سبيل المثال، يتحقق الأسلوب sendBroadcast(Intent) أذونات كما يتم تسليم البيانات إلى كل جهاز استقبال، بعد إرجاع استدعاء الأسلوب، لذلك لن تتلقى استثناء إذا كان هناك فشل الإذن. في جميع الحالات تقريبا، ومع ذلك، سيتم طباعة فشل إذن إلى سجل النظام.
الأذونات التي يوفرها نظام أندرويد يمكن العثور عليها في Manifest.permission . أي تطبيق قد أيضا تحديد وفرض أذونات خاصة بها، لذلك هذه ليست قائمة شاملة لجميع الأذونات الممكنة.
قد يتم فرض إذن معين في عدد من الأماكن أثناء عملية البرنامج:
في وقت مكالمة في النظام، لمنع التطبيق من تنفيذ وظائف معينة.
عند بدء النشاط، لمنع التطبيقات من إطلاق أنشطة تطبيقات أخرى.
كل من الإرسال واستقبال البث، للسيطرة على الذين يمكن أن تتلقى البث أو الذين يمكن إرسال بث لك.
عند الوصول إلى مزود المحتوى وتشغيله.
ربط أو بدء خدمة.
تعديلات الأذونات التلقائية
بمرور الوقت، قد تتم إضافة قيود جديدة إلى النظام الأساسي بحيث يجب أن يطلب تطبيقك، من أجل استخدام واجهات برمجة تطبيقات معينة، إذنا لم يكن في حاجة إليه من قبل. لأن التطبيقات الحالية تفترض الوصول إلى تلك واجهات برمجة التطبيقات متاحة بحرية، قد الروبوت تطبيق طلب إذن جديد إلى بيان التطبيق لتجنب كسر التطبيق على إصدار منصة جديدة. يتخذ أندرويد قرارا بشأن ما إذا كان التطبيق قد يحتاج إلى إذن استنادا إلى القيمة المقدمة للسمة targetSdkVersion . إذا كانت القيمة أقل من الإصدار الذي تمت إضافة الإذن به، فإن أندرويد يضيف الإذن.
على سبيل المثال، تمت إضافة إذن WRITE_EXTERNAL_STORAGE في مستوى أبي 4 لتقييد الوصول إلى مساحة التخزين المشتركة. إذا كان targetSdkVersion الخاص بك هو 3 أو أقل، يتم إضافة هذا الإذن إلى التطبيق الخاص بك على أحدث إصدارات أندرويد.
تحذير: إذا تمت إضافة إذن تلقائيا إلى تطبيقك، فستدرج بطاقة تطبيقك على غوغل بلاي هذه الأذونات الإضافية على الرغم من أن تطبيقك قد لا يتطلبها فعلا.
لتجنب هذا وإزالة الأذونات الافتراضية التي لا تحتاج إليها، دائما تحديث targetSdkVersion الخاص بك targetSdkVersion على أعلى مستوى ممكن. يمكنك معرفة الأذونات التي تمت إضافتها مع كل إصدار في وثائق Build.VERSION_CODES .
عرض أذونات التطبيق
يمكنك عرض في الأذونات المعرفة حاليا في النظام باستخدام التطبيق إعدادات وقذيفة الأمر adb shell pm list permissions . لاستخدام تطبيق الإعدادات، انتقل إلى الإعدادات > التطبيقات . اختر أحد التطبيقات وانتقل لأسفل للاطلاع على الأذونات التي يستخدمها التطبيق. بالنسبة إلى مطوري البرامج، يعرض خيار بنك التنمية الآسيوي '-s' الأذونات في نموذج مشابه لكيفية رؤية المستخدم لها:
$ adb shell pm list permissions -s
All Permissions:
Network communication: view Wi-Fi state, create Bluetooth connections, full
Internet access, view network state
Your location: access extra location provider commands, fine (GPS) location,
mock location sources for testing, coarse (network-based) location
Services that cost you money: send SMS messages, directly call phone numbers
.
إذن المطلوبة لتثبيت تطبيقات غير معروفة
إذا كان تطبيقك يستهدف أندرويد 8.0 (مستوى واجهة برمجة التطبيقات 26) أو أعلى ويؤدي إلى تثبيتات أبك باستخدام واجهة برمجة تطبيقات مثبت الحزمة، فستحتاج إلى إضافة إذن REQUEST_INSTALL_PACKAGES ، كما هو موضح في مقتطف الشفرة التالي:
<manifest>
<uses-permission
android:name="android.permission.REQUEST_INSTALL_PACKAGES" />
<application>
...
</application>
</manifest>
يمكن أن تظهر التطبيقات التي تستخدم هذا الإذن فقط في شاشة إعدادات نظام تثبيت تطبيقات غير معروفة . لمزيد من المعلومات، راجع دليل نشر أندرويد ستوديو لمعرفة كيفية تثبيت تطبيقات غير معروفة .
أذونات عادية وخطرة
وتنقسم أذونات النظام إلى عدة مستويات الحماية. أهم مستويات الحماية التي يجب معرفتها هي أذونات عادية وخطيرة :
تغطي الأذونات العادية المناطق التي يحتاج فيها تطبيقك إلى الوصول إلى البيانات أو الموارد خارج وضع الحماية في التطبيق، ولكن حيث لا يوجد سوى خطر ضئيل جدا على خصوصية المستخدم أو تشغيل تطبيقات أخرى. على سبيل المثال، إذن لتعيين المنطقة الزمنية هو إذن عادي. إذا كان التطبيق يعلن أنه يحتاج إلى إذن عادي، والنظام تلقائيا منح الإذن إلى التطبيق. للحصول على قائمة كاملة من الأذونات العادية الحالية، راجع الأذونات العادية .
تغطي الأذونات الخطرة المناطق التي يريد فيها التطبيق البيانات أو الموارد التي تتضمن معلومات المستخدم الخاصة، أو قد تؤثر على بيانات المستخدم المخزنة أو تشغيل تطبيقات أخرى. على سبيل المثال، القدرة على قراءة جهات اتصال المستخدم هي إذن خطير. إذا كان التطبيق يعلن أنه يحتاج إلى إذن خطير، يجب على المستخدم منح إذن صريح إلى التطبيق.
أذونات خاصة
هناك بضعة أذونات لا تتصرف مثل أذونات عادية وخطيرة. SYSTEM_ALERT_WINDOW و WRITE_SETTINGS حساسة بشكل خاص، لذلك معظم التطبيقات لا ينبغي استخدامها. إذا كان أحد التطبيقات يحتاج إلى أحد هذه الأذونات، فيجب عليه إعلان الإذن في البيان، وإرسال نية تطلب تفويض المستخدم. ويستجيب النظام للقصد من خلال عرض شاشة إدارة مفصلة للمستخدم.
للحصول على تفاصيل حول كيفية طلب هذه الأذونات، راجع WRITE_SETTINGS المرجعي WRITE_SETTINGS و WRITE_SETTINGS .
مجموعات الأذونات
جميع أذونات نظام الروبوت خطيرة تنتمي إلى مجموعات إذن. إذا كان الجهاز يعمل بنظام التشغيل أندرويد 6.0 (مستوى واجهة برمجة التطبيقات 23) و targetSdkVersion من التطبيق هو 23 أو أعلى، targetSdkVersion تطبيق سلوك النظام التالي عندما يطلب تطبيقك إذنا خطيرا:
إذا طلب أحد التطبيقات إذنا خطرا مدرجا في بيانه، ولا يحتوي التطبيق حاليا على أية أذونات في مجموعة الأذونات، يعرض النظام مربع حوار للمستخدم يصف مجموعة الأذونات التي يريد التطبيق الدخول إليها. لا يصف مربع الحوار الإذن المحدد داخل هذه المجموعة. على سبيل المثال، إذا طلب التطبيق إذن READ_CONTACTS ، مربع الحوار النظام يقول فقط التطبيق يحتاج إلى الوصول إلى جهات اتصال الجهاز. إذا منح المستخدم الموافقة، والنظام يعطي التطبيق مجرد إذن طلب.
إذا كان التطبيق يطلب إذن خطير المدرجة في بيانها، والتطبيق بالفعل إذن خطير آخر في نفس المجموعة إذن، يمنح النظام على الفور إذن دون أي تفاعل مع المستخدم. على سبيل المثال، إذا كان أحد التطبيقات قد طلب سابقا وتم منح إذن READ_CONTACTS ، ثم يطلب WRITE_CONTACTS ، يمنح النظام على الفور هذا الإذن.
يمكن لأي إذن أن ينتمي إلى مجموعة إذن، بما في ذلك الأذونات والأذونات العادية التي يحددها تطبيقك. ومع ذلك، تؤثر مجموعة الإذن فقط على تجربة المستخدم إذا كان الإذن خطرا. يمكنك تجاهل مجموعة الأذونات للأذونات العادية.
إذا كان الجهاز يعمل بنظام التشغيل أندرويد 5.1 (أبي targetSdkVersion 22) أو أقل، أو targetSdkVersion في التطبيق هو 22 أو أقل، فإن النظام يطلب من المستخدم منح الأذونات في وقت التثبيت. مرة أخرى، ونظام يقول فقط للمستخدم ما مجموعات إذن يحتاج التطبيق، وليس الأذونات الفردية.
الجدول 1. أذونات خطرة ومجموعات الإذن.
Permission Group Permissions
CALENDAR
READ_CALENDAR
WRITE_CALENDAR
CAMERA
CAMERA
CONTACTS
READ_CONTACTS
WRITE_CONTACTS
GET_ACCOUNTS
LOCATION
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
MICROPHONE
RECORD_AUDIO
PHONE
READ_PHONE_STATE
CALL_PHONE
READ_CALL_LOG
WRITE_CALL_LOG
ADD_VOICEMAIL
USE_SIP
PROCESS_OUTGOING_CALLS
SENSORS
BODY_SENSORS
SMS
SEND_SMS
RECEIVE_SMS
READ_SMS
RECEIVE_WAP_PUSH
RECEIVE_MMS
STORAGE
READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE
تحديد الأذونات
تصف هذه الوثيقة كيف يمكن لمطوري التطبيقات استخدام ميزات الأمان التي يوفرها أندرويد لتحديد أذوناتهم الخاصة. من خلال تحديد الأذونات المخصصة، يمكن للتطبيق مشاركة موارده وإمكانياته مع التطبيقات الأخرى. لمزيد من المعلومات حول الأذونات، راجع نظرة عامة على أمان أندرويد .
خلفية
الروبوت هو نظام التشغيل مفصولة بامتيازات، حيث كل التطبيق يعمل مع هوية نظام متميز (معرف المستخدم لينكس ومعرف المجموعة). كما يتم فصل أجزاء من النظام إلى هويات متميزة. لينكس بالتالي يعزل التطبيقات من بعضها البعض ومن النظام.
يمكن أن تعرض التطبيقات وظائفها لتطبيقات أخرى من خلال تحديد الأذونات التي يمكن لهذه التطبيقات الأخرى طلبها. كما يمكنهم تحديد الأذونات التي يتم إتاحتها تلقائيا لأي تطبيقات أخرى تم توقيعها باستخدام الشهادة نفسها.
توقيع التطبيق
يجب أن يتم توقيع جميع ملفات .apk (ملفات .apk ) مع شهادة .apk الخاص بالمفتاح الخاص. تحدد هذه الشهادة مؤلف التطبيق. لا يلزم توقيع الشهادة من قبل جهة مصدقة؛ فمن المسموح به تماما، ونموذجية، لتطبيقات الروبوت لاستخدام الشهادات الموقعة ذاتيا. والغرض من الشهادات في الروبوت هو التمييز بين الكتاب التطبيق. يسمح هذا النظام لمنح أو رفض التطبيقات الوصول إلى أذونات على مستوى التوقيع ومنح أو رفض طلب التطبيق ليتم منح نفس هوية لينكس كما التطبيق آخر.
وسر إدس والوصول إلى الملفات
في وقت التثبيت، الروبوت يعطي كل حزمة معرف المستخدم لينكس متميزة. تبقى الهوية ثابتة طوال مدة حياة الحزمة على هذا الجهاز. على جهاز آخر، نفس الحزمة قد يكون إيد مختلفة؛ ما يهم هو أن كل حزمة لديها إيد متميزة على جهاز معين.
لأن تنفيذ الأمان يحدث على مستوى العملية، رمز أي حزم اثنين لا يمكن تشغيل عادة في نفس العملية، لأنها تحتاج إلى تشغيل كمستخدمين لينكس مختلفة. يمكنك استخدام السمة sharedUserId في علامة manifest AndroidManifest.xml لكل حزمة sharedUserId معرف المستخدم نفسه. من خلال القيام بذلك، لأغراض الأمن يتم التعامل مع الحزم اثنين كما يجري نفس التطبيق، مع نفس هوية المستخدم وأذونات الملف. لاحظ أنه من أجل الاحتفاظ بالأمان، سيتم منح رقم تعريف المستخدم نفسه اثنين فقط من التطبيقات التي تم توقيعها مع نفس التوقيع (ويطلبان نفس اسم المستخدم المشترك).
سيتم تعيين أي بيانات المخزنة من قبل التطبيق معرف المستخدم التطبيق، وليس عادة الوصول إلى حزم أخرى.
تحديد وإنفاذ الأذونات
لفرض الأذونات الخاصة بك، يجب عليك أولا أن تعلن لهم في AndroidManifest.xml باستخدام واحد أو أكثر من عناصر <permission> .
على سبيل المثال، يمكن للتطبيق الذي يريد التحكم في من يمكنه بدء إحدى أنشطته أن يعلن عن إذن لهذه العملية على النحو التالي:
<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>
ملاحظة: لا يسمح النظام لحزم متعددة بإعلان إذن بنفس الاسم، إلا إذا تم توقيع جميع الحزم بنفس الشهادة. إذا كانت الحزمة تعلن إذن، لا يسمح النظام للمستخدم بتثبيت حزم أخرى بنفس اسم إذن، ما لم يتم توقيع تلك الحزم مع نفس الشهادة مثل الحزمة الأولى. لتجنب تسمية التصادمات، نوصي باستخدام تسمية النمط العكسي للأذونات المخصصة، على سبيل المثال com.example.myapp.ENGAGE_HYPERSPACE .
مطلوب السمة بروتكتيليفيل، إخبار النظام كيف يمكن أن يكون المستخدم على علم التطبيقات التي تتطلب الإذن، أو الذي يسمح له عقد هذا الإذن، كما هو موضح في الوثائق المرتبطة.
السمة 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
phone numbers without your intervention. Malicious apps may
cause unexpected calls on your phone bill. Note that this does not
allow the app to call emergency numbers.</string>
توصيات الأذونات المخصصة
يمكن للتطبيقات تحديد الأذونات المخصصة لها وطلب الأذونات المخصصة من التطبيقات الأخرى من خلال تحديد عناصر <uses-permission> . ومع ذلك، يجب عليك تقييم ما إذا كان من الضروري لتطبيقك القيام بذلك.
إذا كنت تقوم بتصميم مجموعة من التطبيقات التي تعرض وظيفة لبعضها البعض، في محاولة لتصميم التطبيقات بحيث يتم تعريف كل إذن مرة واحدة فقط. يجب القيام بذلك إذا لم يتم توقيع جميع التطبيقات بنفس الشهادة. حتى لو تم توقيع جميع التطبيقات مع نفس الشهادة، فمن أفضل الممارسات لتحديد كل إذن مرة واحدة فقط.
إذا كانت الوظيفة متاحة فقط للتطبيقات التي تم توقيعها بنفس توقيع التطبيق المقدم، فقد تتمكن من تجنب تحديد الأذونات المخصصة باستخدام عمليات التحقق من التوقيع. عندما يجعل أحد تطبيقاتك طلبا لتطبيق آخر من تطبيقاتك، يمكن للتطبيق الثاني التحقق من أن كلا التطبيقين تم توقيعهما باستخدام الشهادة نفسها قبل الالتزام بالطلب.
إذا كنت تقوم بتطوير مجموعة من التطبيقات يعمل فقط على الأجهزة الخاصة بك، يجب عليك تطوير وتثبيت الحزمة التي تدير أذونات لجميع التطبيقات في الجناح. هذه الحزمة لا تحتاج إلى تقديم أي خدمات في حد ذاتها. فإنه يعلن فقط جميع الأذونات، والتطبيقات الأخرى في جناح طلب تلك الأذونات مع العنصر <uses-permission> .
فرض الأذونات في AndroidManifest.xml
يمكنك تطبيق أذونات عالية المستوى تقيد الوصول إلى مكونات كاملة من النظام أو التطبيق من خلال AndroidManifest.xml . للقيام بذلك، وتشمل سمة android:permission على العنصر المطلوب، تسمية الإذن الذي يتحكم في الوصول إليه.
Activity أذونات Activity (التي يتم تطبيقها على علامة <activity> ) على تقييد من يمكنه بدء النشاط المقترن. يتم التحقق من الإذن خلال Context.startActivity() و Activity.startActivityForResult() ؛ إذا لم يكن لدى المتصل الإذن المطلوب ثم يتم طرح SecurityException من المكالمة.
Service أذونات Service (التي يتم تطبيقها على علامة <service> Service <service> ) بتقييد من يمكنه بدء الخدمة المرتبطة أو الارتباط بها. يتم التحقق من الإذن أثناء Context.startService() ، Context.stopService() و Context.bindService() ؛ إذا لم يكن لدى المتصل الإذن المطلوب ثم يتم طرح SecurityException من المكالمة.
أذونات BroadcastReceiver (تطبق على علامة <receiver> ) تقيد من يمكنه إرسال البث إلى المستقبل المقترن. يتم التحقق من الإذن بعد Context.sendBroadcast() يعود، كما يحاول النظام لتقديم البث المقدم إلى المتلقي معين. ونتيجة لذلك، فإن فشل إذن لن يؤدي إلى الاستثناء الذي ألقيت مرة أخرى إلى المتصل. فإنه لن مجرد تحقيق النية. وبنفس الطريقة، يمكن توفير إذن ل Context.registerReceiver() للتحكم في من يمكنه البث إلى جهاز استقبال مسجل برمجيا. الذهاب في الاتجاه الآخر، يمكن توفير إذن عند استدعاء Context.sendBroadcast() لتقييد أي كائنات برودكاستريسيفر يسمح لتلقي البث (انظر أدناه).
ContentProvider أذونات ContentProvider (التي يتم تطبيقها على علامة <provider> ) إلى تقييد من يمكنه الدخول إلى البيانات في ContentProvider . (مزودي المحتوى لديهم مرفق أمان إضافي مهم المتاحة لهم أذونات أوري الموصوفة في وقت لاحق). وخلافا للمكونات الأخرى، وهناك نوعان من سمات إذن منفصلة يمكنك تعيين: android:readPermission يقيد الذين يمكن أن تقرأ من مزود، android:writePermission يقيد من يمكنه الكتابة إليها. لاحظ أنه إذا كان مزود الحماية مع إذن القراءة والكتابة، وعقد فقط إذن الكتابة لا يعني أنك يمكن أن تقرأ من مزود. يتم التحقق من الأذونات عند استرداد موفر (أولا إذا لم يكن لديك أي إذن، سيتم طرح سيكوريتيكسسيبتيون)، وأثناء تنفيذ العمليات على الموفر. استخدام ContentResolver.query() يتطلب عقد إذن القراءة. باستخدام ContentResolver.insert() ، ContentResolver.update() ، ContentResolver.delete() يتطلب إذن الكتابة. في كل هذه الحالات، لا يحمل الإذن المطلوب ينتج في SecurityException يتم طرحها من المكالمة.
فرض الأذونات عند إرسال البث
بالإضافة إلى الإذن بإنفاذ من الذي يمكن إرسال النوايا إلى جهاز الإرسال BroadcastReceiver المسجل (كما هو موضح أعلاه)، يمكنك أيضا تحديد الإذن المطلوب عند إرسال البث. عن طريق استدعاء Context.sendBroadcast() مع سلسلة إذن، تحتاج إلى أن التطبيق المتلقي يجب أن تعقد هذا الإذن من أجل الحصول على البث الخاص بك.
لاحظ أن كلا من جهاز الاستقبال والمذيع يمكن أن يتطلب إذنا. عند حدوث ذلك، يجب أن تمر كل من عمليات التحقق من الأذونات للنية ليتم تسليمها إلى الهدف المقترن.
لمزيد من المعلومات، راجع تقييد البث مع الأذونات .
تنفيذ إذن آخر
يمكن فرض أذونات غرامة الحبيبات بشكل تعسفي في أي مكالمة في الخدمة. يتم تحقيق ذلك باستخدام الأسلوب Context.checkCallingPermission() . استدعاء مع سلسلة إذن المطلوب وسوف يعود عدد صحيح يشير إلى ما إذا كان قد تم منح هذا الإذن لعملية الدعوة الحالية. لاحظ أن هذا يمكن أن تستخدم فقط عند تنفيذ مكالمة قادمة من عملية أخرى، عادة من خلال واجهة إدل نشرت من خدمة أو بطريقة أخرى تعطى لعملية أخرى.
هناك عدد من الطرق المفيدة الأخرى للتحقق من الأذونات. إذا كان لديك بيد من عملية أخرى، يمكنك استخدام الأسلوب السياق Context.checkPermission(String, int, int) للتحقق من إذن ضد هذا بيد. إذا كان لديك اسم حزمة التطبيق آخر، يمكنك استخدام طريقة باكاجيماناجر مباشرة PackageManager.checkPermission PackageManager.checkPermission(String, String) لمعرفة ما إذا كان قد تم منح هذه الحزمة معينة إذن محدد.
أوري الأذونات
نظام الإذن القياسي الموصوف حتى الآن غالبا ما يكون غير كاف عند استخدامه مع مزودي المحتوى. قد يرغب موفر المحتوى في حماية نفسه باستخدام أذونات القراءة والكتابة، في حين يحتاج عملاءه المباشرون أيضا إلى توجيه عناوين ورل محددة إلى تطبيقات أخرى لتشغيلها. مثال نموذجي هو المرفقات في تطبيق البريد. يجب حماية الوصول إلى البريد من خلال الأذونات، نظرا لأن هذه بيانات المستخدم حساسة. ومع ذلك، إذا تم إعطاء عنوان أوري لمرفق صورة إلى عارض صور، لن يكون لدى عارض الصور إذن لفتح المرفق لأنه ليس لديه سبب للاحتفاظ بإذن للوصول إلى كافة رسائل البريد الإلكتروني.
الحل لهذه المشكلة هو أذونات بير-أوري: عند بدء نشاط ما أو إرجاع نتيجة إلى نشاط ما، يستطيع المتصل تعيين Intent.FLAG_GRANT_READ_URI_PERMISSION و / أو Intent.FLAG_GRANT_WRITE_URI_PERMISSION . وهذا يمنح الإذن للنشاط المتلقي الوصول إلى معرف أوري المحدد للبيانات في النية، بغض النظر عما إذا كان لديه أي إذن للوصول إلى البيانات في موفر المحتوى المقابل للنوايا.
تتيح هذه الآلية نموذجا مشتركا على نمط القدرة حيث يؤدي تفاعل المستخدم (فتح مرفق، واختيار جهة اتصال من قائمة، وما إلى ذلك) إلى منح إذن خاص بالحصول على إذن دقيق. هذا يمكن أن يكون وسيلة رئيسية للحد من الأذونات المطلوبة من قبل التطبيقات فقط تلك المرتبطة مباشرة إلى سلوكهم.
ومع ذلك، فإن منح أذونات أوري الدقيقة يتطلب بعض التعاون مع موفر المحتوى الذي يحمل عناوين ورل هذه. فمن المستحسن أن مقدمي المحتوى تنفيذ هذا المرفق، وتعلن أنها تدعم ذلك من خلال android:grantUriPermissions السمة أو <grant-uri-permissions> العلامة.
يمكن العثور على مزيد من المعلومات في طرق Context.grantUriPermission() و Context.revokeUriPermission() و Context.checkUriPermission() .
ليست هناك تعليقات:
إرسال تعليق