أمان التطبيق

عناصر التطبيقات

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

العناصر الأساسية لتطبيقات Android هي:

• AndroidManifest.xml : ملف AndroidManifest.xml هو ملف التحكم الذي يخبر النظام بما يجب فعله بجميع المكونات ذات المستوى الأعلى (على وجه التحديد الأنشطة والخدمات وأجهزة استقبال البث وموفري المحتوى الموضحين أدناه) في التطبيق. ويحدد هذا أيضًا الأذونات المطلوبة.

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

• الخدمات : الخدمة عبارة عن مجموعة من التعليمات البرمجية التي يتم تشغيلها في الخلفية. ويمكن تشغيله في عمليته الخاصة، أو في سياق عملية تطبيق آخر. "ترتبط" المكونات الأخرى بالخدمة وتستدعي الأساليب عليها عبر استدعاءات الإجراءات عن بعد. مثال على الخدمة هو مشغل الوسائط: حتى عندما يقوم المستخدم بإنهاء واجهة مستخدم تحديد الوسائط، فمن المحتمل أن المستخدم لا يزال ينوي مواصلة تشغيل الموسيقى. تحافظ الخدمة على تشغيل الموسيقى حتى عند اكتمال واجهة المستخدم.

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

نموذج إذن Android: الوصول إلى واجهات برمجة التطبيقات المحمية

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

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

تتضمن واجهات برمجة التطبيقات المحمية هذه ما يلي:

• وظائف الكاميرا
• بيانات الموقع (نظام تحديد المواقع العالمي)
• وظائف البلوتوث
• وظائف الهاتف
• وظائف الرسائل القصيرة/رسائل الوسائط المتعددة
• اتصالات الشبكة/البيانات

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

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

ضمن إعدادات الجهاز، يستطيع المستخدمون عرض أذونات التطبيقات التي قاموا بتثبيتها مسبقًا. يمكن للمستخدمين أيضًا إيقاف تشغيل بعض الوظائف عالميًا عندما يختارون ذلك، مثل تعطيل نظام تحديد المواقع العالمي (GPS) أو الراديو أو شبكة Wi-Fi.

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

تم توضيح الأذونات الافتراضية للنظام على https://developer.android.com/reference/android/Manifest.permission.html . قد تعلن التطبيقات عن أذوناتها الخاصة لاستخدام التطبيقات الأخرى. لم يتم سرد هذه الأذونات في الموقع أعلاه.

عند تحديد إذن، تخبر سمة مستوى الحماية النظام بكيفية إعلام المستخدم بالتطبيقات التي تتطلب إذنًا، أو من يُسمح له بالحصول على إذن. تم توضيح تفاصيل إنشاء واستخدام الأذونات الخاصة بالتطبيقات على https://developer.android.com/guide/topics/security/security.html .

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

كيف يفهم المستخدمون تطبيقات الطرف الثالث

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

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

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

كما أظهرت العديد من دراسات واجهة المستخدم أن الإفراط في مطالبة المستخدم يؤدي إلى بدء المستخدم في قول "موافق" لأي مربع حوار يتم عرضه. أحد الأهداف الأمنية لنظام Android هو نقل المعلومات الأمنية المهمة إلى المستخدم بشكل فعال، وهو ما لا يمكن القيام به باستخدام مربعات الحوار التي سيتم تدريب المستخدم على تجاهلها. من خلال تقديم المعلومات المهمة مرة واحدة، وفقط عندما تكون مهمة، من المرجح أن يفكر المستخدم فيما يوافق عليه.

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

الأذونات عند تثبيت التطبيق — ترجمة Google	أذونات التطبيق المثبت - Gmail

الشكل 1. عرض أذونات التطبيقات

اتصال interprocess

يمكن للعمليات التواصل باستخدام أي من الآليات التقليدية من نوع UNIX. تتضمن الأمثلة نظام الملفات أو المقابس المحلية أو الإشارات. ومع ذلك، لا تزال أذونات Linux سارية.

يوفر Android أيضًا آليات IPC جديدة:

• Binder : آلية استدعاء إجراء عن بعد خفيفة الوزن تعتمد على القدرة ومصممة لتحقيق أداء عالٍ عند إجراء مكالمات أثناء العملية وعبر العمليات. يتم تنفيذ Binder باستخدام برنامج تشغيل Linux مخصص. راجع https://developer.android.com/reference/android/os/Binder.html .

• الخدمات : يمكن للخدمات (التي تمت مناقشتها أعلاه) توفير واجهات يمكن الوصول إليها مباشرة باستخدام الموثق.

• النوايا : النية هي كائن رسالة بسيط يمثل "نية" للقيام بشيء ما. على سبيل المثال، إذا كان تطبيقك يريد عرض صفحة ويب، فإنه يعبر عن "نيته" لعرض عنوان URL عن طريق إنشاء مثيل Intent وتسليمه إلى النظام. يحدد النظام موقع جزء آخر من التعليمات البرمجية (في هذه الحالة، المتصفح) الذي يعرف كيفية التعامل مع هذا الهدف، ويقوم بتشغيله. يمكن أيضًا استخدام النوايا لبث الأحداث المثيرة للاهتمام (مثل الإشعارات) على مستوى النظام. راجع https://developer.android.com/reference/android/content/Intent.html .

• ContentProviders : ContentProvider هو مخزن بيانات يوفر الوصول إلى البيانات الموجودة على الجهاز؛ المثال الكلاسيكي هو ContentProvider الذي يتم استخدامه للوصول إلى قائمة جهات اتصال المستخدم. يمكن للتطبيق الوصول إلى البيانات التي كشفتها التطبيقات الأخرى عبر ContentProvider، ويمكن للتطبيق أيضًا تحديد ContentProviders الخاص به لعرض البيانات الخاصة به. راجع https://developer.android.com/reference/android/content/ContentProvider.html .

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

