إضافة جهاز جديد

استخدم المعلومات الموجودة في هذه الصفحة لإنشاء ملفات تعريفية لجهازك ومنتجك.

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

فهم طبقات البناء

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

طبقة مثال وصف
منتج myProduct، myProduct_eu، myProduct_eu_fr، j2، sdk تحدد طبقة المنتج مواصفات الميزة لمنتج الشحن مثل الوحدات النمطية المراد إنشاؤها، والمناطق المحلية المدعومة، والتكوين للمناطق المحلية المختلفة. بمعنى آخر، هذا هو اسم المنتج الإجمالي. يتم تعريف المتغيرات الخاصة بالمنتج في ملفات تعريف المنتج. يمكن أن يرث المنتج من تعريفات المنتج الأخرى، مما يبسط عملية الصيانة. تتمثل إحدى الطرق الشائعة في إنشاء منتج أساسي يحتوي على ميزات تنطبق على جميع المنتجات، ثم إنشاء متغيرات المنتج استنادًا إلى هذا المنتج الأساسي. على سبيل المثال، يمكن أن يرث منتجان يختلفان فقط من خلال أجهزة الراديو الخاصة بهما (CDMA مقابل GSM) من نفس المنتج الأساسي الذي لا يحدد الراديو.
اللوحة/الجهاز مارلن، بلولين، المرجان تمثل طبقة اللوحة/الجهاز الطبقة المادية من البلاستيك الموجودة على الجهاز (أي التصميم الصناعي للجهاز). تمثل هذه الطبقة أيضًا المخططات العارية للمنتج. وتشمل هذه الأجهزة الطرفية الموجودة على اللوحة وتكوينها. الأسماء المستخدمة هي مجرد رموز لتكوينات مختلفة للوحة/الجهاز.
قوس الذراع، x86، الذراع64، x86_64 تصف طبقة البنية تكوين المعالج والواجهة الثنائية للتطبيق (ABI) التي تعمل على اللوحة.

استخدام متغيرات البناء

عند إنشاء منتج معين، من المفيد أن يكون لديك اختلافات طفيفة في إصدار الإصدار النهائي. في تعريف الوحدة النمطية، يمكن للوحدة تحديد العلامات ذات LOCAL_MODULE_TAGS ، والتي يمكن أن تكون واحدة أو أكثر من القيم optional (الافتراضية) و debug و eng .

إذا لم تحدد الوحدة علامة (بواسطة LOCAL_MODULE_TAGS )، فستكون علامتها الافتراضية optional . يتم تثبيت الوحدة الاختيارية فقط إذا كانت مطلوبة من خلال تكوين المنتج مع PRODUCT_PACKAGES .

هذه هي متغيرات البناء المحددة حاليًا.

البديل وصف
eng هذه هي النكهة الافتراضية
  • تثبيت الوحدات الموسومة بـ eng أو debug .
  • تثبيت الوحدات وفقًا لملفات تعريف المنتج، بالإضافة إلى الوحدات ذات العلامات.
  • ro.secure=0
  • ro.debuggable=1
  • ro.kernel.android.checkjni=1
  • يتم تمكين adb بشكل افتراضي.
user المتغير المقصود أن يكون بتات الإصدار النهائي.
  • تثبيت الوحدات ذات العلامات مع user .
  • تثبيت الوحدات وفقًا لملفات تعريف المنتج، بالإضافة إلى الوحدات ذات العلامات.
  • ro.secure=1
  • ro.debuggable=0
  • يتم تعطيل adb بشكل افتراضي.
userdebug نفس user مع الاستثناءات التالية:
  • يقوم أيضًا بتثبيت الوحدات الموسومة بـ debug .
  • ro.debuggable=1
  • يتم تمكين adb بشكل افتراضي.

