ملاحظات برمجة OpenSL ES

تكمل الملاحظات الواردة في هذا القسم OpenSL ES 1.0.1 المواصفات.

الكائنات وتهيئة الواجهة

هناك جانبان من نموذج برمجة OpenSL ES قد لا يكونان مألوفين للمطورين الجدد، وهما والتمييز بين الكائنات والواجهات وتسلسل التهيئة.

باختصار، يشبه كائن OpenSL ES مفهوم الكائن في لغات البرمجة مثل Java وC++ ، باستثناء كائن OpenSL ES الذي يظهر فقط عبر الواجهات المرتبطة به. وتشمل هذه المعلومات ما يلي: الواجهة الأولية لجميع الكائنات، تُسمى SLObjectItf. لا يتوفّر اسم معرِّف لكائن. نفسه، سوى مقبض لواجهة SLObjectItf الخاصة بالكائن.

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

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

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

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

وبعد الانتهاء من التطبيق مع الكائن، يجب عليك إتلافه بشكل صريح؛ اطّلِع على قسم التدمير أدناه.

الجلب المُسبَق لمشغِّل الصوت

إذا كان مشغّل الصوت يتضمن مصدر بيانات معرّف الموارد المنتظم (URI)، يخصّص Object::Realize والموارد ولكنها لا الاتصال بمصدر البيانات (الإعداد) أو البدء في الجلب المسبق للبيانات. تحدث هذه بمجرد تم ضبط حالة اللاعب على SL_PLAYSTATE_PAUSED أو SL_PLAYSTATE_PLAYING.

قد تظل بعض المعلومات غير معروفة حتى وقت متأخر نسبيًا في هذا التسلسل. ضِمن على وجه الخصوص، تُرجع الدالة Player::GetDuration في البداية SL_TIME_UNKNOWN MuteSolo::GetChannelCount إما يتم إرجاعها بنجاح بعدد القنوات صفر أو نتيجة الخطأ SL_RESULT_PRECONDITIONS_VIOLATED. تعرض واجهات برمجة التطبيقات هذه القيم الصحيحة بمجرد معرفتها.

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

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

تُعد واجهة حالة الجلب المُسبَق مفيدة أيضًا في رصد الأخطاء. تسجيل معاودة الاتصال وتفعيل الخيار SL_PREFETCHEVENT_FILLLEVELCHANGE وSL_PREFETCHEVENT_STATUSCHANGE على الأقل أحداث. إذا تم تسليم هذين الحدثين في وقت واحد تقدّم PrefetchStatus::GetFillLevel تقارير عن مستوى صفري أبلغ PrefetchStatus::GetPrefetchStatus SL_PREFETCHSTATUS_UNDERFLOW، ثم هذا تشير إلى خطأ غير قابل للإصلاح في مصدر البيانات. وهذا يشمل عدم القدرة على الربط مصدر البيانات غير موجود أو لأن عنوان URI للشبكة غير صالح.

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

باختصار، تسلسل الرموز الموصى به هو:

  1. Engine::CreateAudioPlayer
  2. Object:Realize
  3. Object::GetInterface لـ SL_IID_PREFETCHSTATUS
  4. PrefetchStatus::SetCallbackEventsMask
  5. PrefetchStatus::SetFillUpdatePeriod
  6. PrefetchStatus::RegisterCallback
  7. Object::GetInterface لـ SL_IID_PLAY
  8. من Play::SetPlayState إلى SL_PLAYSTATE_PAUSED SL_PLAYSTATE_PLAYING

ملاحظة: تحدث التحضير والجلب المسبق هنا؛ خلال هذا الوقت يتم استدعاء معاودة الاتصال تحديثات الحالة الدورية.

التدمير

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

لا يدعم OpenSL ES جمع البيانات غير المرغوب فيها تلقائيًا أو المرجع حساب من الواجهات. بعد طلب Object::Destroy، يبقى كل شيء متاحًا. والواجهات التي تصبح المستمدة من الكائن المرتبط غير محددة.

لم يرصد تطبيق Android OpenSL ES الاستخدام غير الصحيح لهذه الواجهات. ويمكن أن يؤدي مواصلة استخدام هذه الواجهات بعد تدمير العنصر إلى أو أن تتصرف بطرق غير متوقعة.

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

تصوير استيريو

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

عمليات معاودة الاتصال وسلاسل المحادثات

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

يتم استدعاء معالِجات معاودة الاتصال من سلاسل المحادثات الداخلية غير داخل التطبيقات وغير المرتبطة بحزمة وقت تشغيل Android، لذلك فهي غير مؤهَّلة لاستخدام JNI. نظرًا لأن سلاسل المحادثات الداخلية هذه بالغ الأهمية سلامة تنفيذ OpenSL ES، يجب أيضًا ألا يحظر معالج معاودة الاتصال أو تنفيذ العمل المفرط.

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

لاحظ أن العكس آمن: سلسلة تطبيقات Android التي دخلت إلى JNI مسموح له لاستدعاء واجهات برمجة تطبيقات OpenSL ES مباشرةً، بما في ذلك الواجهات التي تحظرها. ومع ذلك، فإن حظر المكالمات لا مقترَحة من سلسلة التعليمات الرئيسية، لأنّها قد تؤدي إلى التطبيق لا يستجيب (ANR).

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

