خذ استبيان قابلية الاستخدام لدينا لتحسين هذا الموقع.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

تصلب الإطار الإعلامي

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

  • تقسيم مكونات خطوط أنابيب AV إلى عمليات آلية خاصة بالتطبيق.
  • تمكين مكونات الوسائط القابلة للتحديث (برامج الاستخراج وبرامج الترميز وما إلى ذلك).

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

يحتاج بائعو OEM و SoC إلى تحديث HAL وتغييرات إطار العمل لجعلها متوافقة مع البنية الجديدة. على وجه التحديد ، نظرًا لأن كود Android المقدم من البائع غالبًا ما يفترض أن كل شيء يعمل في نفس العملية ، يجب على البائعين تحديث native_handle لتمرير المقابض الأصلية ( native_handle ) التي لها معنى عبر العمليات. للحصول على تنفيذ مرجعي للتغييرات المتعلقة بتصلب الوسائط ، ارجع إلى frameworks/av frameworks/native .

التغييرات المعمارية

استخدمت الإصدارات السابقة من Android عملية mediaserver واحدة متجانسة مع العديد من الأذونات (الوصول إلى الكاميرا ، والوصول إلى الصوت ، والوصول إلى برنامج تشغيل الفيديو ، والوصول إلى الملفات ، والوصول إلى الشبكة ، وما إلى ذلك). يقسم Android 7.0 عملية mediaserver إلى عدة عمليات جديدة تتطلب كل منها مجموعة أصغر من الأذونات:

تصلب mediaserver

الشكل 1. تغييرات معمارية لتصلب خادم الوسائط

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

ملاحظة: بسبب تبعيات البائع ، لا تزال بعض برامج الترميز تعمل في mediaserver ، وبالتالي تمنح mediaserver أذونات أكثر من اللازم. على وجه التحديد ، يستمر Widevine Classic في العمل في mediaserver لنظام Android 7.0.

تغييرات MediaServer

في Android 7.0 ، توجد عملية mediaserver لقيادة التشغيل والتسجيل ، على سبيل المثال تمرير ومزامنة المخازن المؤقتة بين المكونات والعمليات. تتواصل العمليات من خلال آلية Binder القياسية.

في جلسة تشغيل ملف محلي قياسي ، يمرر التطبيق واصف ملف (FD) إلى mediaserver (عادةً عبر mediaserver Java API) ، mediaserver :

  1. يلتف ملف FD ​​في كائن مصدر بيانات Binder الذي يتم تمريره إلى عملية الاستخراج ، والذي يستخدمه للقراءة من الملف باستخدام Binder IPC. (لا يحصل مستخرج الوسائط على FD ولكنه بدلاً من ذلك يقوم بإجراء مكالمات Binder مرة أخرى إلى mediaserver للحصول على البيانات.)
  2. يفحص الملف ، وينشئ المستخرج المناسب لنوع الملف (مثل MP3Extractor ، أو MPEG4Extractor) ، ويعيد واجهة Binder mediaserver عملية mediaserver .
  3. يقوم بإجراء مكالمات Binder IPC للمستخرج لتحديد نوع البيانات في الملف (مثل بيانات MP3 أو H.264).
  4. يدعو إلى عملية mediacodec لإنشاء برامج ترميز من النوع المطلوب ؛ يتلقى واجهات Binder لبرامج الترميز هذه.
  5. يجعل مكالمات Binder IPC متكررة إلى mediacodec لقراءة العينات المشفرة ، ويستخدم Binder IPC لإرسال البيانات المشفرة إلى عملية mediacodec لفك التشفير ، mediacodec البيانات التي تم فك تشفيرها.

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

التغييرات MediaCodecService

خدمة الترميز هي المكان الذي تعيش فيه أجهزة التشفير وأجهزة فك التشفير. بسبب تبعيات البائع ، ليست كل برامج الترميز موجودة في عملية الترميز حتى الآن. في Android 7.0:

  • تعيش أجهزة فك التشفير وبرامج التشفير غير الآمنة في عملية الترميز.
  • تعيش أجهزة فك التشفير الآمنة وأجهزة ترميز الأجهزة في mediaserver (دون تغيير).

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

تغييرات MediaDrmServer

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

تغييرات AudioServer

تستضيف عملية AudioServer المكونات المتعلقة بالصوت مثل إدخال الصوت ومخرجاته ، وخدمة Policymanager التي تحدد توجيه الصوت ، وخدمة راديو FM. للحصول على تفاصيل حول التغييرات الصوتية وإرشادات التنفيذ ، راجع تنفيذ الصوت .

تغييرات CameraServer

يتحكم CameraServer في الكاميرا ويستخدم عند تسجيل الفيديو للحصول على إطارات الفيديو من الكاميرا ثم تمريرها إلى mediaserver لمزيد من المعالجة. للحصول على تفاصيل حول التغييرات وإرشادات التنفيذ لتغييرات CameraServer ، راجع Camera Framework Hardening .