إرشادات لتصحيح المستخدم

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

  • يتم تعريف userdebug على أنه إنشاء مستخدم مع تمكين الوصول إلى الجذر، باستثناء:
    • تطبيقات تصحيح أخطاء المستخدم فقط التي يتم تشغيلها فقط عند الطلب من قبل المستخدم
    • العمليات التي يتم تشغيلها فقط أثناء الصيانة الخاملة (على الشاحن/مشحون بالكامل)، مثل استخدام dex2oatd مقابل dex2oat لتجميعات الخلفية
  • لا تقم بتضمين الميزات التي يتم تمكينها/تعطيلها افتراضيًا بناءً على نوع الإصدار. لا يُنصح المطورون باستخدام أي شكل من أشكال التسجيل الذي يؤثر على عمر البطارية، مثل تسجيل تصحيح الأخطاء أو تفريغ الكومة.
  • يجب تعريف أي ميزات تصحيح يتم تمكينها افتراضيًا في userdebug بوضوح ومشاركتها مع جميع المطورين العاملين في المشروع. يجب عليك تمكين ميزات تصحيح الأخطاء فقط لفترة زمنية محدودة حتى يتم حل المشكلة التي تحاول تصحيحها.

تخصيص البناء مع تراكبات الموارد

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

الإعدادات المخصصة الأكثر شيوعًا موجودة في ملف Frameworks/base/core/res/res/values/config.xml .

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

PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay

أو

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

ثم قم بإضافة ملف تراكب إلى الدليل، على سبيل المثال:

vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml

أي سلاسل أو مصفوفات سلاسل موجودة في ملف config.xml المتراكب تحل محل تلك الموجودة في الملف الأصلي.

بناء منتج

يمكنك تنظيم الملفات المصدر لجهازك بعدة طرق مختلفة. فيما يلي وصف موجز لإحدى طرق تنظيم تطبيق Pixel.

يتم تنفيذ Pixel بتكوين جهاز رئيسي يسمى marlin . من تكوين الجهاز هذا، يتم إنشاء منتج باستخدام ملف تعريف المنتج الذي يعلن عن معلومات خاصة بالمنتج حول الجهاز مثل الاسم والطراز. يمكنك عرض دليل device/google/marlin لمعرفة كيفية إعداد كل هذا.

كتابة ملفات تعريف المنتج

تصف الخطوات التالية كيفية إعداد ملفات تعريف المنتج بطريقة مشابهة لتلك الخاصة بخط إنتاج Pixel:

  1. قم بإنشاء دليل device/ <company-name> / <device-name> لمنتجك. على سبيل المثال، device/google/marlin . سيحتوي هذا الدليل على الكود المصدري لجهازك بالإضافة إلى ملفات التعريف اللازمة لإنشائها.
  2. قم بإنشاء ملف تعريف device.mk الذي يعلن عن الملفات والوحدات النمطية المطلوبة للجهاز. على سبيل المثال، راجع device/google/marlin/device-marlin.mk .
  3. قم بإنشاء ملف تعريف المنتج لإنشاء منتج معين بناءً على الجهاز. الملف التعريفي التالي مأخوذ من device/google/marlin/aosp_marlin.mk كمثال. لاحظ أن المنتج يرث من ملفات device/google/marlin/device-marlin.mk vendor/google/marlin/device-vendor-marlin.mk من خلال ملف makefile مع الإعلان أيضًا عن المعلومات الخاصة بالمنتج مثل الاسم والعلامة التجارية والنموذج.
    # Inherit from the common Open Source product configuration
    $(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
    $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)
    
    PRODUCT_NAME := aosp_marlin
    PRODUCT_DEVICE := marlin
    PRODUCT_BRAND := Android
    PRODUCT_MODEL := AOSP on msm8996
    PRODUCT_MANUFACTURER := Google
    PRODUCT_RESTRICT_VENDOR_FILES := true
    
    PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin
    
    $(call inherit-product, device/google/marlin/device-marlin.mk)
    $(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk)
    
    PRODUCT_PACKAGES += \
        Launcher3QuickStep \
        WallpaperPicker
    

    راجع إعداد متغيرات تعريف المنتج للمتغيرات الإضافية الخاصة بالمنتج والتي يمكنك إضافتها إلى ملفات التعريف الخاصة بك.

  4. قم بإنشاء ملف AndroidProducts.mk الذي يشير إلى ملفات تعريف المنتج. في هذا المثال، يلزم فقط ملف تعريف المنتج. المثال أدناه مأخوذ من device/google/marlin/AndroidProducts.mk (الذي يحتوي على كل من marlin وPixel وSailfish، Pixel XL، الذي شارك في معظم التكوين):
    PRODUCT_MAKEFILES := \
    	$(LOCAL_DIR)/aosp_marlin.mk \
    	$(LOCAL_DIR)/aosp_sailfish.mk
    
    COMMON_LUNCH_CHOICES := \
    	aosp_marlin-userdebug \
    	aosp_sailfish-userdebug
    
  5. قم بإنشاء ملف تعريف BoardConfig.mk الذي يحتوي على تكوينات خاصة باللوحة. على سبيل المثال، راجع device/google/marlin/BoardConfig.mk .
  6. بالنسبة لنظام التشغيل Android 9 والإصدارات الأقدم فقط ، أنشئ ملف vendorsetup.sh لإضافة منتجك ("مجموعة الغداء") إلى الإصدار بالإضافة إلى متغير بناء مفصول بشرطة. على سبيل المثال:
    add_lunch_combo <product-name>-userdebug
    
  7. عند هذه النقطة، يمكنك إنشاء المزيد من متغيرات المنتج استنادًا إلى نفس الجهاز.

