أمان التطبيق

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

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

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

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

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

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

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

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

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

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

تشمل واجهات برمجة التطبيقات المحمية ما يلي:

  • وظائف الكاميرا
  • بيانات الموقع (GPS)
  • وظائف بلوتوث
  • وظائف الهاتف
  • وظائف SMS / MMS
  • اتصالات الشبكة / البيانات

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

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

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

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

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

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

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

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

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

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

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

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

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

أذونات في تثبيت التطبيق - خرائط جوجل أذونات التطبيق المثبت - Gmail
أذونات في تثبيت التطبيق - خرائط جوجلأذونات التطبيق المثبت - 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 واجهات برمجة التطبيقات الحساسة للتكلفة في قائمة واجهات برمجة التطبيقات المحمية التي يتحكم فيها نظام التشغيل. سيتعين على المستخدم منح إذن صريح لتطبيقات الجهات الخارجية التي تطلب استخدام واجهات برمجة التطبيقات الحساسة من حيث التكلفة. تشمل واجهات برمجة التطبيقات هذه:

  • مهاتفة
  • SMS / MMS
  • الشبكة / البيانات
  • الفواتير داخل التطبيق
  • وصول NFC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المراجع المصدقة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • واجهة برمجة تطبيقات لإطار إدارة الحقوق الرقمية (DRM) ، والتي تتعرض للتطبيقات من خلال إطار عمل تطبيق Android وتعمل من خلال Dalvik VM للتطبيقات القياسية.

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

هندسة إدارة الحقوق الرقمية على منصة Android

الشكل 3. هندسة إدارة الحقوق الرقمية على نظام Android الأساسي