يفصل 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.
يمكنك إنشاء ملف إعداد يحدد الحِزم للقسم
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),)
في ملف
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
، ثم البحث
للتعرّف على أخطاء الإصدار والتشغيل وحلّها للتحقّق من تشغيل الجهاز وتسجيله
وللعثور على الأخطاء في روابط بيئة التشغيل وإصلاحها:
ضبط
PRODUCT_PRODUCT_VNDK_VERSION := current
أنشِئ الجهاز وابحث عن أخطاء الإصدار. من المحتمل أن تظهر لك بعض الإصدارات فواصل إعلانية لخيارات المنتج أو الخيارات الأساسية غير المتوفرة. الفواصل الشائعة تشمل:
- ولن يتم استخدام أي وحدة
hidl_interface
تتضمّنproduct_specific: true
. المتاحة لوحدات النظام. لحلّ هذه المشكلة، يُرجى استبدال "product_specific: true
". معsystem_ext_specific: true
. - قد لا تتضمّن الوحدات خيار المنتج المطلوب للمنتج
الوحدات. لحلّ هذه المشكلة، اجعل هذه الوحدة متاحة لقسم
product
من خلال ضبطproduct_available: true
أو نقل الوحدة إلىproduct
من خلال تعيينproduct_specific: true
.
- ولن يتم استخدام أي وحدة
يجب حلّ أخطاء الإصدار والتأكّد من إصدار الجهاز بنجاح.
يمكنك مسح الصورة والبحث عن أخطاء وقت التشغيل في تشغيل الجهاز والسجلات.
- إذا كانت العلامة
linker
من سجلّ حالات الاختبار تعرضCANNOT LINK EXECUTABLE
فإن ملف التصميم يفتقد تبعية (ولم يتم التقاطها في وقت الإصدار). - للتحقّق من ذلك من نظام الإصدار، أضِف المكتبة المطلوبة إلى
الحقل
shared_libs:
أوrequired:
.
- إذا كانت العلامة
حل التبعيات المفقودة باستخدام الإرشادات الواردة أعلاه.
الخطوة 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