ليس من المضمون أن تحمل سلسلة المحادثات التي يتم فيها تشغيل معالج معاودة الاتصال الهوية نفسها في مكالمات مختلفة. لذلك، لا تعتمد على سمة pthread_t التي تعرضها قيمة pthread_self() أو pid_t التي تعرضها gettid() متسقة عبر المكالمات. وللسبب ذاته، لا تستخدم واجهات برمجة تطبيقات التخزين المحلي (بروتوكول أمان طبقة النقل) لسلسلة المحادثات، مثل pthread_setspecific() وpthread_getspecific() من معاودة الاتصال.

يضمن التنفيذ أن تكون عمليات الاستدعاء المتزامنة من نفس النوع، نفس الكائن هل لا تحدث. ومع ذلك، يمكن استرداد أنواع مختلفة من استدعاءات الكائن نفسه في الوقت نفسه على سلاسل محادثات مختلفة.

الأداء

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

أحد هذه التطورات هو دعم انخفاض وقت استجابة إخراج الصوت. الركائز الأساسية لخفض تم تضمين وقت استجابة الإخراج لأول مرة في Android 4.1 (المستوى 16 لواجهة برمجة التطبيقات)، ثم التقدم المستمر في Android 4.2 (المستوى 17 لواجهة برمجة التطبيقات). تتوفر هذه التحسينات عبر OpenSL ES لعمليات تنفيذ الأجهزة التي ميزة المطالبة رقم android.hardware.audio.low_latency. إذا لم تتم المطالبة بهذه الميزة على الجهاز ولكنه متوافق مع Android 2.3 (المستوى 9 من واجهة برمجة التطبيقات) أو في إصدار لاحق، يظل بإمكانك استخدام واجهات برمجة تطبيقات OpenSL ES، ولكن قد يكون وقت استجابة الإخراج أطول. كلما انخفضت لا يتم استخدام مسار وقت استجابة الناتج إلا إذا طلب التطبيق حجم المخزن المؤقت ومعدل العينة من متوافقة مع إعدادات الإخراج الأصلية للجهاز. هذه المعلمات الخاصة بالجهاز كما هو موضح أدناه.

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

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

تمنع جميع واجهات OpenSL ES الخاصة بتأثيرات الإخراج مسار الاستجابة الأقل.

وفي ما يلي التسلسل المقترَح:

  1. يُرجى التحقّق من المستوى 9 أو أعلى لواجهة برمجة التطبيقات لتأكيد استخدام OpenSL ES.
  2. تحقق من الميزة android.hardware.audio.low_latency باستخدام رمز مثل هذا:

    Kotlin

    import android.content.pm.PackageManager
...
val pm: PackageManager = context.packageManager
val claimsFeature: Boolean = pm.hasSystemFeature(PackageManager.FEATURE_AUDIO_LOW_LATENCY)

    Java

    import android.content.pm.PackageManager;
...
PackageManager pm = getContext().getPackageManager();
boolean claimsFeature = pm.hasSystemFeature(PackageManager.FEATURE_AUDIO_LOW_LATENCY);
  3. يُرجى التحقّق من المستوى 17 أو أعلى لواجهة برمجة التطبيقات لتأكيد استخدام android.media.AudioManager.getProperty()
  4. الحصول على حجم العيّنة وحجم المخزن المؤقت للمخرج الأصلي أو الأمثل لهذا الجهاز الناتج الأساسي البث باستخدام رمز مثل هذا:

    Kotlin

    import android.media.AudioManager
...
val am = getSystemService(Context.AUDIO_SERVICE) as AudioManager
val sampleRate: String = am.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE)
val framesPerBuffer: String = am.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER)

    Java

    import android.media.AudioManager;
...
AudioManager am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
String sampleRate = am.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE);
String framesPerBuffer = am.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER);
    يُرجى العِلم أنّ sampleRate وframesPerBuffer هما سلاسل. التحقق الأول من null ثم التحويل إلى int باستخدام Integer.parseInt().
  5. يمكنك الآن استخدام OpenSL ES لإنشاء AudioPlayer مع محدد موقع بيانات قائمة انتظار المخزن المؤقت PCM.

ملاحظة: يمكنك استخدام صفحة حجم التخزين المؤقت للصوت اختبار التطبيق لتحديد حجم المخزن المؤقت الأصلي ومعدل العينة للصوت OpenSL ES التطبيقات على الجهاز السماعي. يمكنك أيضًا زيارة GitHub لعرض لعيّنات حجم المخزن المؤقت للصوت

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

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

