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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

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

استخدام أنواع الإصدارات

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

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

هذه هي أنواع الإصدارات المحدّدة حاليًا.

إرشادات حول وضع userdebug

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

   اطّلِع على ضبط متغيّرات تعريف المنتج للاطّلاع على مزيد من المتغيّرات المتعلّقة بالمنتج والتي يمكنك إضافتها إلى ملفات الإنشاء.

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

   add_lunch_combo <product-name>-userdebug
   

7. في هذه المرحلة، يمكنك إنشاء المزيد من خيارات المنتج استنادًا إلى الجهاز نفسه.

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

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

ضبط لغة النظام التلقائية وفلتر اللغة

استخدِم هذه المعلومات لضبط فلتر اللغة التلقائية ولغة النظام، ثم فعِّل فلتر اللغة لنوع جهاز جديد.

الخصائص

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

• ‫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، ما يساعد في ضمان تذكُّرنا بإنشاء مفتاحَي تشفير جديدَين لكل إصدار من نظام التشغيل.

في ما يلي ملف الإنشاء الذي تستخدمه 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 إذا لم يكن مضبوطًا.