واجهات برمجة التطبيقات الحساسة للتكلفة

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

• الاتصالات الهاتفية
• الرسائل القصيرة/رسائل الوسائط المتعددة
• الشبكة/البيانات
• الفواتير داخل التطبيق
• الوصول إلى NFC

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

الوصول إلى بطاقة SIM

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

معلومات شخصية

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

الشكل 2. الوصول إلى بيانات المستخدم الحساسة متاح فقط من خلال واجهات برمجة التطبيقات المحمية

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

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

أجهزة إدخال البيانات الحساسة

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

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

البيانات التعريفية للجهاز

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

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

سلطات التصديق

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

لإضافتها كمرجع مصدق عام جديد إلى مجموعة أسهم Android، يجب على المرجع المصدق إكمال عملية تضمين Mozilla CA ثم تقديم طلب ميزة ضد Android ( https://code.google.com/p/android/issues/entry ) لإضافة CA إلى مخزون Android CA الذي تم تعيينه في مشروع Android مفتوح المصدر (AOSP).

لا تزال هناك مراجع مصدقة خاصة بالجهاز ولا ينبغي تضمينها في المجموعة الأساسية لمراجع AOSP، مثل المراجع المصدقة الخاصة بمشغلي شبكة الجوال والتي قد تكون ضرورية للوصول بشكل آمن إلى مكونات البنية التحتية لمشغل شبكة الجوال، مثل بوابات SMS/MMS. يتم تشجيع الشركات المصنعة للأجهزة على تضمين المراجع المصدقة الخاصة فقط في المكونات/التطبيقات التي تحتاج إلى الوثوق بهذه المراجع المصدقة. لمزيد من التفاصيل، راجع تكوين أمان الشبكة .

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

يتيح توقيع التعليمات البرمجية للمطورين التعرف على مؤلف التطبيق وتحديث تطبيقهم دون إنشاء واجهات وأذونات معقدة. يجب أن يتم توقيع كل تطبيق يتم تشغيله على نظام Android الأساسي من قبل المطور. يتم رفض التطبيقات التي تحاول التثبيت دون التوقيع بواسطة Google Play أو مثبت الحزمة على جهاز Android.

في Google Play، يعمل توقيع التطبيق على بناء جسر بين الثقة التي تربط Google بالمطور والثقة التي يضعها المطور في تطبيقه. يعرف المطورون أن تطبيقاتهم مقدمة، دون تعديل على جهاز Android؛ ويمكن مساءلة المطورين عن سلوك تطبيقاتهم.

على نظام Android، يعد توقيع التطبيق هو الخطوة الأولى لوضع التطبيق في وضع الحماية للتطبيق الخاص به. تحدد شهادة التطبيق الموقعة معرف المستخدم المرتبط بأي تطبيق؛ تعمل التطبيقات المختلفة تحت معرفات مستخدم مختلفة. يضمن توقيع التطبيق عدم تمكن تطبيق واحد من الوصول إلى أي تطبيق آخر إلا من خلال IPC محدد جيدًا.

عند تثبيت تطبيق (ملف APK) على جهاز Android، يتحقق مدير الحزم من توقيع APK بشكل صحيح باستخدام الشهادة المضمنة في ملف APK هذا. إذا كانت الشهادة (أو بشكل أكثر دقة المفتاح العام في الشهادة) تتطابق مع المفتاح المستخدم لتوقيع أي APK آخر على الجهاز، فإن APK الجديد لديه خيار التحديد في البيان أنه سيشارك UID مع الآخر بالمثل -ملفات APK الموقعة.

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

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

التحقق من التطبيق

يدعم Android 4.2 والإصدارات الأحدث التحقق من التطبيق. يمكن للمستخدمين اختيار تمكين "التحقق من التطبيقات" وتقييم التطبيقات بواسطة أداة التحقق من التطبيقات قبل التثبيت. يمكن أن ينبه التحقق من التطبيقات المستخدم إذا حاول تثبيت تطبيق قد يكون ضارًا؛ وإذا كان التطبيق سيئًا بشكل خاص، فيمكنه حظر التثبيت .

إدارة الحقوق الرقمية

يوفر نظام Android الأساسي إطار عمل DRM قابل للتوسيع يتيح للتطبيقات إدارة المحتوى المحمي بالحقوق وفقًا لقيود الترخيص المرتبطة بالمحتوى. يدعم إطار عمل إدارة الحقوق الرقمية (DRM) العديد من أنظمة إدارة الحقوق الرقمية (DRM)؛ يتم ترك أنظمة إدارة الحقوق الرقمية (DRM) التي يدعمها الجهاز إلى الشركة المصنعة للجهاز.

يتم تنفيذ إطار عمل Android DRM في طبقتين معماريتين (انظر الشكل أدناه):

• واجهة برمجة تطبيقات إطار عمل DRM، والتي يتم عرضها للتطبيقات من خلال إطار عمل تطبيق Android ويتم تشغيلها من خلال ART VM للتطبيقات القياسية.

• مدير إدارة الحقوق الرقمية (DRM) للكود الأصلي، والذي ينفذ إطار عمل إدارة الحقوق الرقمية (DRM) ويكشف عن واجهة لمكونات إدارة الحقوق الرقمية الإضافية (الوكلاء) للتعامل مع إدارة الحقوق وفك التشفير لمختلف أنظمة إدارة الحقوق الرقمية (DRM)

الشكل 3. بنية إدارة الحقوق الرقمية على منصة أندرويد