تحديد متغيرات تعريف المنتج

يتم تعريف المتغيرات الخاصة بالمنتج في ملف تعريف المنتج. يوضح الجدول بعض المتغيرات التي تم الاحتفاظ بها في ملف تعريف المنتج.

عامل وصف مثال
PRODUCT_AAPT_CONFIG تكوينات aapt لاستخدامها عند إنشاء الحزم.
PRODUCT_BRAND العلامة التجارية (على سبيل المثال، شركة الاتصالات) التي تم تخصيص البرنامج لها.
PRODUCT_CHARACTERISTICS خصائص aapt للسماح بإضافة موارد خاصة بالمتغير إلى الحزمة. tablet ، nosdcard
PRODUCT_COPY_FILES قائمة كلمات مثل source_path:destination_path . يجب نسخ الملف الموجود في المسار المصدر إلى المسار الوجهة عند إنشاء هذا المنتج. يتم تعريف قواعد خطوات النسخ في config/makefile .
PRODUCT_DEVICE اسم التصميم الصناعي . هذا هو أيضًا اسم اللوحة، ويستخدمه نظام الإنشاء لتحديد موقع BoardConfig.mk . tuna
PRODUCT_LOCALES قائمة مفصولة بمسافات من رموز اللغة المكونة من حرفين، وأزواج رموز الدولة المكونة من حرفين والتي تصف العديد من الإعدادات للمستخدم، مثل لغة واجهة المستخدم والوقت والتاريخ وتنسيق العملة. يتم استخدام اللغة المحلية الأولى المدرجة في PRODUCT_LOCALES باعتبارها اللغة الافتراضية للمنتج. en_GB , de_DE , es_ES , fr_CA
PRODUCT_MANUFACTURER اسم الشركة المصنعة. acme
PRODUCT_MODEL الاسم المرئي للمستخدم النهائي للمنتج النهائي.
PRODUCT_NAME الاسم المرئي للمستخدم النهائي للمنتج الإجمالي. يظهر في شاشة الإعدادات > حول .
PRODUCT_OTA_PUBLIC_KEYS قائمة المفاتيح العامة عبر الهواء (OTA) للمنتج.
PRODUCT_PACKAGES قائمة بملفات APK والوحدات النمطية المطلوب تثبيتها. جهات اتصال التقويم
PRODUCT_PACKAGE_OVERLAYS يشير إلى ما إذا كان سيتم استخدام الموارد الافتراضية أو إضافة أي تراكبات خاصة بالمنتج. vendor/acme/overlay
PRODUCT_SYSTEM_PROPERTIES قائمة بتعيينات خصائص النظام بالتنسيق "key=value" لقسم النظام. يمكن تعيين خصائص النظام للأقسام الأخرى عبر PRODUCT_<PARTITION>_PROPERTIES كما في PRODUCT_VENDOR_PROPERTIES لقسم البائع. أسماء الأقسام المدعومة: SYSTEM و VENDOR و ODM و SYSTEM_EXT و PRODUCT .

تكوين لغة النظام الافتراضية ومرشح الإعدادات المحلية

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

