فرض واجهات تقسيم المنتجات

يفصل Android 11 قسم "product"، ما يجعله بشكل مستقل عن القسمين system وvendor. وفي إطار هذه التغييرات، يمكنك الآن التحكّم في وصول قسم product إلى النسخة الأصلية ولغة Java الواجهات (التي تشبه طريقة عمل فرض الواجهات في vendor الأقسام).

فرض الواجهات الأصلية

لتفعيل فرض الواجهة الأصلية، يجب ضبط PRODUCT_PRODUCT_VNDK_VERSION إلى current. (يتم ضبط الإصدار تلقائيًا على current عند الشحن مستوى واجهة برمجة التطبيقات المستهدَف أكبر من 29). يسمح إجراء التنفيذ بما يلي:

• الوحدات الأصلية في قسم product المطلوب الربط به:
  • بشكل ثابت أو ديناميكي مع الوحدات الأخرى في قسم product الذي تتضمن المكتبات الثابتة أو المشتركة أو الخاصة بالعناوين.
  • ديناميكيًا إلى مكتبات VNDK في قسم system.
• مكتبات JNI في حِزم APK غير المجمّعة في قسم product للربط بها المكتبات في /product/lib أو /product/lib64 (بالإضافة إلى مكتبات NDK).

لا يسمح إجراء التنفيذ بالروابط الأخرى إلى أقسام غير product قسم القرص.

فرض وقت الإصدار (Android.bp)

في Android 11، يمكن لوحدات النظام إنشاء منتج. لمتغير الصورة بالإضافة إلى خيارات الصورة الأساسية وصورة المورد. عندما يكون مدمجًا مع المحتوى تم تفعيل فرض الواجهة (تم ضبط PRODUCT_PRODUCT_VNDK_VERSION على current):

• تتوفّر الوحدات الأصلية في قسم product ضمن خيار المنتج بدلاً من ذلك. من السعر المتغير الأساسي

• الوحدات التي تحتوي على product_available: true في ملفات Android.bp هي: المتوفرة لخيار المنتج.

• يمكن للمكتبات أو البرامج الثنائية التي تحدد product_specific: true الارتباط بأخرى المكتبات التي تحدّد product_specific: true أو product_available: true في ملفات Android.bp.

• يجب أن تحتوي مكتبات VNDK على product_available: true في ملفات Android.bp. حتى تتمكن برامج ثنائية product من الارتباط بملفات VNDK libs.

يلخّص الجدول التالي سمات Android.bp المُستخدَمة لإنشاء الصور. مختلفة.

العقارات في Android.bp	تم إنشاء خيارات المنتج
	قبل التنفيذ	بعد التنفيذ
تلقائي (بدون)	قلب (يشمل /system و/system_ext /product)	قلب (يشمل /system و/system_ext، ولكن ليس /product)
system_ext_specific: true	قلب	قلب
product_specific: true	قلب	المنتج
vendor: true	المُورِّد	المُورِّد
vendor_available: true	أساسي، بائع	أساسي، بائع
product_available: true	لا ينطبق	أساسي، منتج
vendor_available: true وproduct_available: true	لا ينطبق	أساسي، منتج، بائع
system_ext_specific: true وvendor_available: true	أساسي، بائع	أساسي، بائع
product_specific: true وvendor_available: true	أساسي، بائع	منتج، بائع

فرض وقت الإصدار (Android.mk)

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

فرض بيئة التشغيل

عند تفعيل فرض الواجهة الأصلية، تعمل تهيئة الرابط لا يسمح رابط الشهادة الحيوية لعمليات النظام باستخدام مكتبات product إنشاء قسم product لعمليات product التي لا يمكن الربط بها المكتبات خارج قسم product (ومع ذلك، يمكن لهذه العمليات الارتباط مكتبات VNDK). تتسبب محاولات انتهاك تهيئة رابط بيئة التشغيل في فشل العملية وظهور رسالة الخطأ CANNOT LINK EXECUTABLE.

فرض واجهات Java

لتفعيل فرض واجهة Java، اضبط PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE إلى true (القيمة هي يتم ضبطها تلقائيًا على true عندما يكون مستوى واجهة برمجة تطبيقات الشحن للسمة المستهدَفة أكبر من 29). عند تفعيل هذا الخيار، يسمح إجراء التنفيذ بما يلي أو لا يسمح به: access:

واجهة برمجة التطبيقات	/system	/system_ext	/product	/vendor	/data
واجهة برمجة التطبيقات العامة
@SystemApi
@إخفاء واجهة برمجة التطبيقات

كما في قسم vendor، يتوفر تطبيق أو مكتبة Java في product يُسمح للقسم باستخدام واجهات برمجة التطبيقات العامة وواجهات برمجة التطبيقات للنظام فقط، الربط بمكتبة التي تستخدم واجهات برمجة تطبيقات مخفية. يشمل ذلك الربط عند الإصدار. الوقت والانعكاس في وقت التشغيل

فرض وقت الإصدار

