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

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

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

فهم طبقات التصميم

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

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

كتابة ملفات تصميم المنتجات

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

  1. إنشاء device/<company-name>/<device-name> دليل المنتج. مثلاً: device/google/marlin سيحتوي هذا الدليل على رمز مصدر لجهازك إلى جانب ملفات التغييرات لإنشائها.
  2. أنشِئ ملف device.mk بتنسيق يحدِّد الملفات والوحدات المطلوبة الخاص بك. على سبيل المثال، يُرجى مراجعة 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 (الذي يحتوي على كل من marlin وPixel وسمك شراع، 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. وفي هذه المرحلة، يمكنك إنشاء المزيد من خيارات المنتج استنادًا إلى الجهاز نفسه.

ضبط متغيّرات تعريفات المنتجات

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

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