ملكيات

قم بتكوين كل من اللغة الافتراضية ومرشح لغة النظام باستخدام خصائص النظام المخصصة:

  • ro.product.locale : لتعيين اللغة الافتراضية. يتم تعيين هذا في البداية على اللغة الأولى في المتغير PRODUCT_LOCALES ؛ يمكنك تجاوز هذه القيمة. (لمزيد من المعلومات، راجع جدول إعداد متغيرات تعريف المنتج .)
  • ro.localization.locale_filter : لإعداد مرشح اللغة، باستخدام تعبير عادي مطبق على أسماء اللغات. على سبيل المثال:
    • مرشح شامل: ^(de-AT|de-DE|en|uk).* - يسمح فقط باللغة الألمانية (متغيرات النمسا وألمانيا)، وجميع المتغيرات الإنجليزية للغة الإنجليزية، والأوكرانية
    • عامل التصفية الحصري: ^(?!de-IT|es).* - يستثني اللغة الألمانية (النسخة الإيطالية)، وجميع أشكال اللغة الإسبانية.

تمكين مرشح اللغة

لتمكين عامل التصفية، قم بتعيين قيمة سلسلة خاصية النظام ro.localization.locale_filter .

من خلال تعيين قيمة خاصية الفلتر واللغة الافتراضية من خلال oem/oem.prop أثناء معايرة المصنع، يمكنك تكوين القيود دون حفظ الفلتر في صورة النظام. عليك التأكد من التقاط هذه الخصائص من قسم OEM عن طريق إضافتها إلى المتغير PRODUCT_OEM_PROPERTIES كما هو موضح أدناه:

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

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

إعداد ADB_VENDOR_KEYS للاتصال عبر USB

يمكّن متغير البيئة ADB_VENDOR_KEYS الشركات المصنعة للأجهزة من الوصول إلى الإصدارات القابلة للتصحيح (-userdebug و-eng، ولكن ليس -user) عبر adb دون ترخيص يدوي. عادةً ما يقوم adb بإنشاء مفتاح مصادقة RSA فريد لكل كمبيوتر عميل، والذي سيرسله إلى أي جهاز متصل. هذا هو مفتاح RSA الموضح في مربع حوار ترخيص adb. وكبديل، يمكنك إنشاء مفاتيح معروفة في صورة النظام ومشاركتها مع عميل adb. يعد هذا مفيدًا لتطوير نظام التشغيل وخاصة للاختبار لأنه يتجنب الحاجة إلى التفاعل يدويًا مع مربع حوار ترخيص adb.

لإنشاء مفاتيح البائع، يجب على شخص واحد (عادةً مدير الإصدار):

  1. قم بإنشاء زوج مفاتيح باستخدام adb keygen . بالنسبة لأجهزة Google، تقوم Google بإنشاء زوج مفاتيح جديد لكل إصدار جديد من نظام التشغيل.
  2. تحقق من أزواج المفاتيح في مكان ما في الشجرة المصدر. تقوم Google بتخزينها في vendor/google/security/adb/ ، على سبيل المثال.
  3. قم بتعيين متغير البناء PRODUCT_ADB_KEYS للإشارة إلى دليل المفتاح الخاص بك. تقوم Google بذلك عن طريق إضافة ملف Android.mk في الدليل الرئيسي الذي يحمل اسم PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub ، مما يساعد على التأكد من أننا نتذكر إنشاء زوج مفاتيح جديد لكل إصدار من إصدارات نظام التشغيل.

إليك الملف التعريفي الذي تستخدمه Google في الدليل حيث نقوم بتخزين أزواج المفاتيح التي تم تسجيل الوصول إليها لكل إصدار:

PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub

ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),)
  $(warning ========================)
  $(warning The adb key for this release)
  $(warning )
  $(warning   $(PRODUCT_ADB_KEYS))
  $(warning )
  $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk)
  $(warning has changed and a new adb key needs to be generated.)
  $(warning )
  $(warning Please run the following commands to create a new key:)
  $(warning )
  $(warning   make -j8 adb)
  $(warning   LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS)))
  $(warning )
  $(warning and upload/review/submit the changes)
  $(warning ========================)
  $(error done)
endif

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