تغييرات ExtractorService

تستضيف خدمة المستخرج المستخلصات والمكونات التي تحلل تنسيقات الملفات المختلفة التي يدعمها إطار عمل الوسائط. تعتبر خدمة المستخرج هي الأقل امتيازًا بين جميع الخدمات - لا يمكنها قراءة ملفات FD ، لذا فهي تقوم بإجراء مكالمات على واجهة Binder (التي يوفرها لها mediaserver for لكل جلسة تشغيل) للوصول إلى الملفات.

يقوم تطبيق (أو mediaserver ) بإجراء مكالمة إلى عملية الاستخراج للحصول على IMediaExtractor ، ويستدعي ذلك IMediaExtractor للحصول على IMediaSources للمسار الموجود في الملف ، ثم يستدعي IMediaSources لقراءة البيانات منها.

لنقل البيانات بين العمليات ، mediaserver التطبيق (أو mediaserver ) على البيانات الموجودة في mediaserver الرد كجزء من معاملة Binder أو يستخدم ذاكرة مشتركة:

  • يتطلب استخدام الذاكرة المشتركة استدعاء Binder إضافيًا لتحرير الذاكرة المشتركة ولكنه أسرع ويستخدم طاقة أقل للمخازن المؤقتة الكبيرة.
  • يتطلب استخدام in-Parcel نسخًا إضافيًا ولكنه أسرع ويستخدم طاقة أقل للمخازن المؤقتة الأصغر من 64 كيلو بايت.

التنفيذ

لدعم هذه الخطوة من MediaDrm و MediaCrypto المكونات في جديدة mediadrmserver العملية، يجب على موردي تغيير طريقة توزيع للمخازن آمنة للسماح المخازن المؤقتة إلى أن تكون مشتركة بين العمليات.

في إصدارات Android السابقة ، تم تخصيص مخازن مؤقتة آمنة في mediaserver قبل OMX::allocateBuffer mediaserver وتستخدم أثناء فك التشفير في نفس العملية ، كما هو موضح أدناه:

الشكل 2. Android 6.0 وتخصيص المخزن المؤقت الأقل في خادم الوسائط.

في Android 7.0 ، تغيرت عملية تخصيص المخزن المؤقت إلى آلية جديدة توفر المرونة مع تقليل التأثير على عمليات التنفيذ الحالية. مع MediaDrm و MediaCrypto مداخن في جديدة mediadrmserver العملية، يتم تخصيص مخازن مختلفة ويجب على موردي بتحديث مقابض عازلة آمنة بحيث يمكن نقلها عبر الموثق عندما MediaCodec استدعاء عملية فك تشفير على MediaCrypto .

الشكل 3. تخصيص الإصدار 7.0 من نظام Android والإصدارات الأحدث من المخزن المؤقت في خادم الوسائط.

باستخدام مقابض أصلية

يجب أن يُرجع OMX::allocateBuffer native_handle مؤشرًا إلى بنية native_handle ، والتي تحتوي على واصفات الملف (FDs) وبيانات عدد صحيح إضافي. تتمتع native_handle بجميع مزايا استخدام FDs ، بما في ذلك دعم الموثق الحالي للتسلسل / إلغاء التسلسل ، مع السماح بمزيد من المرونة للبائعين الذين لا يستخدمون FDs حاليًا.

استخدم native_handle_create() لتخصيص المقبض الأصلي. تأخذ شفرة الإطار ملكية البنية native_handle المخصصة وهي مسؤولة عن تحرير الموارد في كل من العملية حيث يتم تخصيص native_handle الأصلي في الأصل وفي العملية التي يتم فيها إلغاء التسلسل. يقوم إطار العمل بإصدار مقابض أصلية مع native_handle_close() متبوعًا بـ native_handle_delete() ويقوم native_handle / إلغاء تسلسل native_handle باستخدام Parcel::writeNativeHandle()/readNativeHandle() .

يمكن لبائعي SoC الذين يستخدمون FDs لتمثيل المخازن المؤقتة الآمنة ملء FD في native_handle مع FD الخاص بهم. يمكن للبائعين الذين لا يستخدمون FDs تمثيل المخازن المؤقتة الآمنة باستخدام حقول إضافية في native_buffer .

تحديد موقع فك التشفير

يجب على البائعين تحديث طريقة فك تشفير OEMCrypto التي تعمل على native_handle لإجراء أي عمليات خاصة بالمورد ضرورية لجعل native_handle قابلة للاستخدام في مساحة العملية الجديدة (تتضمن التغييرات عادةً تحديثات لمكتبات OEMCrypto).

كما allocateBuffer هو عملية OMX القياسية، الروبوت 7.0 يتضمن ملحق جديد OMX ( OMX.google.android.index.allocateNativeHandle ) إلى الاستعلام عن هذا الدعم و OMX_SetParameter الدعوة التي تخطر تنفيذ OMX يجب استخدام مقابض الأم.