في وقت الإصدار، يتحقّق تطبيق Make وSong من أنّ وحدات Java في product لا يستخدم واجهات برمجة التطبيقات المخفية من خلال التحقق من platform_apis حقلان (sdk_version) يجب أن يشتمل sdk_version للتطبيقات في القسم "product" على أن يتم ملؤها current أو system_current أو إصدار رقمي من واجهة برمجة التطبيقات يجب أن يكون الحقل platform_apis فارغًا.

فرض بيئة التشغيل

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

تفعيل فرض واجهة المنتج

استخدِم الخطوات الواردة في هذا القسم لتفعيل فرض واجهة المنتج.

الخطوة	المهمة	مطلوب
1	قم بتعريف ملف makefile في النظام الخاص بك والذي يحدد حزم البيانات system، ثم ضبط التحقُّق من متطلبات مسار العناصر في device.mk (لمنع تثبيت الوحدات غير التابعة للنظام) إلى قسم system).	N
2	يمكنك حذف القائمة المسموح بها.	N
3	فرض الواجهات الأصلية وتحديد حالات إخفاق رابط بيئة التشغيل (يمكن أن يتم تشغيله في بالتوازي مع فرض Java).	Y
4	فرض واجهات Java والتحقق من سلوك بيئة التشغيل (يمكن أن يتم التشغيل بالتوازي من خلال فرض الإعلانات المدمجة مع المحتوى).	Y
5	يمكنك التحقّق من سلوكيات بيئة التشغيل.	Y
6	عدِّل device.mk بفرض تفعيل واجهة المنتج.	Y

الخطوة 1: إنشاء ملف makefile وتفعيل التحقُّق من مسار العناصر

في هذه الخطوة، يمكنك تحديد ملف system makefile.

1. يمكنك إنشاء ملف إعداد يحدد الحِزم للقسم system. بالنسبة على سبيل المثال، أنشئ ملف oem_system.mk يتضمّن ما يلي:

   $(call inherit-product, $(SRC_TARGET_DIR)/product/handheld_system.mk)
   $(call inherit-product, $(SRC_TARGET_DIR)/product/telephony_system.mk)
   
   # Applications
   PRODUCT_PACKAGES += \
       CommonSystemApp1 \
       CommonSystemApp2 \
       CommonSystemApp3 \
   
   # Binaries
   PRODUCT_PACKAGES += \
       CommonSystemBin1 \
       CommonSystemBin2 \
       CommonSystemBin3 \
   
   # Libraries
   PRODUCT_PACKAGES += \
       CommonSystemLib1 \
       CommonSystemLib2 \
       CommonSystemLib3 \
   
   PRODUCT_SYSTEM_NAME := oem_system
   PRODUCT_SYSTEM_BRAND := Android
   PRODUCT_SYSTEM_MANUFACTURER := Android
   PRODUCT_SYSTEM_MODEL := oem_system
   PRODUCT_SYSTEM_DEVICE := generic
   
   # For system-as-root devices, system.img should be mounted at /, so we
   # include ROOT here.
   _my_paths := \
    $(TARGET_COPY_OUT_ROOT)/ \
    $(TARGET_COPY_OUT_SYSTEM)/ \
   
   $(call require-artifacts-in-path, $(_my_paths),)
   

2. في ملف device.mk، عليك اكتساب ملف العلامة التجارية الشائع لـ system. عملية التقسيم وتفعيل التحقق من متطلبات مسار العناصر. مثلاً:

   $(call inherit-product, $(SRC_TARGET_DIR)/product/oem_system.mk)
   
   # Enable artifact path requirements checking
   PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := strict
   

لمحة عن متطلبات مسار العناصر

عند ضبط PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS على true أو strict، يمنع نظام الإصدار تثبيت الحزم المحددة في ملفات Makefiles أخرى المسارات المحددة في require-artifacts-in-path و تمنع الحِزم محددة في ملف Makefile الحالي من تثبيت العناصر خارج المسارات محددة في require-artifacts-in-path.

في المثال أعلاه، مع ضبط PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS على strict، لا يمكن أن تتضمّن ملفات makefiles خارج "oem_system.mk" وحدات تم تثبيتها على القسم root أو system. لتضمين هذه الوحدات، يجب عليك يُرجى تحديدها في ملف oem_system.mk نفسه أو في ملف makefile مضمَّن. تؤدي محاولات تثبيت وحدات لمسارات غير مسموح بها إلى حدوث فواصل تصميم. لحلّ المشكلة الفواصل الإعلانية، يمكنك تنفيذ أحد الإجراءات التالية:

• الخيار 1: تضمين وحدة النظام في ملفات التخزين المضمّنة في oem_system.mk وهذا يجعل ذلك يتم تلبية متطلبات مسار الأداة (نظرًا لأن الوحدات المتوفّرة حاليًا في ملف makefile مضمّن) وبالتالي تسمح بالتثبيت على مجموعة من المسارات في "طلب-artifacts-in-path".

• الخيار 2: تثبيت الوحدات في القسم system_ext أو product (و عدم تثبيت الوحدات في قسم system).

