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

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

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

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

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

طبقة مثال وصف
المنتج myProduct ، myProduct_eu ، myProduct_eu_fr ، j2 ، sdk تحدد طبقة المنتج مواصفات الميزة لمنتج الشحن مثل الوحدات النمطية المراد إنشاؤها ، واللغات المدعومة ، والتكوين لمختلف اللغات. وبعبارة أخرى، وهذا هو اسم المنتج بشكل عام. يتم تحديد المتغيرات الخاصة بالمنتج في ملفات تعريف المنتج. يمكن للمنتج أن يرث من تعريفات المنتجات الأخرى ، مما يبسط الصيانة. تتمثل إحدى الطرق الشائعة في إنشاء منتج أساسي يحتوي على ميزات تنطبق على جميع المنتجات ، ثم إنشاء متغيرات المنتج بناءً على هذا المنتج الأساسي. على سبيل المثال ، يمكن أن يرث منتجان يختلفان فقط من خلال أجهزة الراديو الخاصة بهما (CDMA مقابل GSM) من نفس المنتج الأساسي الذي لا يعرف الراديو.
مجلس / جهاز مارلين ، بلولين ، مرجان تمثل طبقة اللوحة / الجهاز الطبقة المادية للبلاستيك على الجهاز (أي ، التصميم الصناعي للجهاز). تمثل هذه الطبقة أيضًا المخططات المجردة للمنتج. وتشمل هذه الأجهزة الطرفية على اللوحة وتكوينها. الأسماء المستخدمة هي مجرد رموز لتكوينات مختلفة للوحة / الجهاز.
قوس الذراع ، x86 ، arm64 ، 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 ، ولتحقيق مقاييس موثوقة في البنيات المستخدمة لتصحيح الأخطاء ، يجب على مطوري الأجهزة اتباع الإرشادات التالية:

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

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

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

وترد الإعدادات الأكثر شيوعا مخصصة في ملف الأطر / القاعدة / الأساسية / RES / RES / القيم / 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.

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

كتابة makefiles المنتج

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

  1. إنشاء device/ <company-name> / <device-name> دليل للمنتج الخاص بك. على سبيل المثال، device/google/marlin . سيحتوي هذا الدليل على شفرة المصدر لجهازك بالإضافة إلى ملفات makefiles لبنائها.
  2. إنشاء device.mk MAKEFILE أن يعلن الملفات والوحدات اللازمة للجهاز. للحصول على مثال، انظر device/google/marlin/device-marlin.mk .
  3. قم بإنشاء ملف تعريف منتج لإنشاء منتج معين بناءً على الجهاز. يؤخذ في makefile التالية من 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
    

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

  4. إنشاء AndroidProducts.mk الملف الذي يشير إلى makefiles المنتج. في هذا المثال ، يلزم فقط تعريف المنتج makefile. المثال التالي هو من device/google/marlin/AndroidProducts.mk (الذي يحتوي على كل مارلن، بكسل، والأسقمري، بكسل 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 MAKEFILE التي تحتوي على تكوينات متن محددة. للحصول على مثال، انظر device/google/marlin/BoardConfig.mk .
  6. للحصول على الروبوت 9 و خفض فقط، إنشاء vendorsetup.sh ملف لإضافة منتج الخاص بك ( "التحرير والسرد الغداء") لبناء جنبا إلى جنب مع بناء البديل مفصولة شرطة. على سبيل المثال:
    add_lunch_combo <product-name>-userdebug
    
  7. في هذه المرحلة ، يمكنك إنشاء المزيد من متغيرات المنتجات بناءً على نفس الجهاز.

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

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

عامل وصف مثال
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 مفتاح مصادقة RSA فريدًا لكل كمبيوتر عميل ، والذي سيرسله إلى أي جهاز متصل. هذا هو مفتاح RSA الموضح في مربع حوار تفويض adb. كبديل ، يمكنك إنشاء مفاتيح معروفة في صورة النظام ومشاركتها مع عميل adb. هذا مفيد لتطوير نظام التشغيل وخاصة للاختبار لأنه يتجنب الحاجة إلى التفاعل يدويًا مع مربع حوار تفويض adb.

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

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

إليك ملف makefile الذي تستخدمه 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 إذا لم يكن بالفعل تعيين.