הוספת מכשיר חדש

השתמש במידע בדף זה כדי ליצור קבצי makefile עבור המכשיר והמוצר שלך.

לכל מודול אנדרואיד חדש חייב להיות קובץ תצורה כדי לכוון את מערכת הבנייה עם מטא נתונים של מודול, תלות בזמן הידור והוראות אריזה. אנדרואיד משתמשת במערכת הבנייה Soong . ראה בניית אנדרואיד למידע נוסף על מערכת הבנייה של אנדרואיד.

הבנת שכבות בנייה

היררכיית הבנייה כוללת את שכבות ההפשטה המתאימות למבנה הפיזי של מכשיר. שכבות אלו מתוארות בטבלה שלהלן. כל שכבה מתייחסת לזה שמעליו במערכת יחסים של אחד לרבים. לדוגמה, ארכיטקטורה יכולה לכלול יותר מלוח אחד ולכל לוח יכול להיות יותר ממוצר אחד. אתה יכול להגדיר אלמנט בשכבה נתונה כהתמחות של אלמנט באותה שכבה, מה שמבטל את ההעתקה ומפשט את התחזוקה.

שימוש בגרסאות בנייה

כאשר בונים עבור מוצר מסוים, כדאי שיהיו וריאציות קלות על בניית המהדורה הסופית. בהגדרת מודול, המודול יכול לציין תגים עם LOCAL_MODULE_TAGS , שיכולים להיות ערך אחד או יותר של optional (ברירת מחדל), debug ו- eng .

אם מודול אינו מציין תג (על ידי LOCAL_MODULE_TAGS ), התג שלו מוגדר כברירת מחדל optional . מודול אופציונלי מותקן רק אם הוא נדרש על ידי תצורת המוצר עם PRODUCT_PACKAGES .

אלו הן גרסאות הבנייה המוגדרות כעת.

הנחיות עבור userdebug

הפעלת Userdebug build בבדיקות עוזרת למפתחי מכשירים להבין את הביצועים והעוצמה של מהדורות בפיתוח. כדי לשמור על עקביות בין משתמש ו-userdebug builds, וכדי להשיג מדדים אמינים ב-builds המשמשים לניפוי באגים, מפתחי מכשירים צריכים לפעול לפי ההנחיות הבאות:

• userdebug מוגדר כבניית משתמש עם גישת בסיס מופעלת, למעט:
  • אפליקציות userdebug בלבד המופעלות רק לפי דרישה של המשתמש
  • פעולות הפועלות רק בזמן תחזוקה סרק (במטען/טעון במלואו), כמו שימוש ב- dex2oatd לעומת dex2oat עבור קומפילי רקע
• אל תכלול תכונות מופעלות/מושבתות כברירת מחדל על סמך סוג ה-build. מפתחים לא מעודדים להשתמש בכל צורת רישום שמשפיעה על חיי הסוללה, כגון רישום באגים או השלכת ערימות.
• כל תכונות ניפוי באגים המופעלות כברירת מחדל ב-userdebug צריכות להיות מוגדרות בבירור ולשתף אותן עם כל המפתחים שעובדים על הפרויקט. עליך להפעיל תכונות ניפוי באגים רק על בסיס זמן מוגבל עד שהבעיה שאתה מנסה לאתר באגים תיפתר.

התאמה אישית של ה-build עם שכבות-על של משאבים

מערכת הבנייה של אנדרואיד משתמשת בשכבות-על של משאבים כדי להתאים אישית מוצר בזמן הבנייה. שכבות-על של משאבים מציינות קובצי משאבים המוחלים על ברירות המחדל. כדי להשתמש בשכבות-על של משאבים, שנה את קובץ build של הפרויקט כדי להגדיר את PRODUCT_PACKAGE_OVERLAYS לנתיב ביחס לספרייה ברמה העליונה שלך. נתיב זה הופך לשורש צל שמחפשים אותו יחד עם השורש הנוכחי כאשר מערכת ה-build מחפשת משאבים.

ההגדרות המותאמות אישית הנפוצות ביותר נמצאות במסגרות הקובץ/base/core/res/res/values/config.xml .

כדי להגדיר שכבת-על של משאב בקובץ זה, הוסף את ספריית שכבת-העל לקובץ build של הפרויקט באמצעות אחת מהפעולות הבאות:

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 כדי לראות איך כל זה מוגדר.

כתיבת קבצי מוצר

השלבים הבאים מתארים כיצד להגדיר קבצי makefile של מוצרים בצורה דומה לזו של קו המוצרים של Pixel:

1. צור ספריית device/ <company-name> / <device-name> עבור המוצר שלך. לדוגמה, device/google/marlin . ספרייה זו תכיל קוד מקור עבור המכשיר שלך יחד עם קבצי ה-make כדי לבנות אותם.
2. צור makefile device.mk שמצהיר על הקבצים והמודולים הדרושים למכשיר. לדוגמא, ראה 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 על קבצי המייקאפ של המוצר. בדוגמה זו, יש צורך רק בקובץ makefile של הגדרת המוצר. הדוגמה למטה היא מ- device/google/marlin/AndroidProducts.mk (המכיל גם את מרלין, את הפיקסל וגם את דג המפרש, ה-Pixel XL, שחלקו את רוב התצורה):

   PRODUCT_MAKEFILES := \
   	$(LOCAL_DIR)/aosp_marlin.mk \
   	$(LOCAL_DIR)/aosp_sailfish.mk
   
   COMMON_LUNCH_CHOICES := \
   	aosp_marlin-userdebug \
   	aosp_sailfish-userdebug
   

5. צור Makefile BoardConfig.mk המכיל תצורות ספציפיות ללוח. לדוגמא, ראה device/google/marlin/BoardConfig.mk .
6. עבור אנדרואיד 9 ומטה בלבד , צור קובץ vendorsetup.sh כדי להוסיף את המוצר שלך ("שילוב ארוחת צהריים") ל-build יחד עם גרסת בנייה מופרדת באמצעות מקף. לדוגמה:

   add_lunch_combo <product-name>-userdebug
   

7. בשלב זה, תוכל ליצור גרסאות נוספות של מוצר המבוססות על אותו מכשיר.

הגדרת משתני הגדרת המוצר

משתנים ספציפיים למוצר מוגדרים ב-makefile של המוצר. הטבלה מציגה חלק מהמשתנים המתוחזקים בקובץ הגדרת מוצר.

הגדרת שפת מערכת ברירת המחדל ומסנן מיקום

השתמש במידע זה כדי להגדיר את מסנן שפת ברירת המחדל ואת מסנן אזור המערכת, ולאחר מכן הפעל את מסנן המקום עבור סוג מכשיר חדש.

נכסים

הגדר הן את שפת ברירת המחדל והן את מסנן אזור המערכת באמצעות מאפייני מערכת ייעודיים:

• 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 מאפשר ליצרני מכשירים לגשת ל-builds הניתנים לאיפוי באגים (-userdebug ו-eng, אך לא -user) דרך adb ללא הרשאה ידנית. בדרך כלל 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 , מה שעוזר להבטיח שנזכור ליצור זוג מפתחות חדש עבור כל גרסת מערכת הפעלה.

להלן קובץ ה-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 אם הוא עדיין לא מוגדר.