• الخيار 3: إضافة وحدات إلى PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST تضم هذه القائمة الوحدات المسموح بها ليتم تثبيتها.

الخطوة 2: إفراغ القائمة المسموح بها

في هذه الخطوة، يمكنك إجراء PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST. فارغة، لذا يمكن لجميع الأجهزة التي تشارك oem_system.mk أن تشارك أيضًا system واحدًا . لإفراغ القائمة المسموح بها، انقل أي وحدات في القائمة إلى عليك إضافة system_ext أو product إلى قسم "إنشاء ملفات" في system. هذا النمط هذه الخطوة اختيارية لأنّ تحديد صورة system شائعة ليس مطلوبًا. تفعيل فرض واجهة المنتج. ومع ذلك، فإن إفراغ القائمة المسموح بها مفيدة في تحديد حدود system باستخدام system_ext.

الخطوة 3: فرض الواجهات الأصلية

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

1. ضبط PRODUCT_PRODUCT_VNDK_VERSION := current

2. أنشِئ الجهاز وابحث عن أخطاء الإصدار. من المحتمل أن تظهر لك بعض الإصدارات فواصل إعلانية لخيارات المنتج أو الخيارات الأساسية غير المتوفرة. الفواصل الشائعة تشمل:

   • ولن يتم استخدام أي وحدة hidl_interface تتضمّن product_specific: true. المتاحة لوحدات النظام. لحلّ هذه المشكلة، يُرجى استبدال "product_specific: true". مع system_ext_specific: true.
   • قد لا تتضمّن الوحدات خيار المنتج المطلوب للمنتج الوحدات. لحلّ هذه المشكلة، اجعل هذه الوحدة متاحة لقسم product من خلال ضبط product_available: true أو نقل الوحدة إلى product من خلال تعيين product_specific: true.

3. يجب حلّ أخطاء الإصدار والتأكّد من إصدار الجهاز بنجاح.

4. يمكنك مسح الصورة والبحث عن أخطاء وقت التشغيل في تشغيل الجهاز والسجلات.

   • إذا كانت العلامة linker من سجلّ حالات الاختبار تعرض CANNOT LINK EXECUTABLE فإن ملف التصميم يفتقد تبعية (ولم يتم التقاطها في وقت الإصدار).
   • للتحقّق من ذلك من نظام الإصدار، أضِف المكتبة المطلوبة إلى الحقل shared_libs: أو required:.

5. حل التبعيات المفقودة باستخدام الإرشادات الواردة أعلاه.

الخطوة 4: فرض واجهات Java

في هذه الخطوة، يتم إعداد PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true، ثم البحث عن أخطاء الإصدار الناتجة وإصلاحها. ابحث عن نوعين محددين من الأخطاء:

• أخطاء نوع الرابط: يشير هذا الخطأ إلى أنّ أحد التطبيقات يرتبط بوحدات Java التي تتضمّن sdk_version أوسع نطاقًا لإصلاح ذلك، يمكنك توسيع نطاق sdk_version أو حصر إمكانية الوصول إلى sdk_version في المكتبة مثال على الخطأ:

  error: frameworks/base/packages/SystemUI/Android.bp:138:1: module "SystemUI" variant "android_common": compiles against system API, but dependency "telephony-common" is compiling against private API.Adjust sdk_version: property of the source or target module so that target module is built with the same or smaller API set than the source.
  

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

  frameworks/opt/net/voip/src/java/com/android/server/sip/SipSessionGroup.java:1051: error: cannot find symbol
              ProxyAuthenticate proxyAuth = (ProxyAuthenticate)response.getHeader(
                                             ^
    symbol:   class ProxyAuthenticate
    location: class SipSessionGroup.SipSessionImpl
  

الخطوة 5: التحقّق من سلوكيات بيئة التشغيل

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

• بناء جملة Veridex:

  ./art/tools/veridex/appcompat.sh --dex-file={apk file}
  

• مثال على نتيجة veridex:

  #1: Linking greylist-max-o Landroid/animation/AnimationHandler;-><init>()V use(s):
         Lcom/android/systemui/pip/phone/PipMotionHelper;-><init>(Landroid/content/Context;Landroid/app/IActivityManager;Landroid/app/IActivityTaskManager;Lcom/android/systemui/pip/phone/PipMenuActivityController;Lcom/android/internal/policy/PipSnapAlgorithm;Lcom/android/systemui/statusbar/FlingAnimationUtils;)V
  
  #1332: Reflection greylist Landroid/app/Activity;->mMainThread use(s):
         Landroidx/core/app/ActivityRecreator;->getMainThreadField()Ljava/lang/reflect/Field;
  

للحصول على تفاصيل عن استخدام veridex، يُرجى الرجوع إلى مقالة اختبار باستخدام veridex .

الخطوة 6: تحديث device.mk

بعد إصلاح جميع الأعطال في الإصدار والتشغيل، والتحقّق من بيئة التشغيل هذه السلوك على النحو المتوقع، يمكنك ضبط ما يلي في device.mk:

• PRODUCT_PRODUCT_VNDK_VERSION := current
• PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true