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

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

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

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

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

שִׁכבָה דוגמא תיאור
מוצר myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk שכבת המוצר מגדירה את מפרט התכונות של מוצר משלוח כגון המודולים לבנייה, תמיכה במקומות ותצורה עבור מקומות שונים. במילים אחרות, זהו השם של המוצר הכולל. משתנים ספציפיים למוצר מוגדרים בקובצי הגדרות מוצר. מוצר יכול לרשת מהגדרות מוצר אחרות, מה שמפשט את התחזוקה. שיטה נפוצה היא ליצור מוצר בסיס המכיל תכונות החלות על כל המוצרים, ולאחר מכן ליצור גרסאות מוצר המבוססות על אותו מוצר בסיסי. לדוגמה, שני מוצרים הנבדלים זה מזה ברדיו (CDMA לעומת GSM) יכולים לרשת מאותו מוצר בסיס שאינו מגדיר רדיו.
לוח/מכשיר מרלין, בלואלין, אלמוגים שכבת הלוח/המכשיר מייצגת את שכבת הפלסטיק הפיזית במכשיר (כלומר העיצוב התעשייתי של המכשיר). שכבה זו מייצגת גם את הסכימות החשופות של המוצר. אלה כוללים את הציוד ההיקפי בלוח ותצורתם. השמות המשמשים הם רק קודים לתצורות לוח/התקנים שונות.
קֶשֶׁת זרוע, x86, arm64, x86_64 שכבת הארכיטקטורה מתארת ​​את תצורת המעבד ואת הממשק הבינארי של היישומים (ABI) הפועלים על הלוח.

שימוש בגרסאות build

כאשר בונים עבור מוצר מסוים, כדאי שיהיו וריאציות קטנות על מבנה המהדורה הסופית. בשנת הגדרה מודול, מודול יכול לציין תגים עם 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 צריכות להיות מוגדרות בבירור ולשתף אותן עם כל המפתחים שעובדים על הפרויקט. עליך להפעיל תכונות ניפוי באגים רק בזמן מוגבל עד שהבעיה שאתה מנסה לאתר באגים תיפתר.

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

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

הגדרות מותאמות אישית לרוב כלולים בקובץ מסגרות / בסיס / ליבה / 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 מיושמת עם בשם תצורת המכשיר העיקרי marlin . מתצורת התקן זו נוצר מוצר עם קובץ הגדרת מוצר המצהיר מידע ספציפי למוצר אודות המכשיר כגון השם והדגם. אתה יכול להציג את device/google/marlin ספרייה לראות איך כל זה מוגדר.

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

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

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