يشير هذا المصطلح إلى العمليات الحسابية المطلوبة لعرض المخزن المؤقت التالي (لمشغِّل الصوت) أو استهلاك مساحة التخزين المؤقت السابقة. يجب أن يستغرق المخزن المؤقت (لـ AudioRecord) المدة الزمنية نفسها تقريبًا لكل معاودة اتصال. تجنَّب الخوارزميات التي يتم تنفيذها خلال فترة زمنية غير محدّدة أو التي يتم تنفيذها بشكل متتالٍ. العمليات الحسابية الخاصة بهم. تكون العملية الحسابية لرد الاتصال متسلسلة إذا استغرقت معالجة وحدة المعالجة المركزية (CPU) أي استدعاء معين أكبر بكثير من المتوسط. وباختصار، فإن الخيار المثالي هو وقت تنفيذ وحدة المعالجة المركزية أن يكون المعالِج على تباين قريب من الصفر، وأن لا يحظر المعالِج الأوقات غير المحدودة.

يمكن استخدام وقت استجابة بطيء مع النتائج التالية فقط:

  • مكبّرات الصوت على الجهاز
  • سماعات رأس سلكية
  • سماعات الرأس السلكية
  • يتوسطه خط.
  • USB رقمي الصوتية.

يكون وقت استجابة مكبّر الصوت في بعض الأجهزة أعلى من المسارات الأخرى بسبب معالجة الإشارات الرقمية تصحيح مكبرات الصوت وحمايتها

بدءًا من Android 5.0 (مستوى واجهة برمجة التطبيقات 21)، وقت استجابة أقل تتوفّر ميزة إدخال الصوت على أجهزة محدّدة. للاستفادة من هذه الميزة، عليك أولاً تأكيد أن مخرجات الاستجابة المنخفضة متاحة كما هو موضح أعلاه. إمكانية خفض وقت الاستجابة من المتطلبات الأساسية لميزة إدخال وقت الاستجابة البطيء. ثم أنشئ مسجّل صوت معدل العينة وحجم المورد الاحتياطي كما سيتم استخدامه للمخرج. واجهات OpenSL ES لتأثيرات الإدخال مسار وقت الاستجابة الأقل. الإعداد المسبق للتسجيل يجب استخدام SL_ANDROID_RECORDING_PRESET_VOICE_RECOGNITION لوقت استجابة أقل؛ هذا يؤدي هذا الإعداد المسبق إلى إيقاف معالجة الإشارات الرقمية الخاصة بالجهاز والتي قد تضيف وقت الاستجابة إلى مسار الإدخال. لمزيد من المعلومات حول الإعدادات المسبقة للتسجيل، راجع إعداد Android واجهة المستخدم أعلاه.

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

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

أوضاع الأداء

بدءًا من نظام التشغيل Android 7.1 (مستوى واجهة برمجة التطبيقات 25)، قدّم OpenSL ES طريقة لتحديد وضع الأداء. للمسار الصوتي. الخيارات هي:

  • SL_ANDROID_PERFORMANCE_NONE: ما مِن متطلبات محدَّدة للأداء. يسمح بتأثيرات الأجهزة والبرامج.
  • SL_ANDROID_PERFORMANCE_LATENCY: يتم إعطاء الأولوية لوقت الاستجابة. لا توجد أجهزة أو وتأثيرات البرامج. وهذا هو الوضع التلقائي.
  • SL_ANDROID_PERFORMANCE_LATENCY_EFFECTS: إعطاء الأولوية لوقت الاستجابة مع الاستمرار في السماح بتأثيرات الأجهزة والبرامج.
  • SL_ANDROID_PERFORMANCE_POWER_SAVING: الأولوية الممنوحة للحفاظ على الطاقة يسمح بتأثيرات الأجهزة والبرامج.

ملاحظة: إذا لم تكن بحاجة إلى مسار وقت استجابة سريع وأردت اتّباع الاستفادة من التأثيرات الصوتية المدمجة في الجهاز (مثل تحسين الصوت لتشغيل الفيديو)، يجب عليك تعيين وضع الأداء بشكل صريح SL_ANDROID_PERFORMANCE_NONE

لضبط وضع الأداء، يجب الاتصال بـ SetConfiguration باستخدام جهاز Android على النحو الموضَّح أدناه: 

  // Obtain the Android configuration interface using a previously configured SLObjectItf.
  SLAndroidConfigurationItf configItf = nullptr;
  (*objItf)->GetInterface(objItf, SL_IID_ANDROIDCONFIGURATION, &configItf);

  // Set the performance mode.
  SLuint32 performanceMode = SL_ANDROID_PERFORMANCE_NONE;
    result = (*configItf)->SetConfiguration(configItf, SL_ANDROID_KEY_PERFORMANCE_MODE,
                                                     &performanceMode, sizeof(performanceMode));

الأمان والأذونات

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

يجب أن تطلب التطبيقات التي تستخدم OpenSL ES الأذونات التي قد تحتاج إليها للحصول على واجهات برمجة تطبيقات غير أصلية. على سبيل المثال، إذا كان التطبيق يسجّل الصوت، سيحتاج إلى إذن android.permission.RECORD_AUDIO. تحتاج التطبيقات التي تستخدم التأثيرات الصوتية إلى android.permission.MODIFY_AUDIO_SETTINGS التطبيقات التي تشغّل موارد معرّف الموارد المنتظم (URI) للشبكة بحاجة إلى android.permission.NETWORK. لمزيد من المعلومات، يُرجى مراجعة استخدام النظام الأذونات:

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