از اطلاعات موجود در این صفحه برای ایجاد فایلهای سازنده برای دستگاه و محصول خود استفاده کنید.
هر ماژول جدید Android باید دارای یک فایل پیکربندی باشد تا سیستم ساخت را با فراداده ماژول ، وابستگی های زمان کامپایل و دستورالعمل های بسته بندی هدایت کند. آندروید با استفاده از سیستم ساخت Soong . مشاهده ساختمانی آندروید برای اطلاعات بیشتر در مورد سیستم ساخت اندیشه.
درک لایه های ساخت
سلسله مراتب ساخت شامل لایه های انتزاعی است که با ساختار فیزیکی یک دستگاه مطابقت دارد. این لایه ها در جدول زیر توضیح داده شده است. هر لایه به لایه ای که در بالای آن قرار دارد در رابطه ای یک به چند مربوط می شود. به عنوان مثال ، یک معماری می تواند بیش از یک تخته و هر تخته می تواند بیش از یک محصول داشته باشد. شما می توانید یک عنصر در یک لایه معین را به عنوان تخصصی از یک عنصر در همان لایه تعریف کنید ، که کپی را حذف کرده و نگهداری را ساده می کند.
لایه | مثال | شرح |
---|---|---|
تولید - محصول | 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 | این طعم پیش فرض است.
|
user | نسخه مورد نظر بیت های انتشار نهایی است.
|
userdebug | همان user ، با این استثنا:
|
دستورالعمل های مربوط به اشکال زدایی کاربر
اجرای آزمایشی userdebug به توسعه دهندگان دستگاه کمک می کند تا عملکرد و قدرت نسخه های در حال توسعه را درک کنند. برای حفظ سازگاری بین ساختارهای کاربر و userdebug و دستیابی به معیارهای قابل اعتماد در ساختارهایی که برای اشکال زدایی استفاده می شود ، توسعه دهندگان دستگاه باید این دستورالعمل ها را دنبال کنند:
- userdebug به عنوان ساخت کاربر با دسترسی فعال ریشه تعریف می شود ، به جز موارد زیر:
- برنامه های فقط userdebug که فقط در صورت درخواست توسط کاربر اجرا می شوند
- عملیات که تنها در طول نگهداری بیکار اجرا (در شارژر / به طور کامل شارژ)، مانند استفاده از
dex2oatd
مقابلdex2oat
برای کامپایل پس زمینه
- ویژگی هایی را که به طور پیش فرض بر اساس نوع ساخت فعال/غیرفعال هستند ، وارد نکنید. توسعه دهندگان از استفاده از هر گونه ورود به سیستم که بر عمر باتری تأثیر می گذارد ، مانند اشکال زدایی اشکال زدایی یا تخلیه پشته دلسرد می شوند.
- هر گونه اشکال زدایی که به طور پیش فرض در userdebug فعال است باید به وضوح تعریف شده و با همه توسعه دهندگان که روی پروژه کار می کنند به اشتراک گذاشته شود. شما باید ویژگیهای اشکال زدایی را فقط به صورت محدود فعال کنید تا زمانی که مشکلی که می خواهید اشکال زدایی برطرف شود حل شود.
سفارشی سازی ساختار با همپوشانی منابع
سیستم ساخت آندروید برای سفارشی سازی محصول در زمان ساخت از پوشش های منابع استفاده می کند. همپوشانی منابع فایل های منبع را که در بالای پیش فرض ها اعمال می شوند ، مشخص می کند. برای استفاده از پوشش منابع، تغییر buildfile پروژه به مجموعه ای PRODUCT_PACKAGE_OVERLAYS
به یک مسیر نسبت به دایرکتوری سطح بالا خود را. هنگامی که سیستم build منابع را جستجو می کند ، این مسیر به ریشه سایه ای تبدیل می شود که همراه با ریشه فعلی جستجو می شود.
تنظیمات رایج ترین سفارشی در فایل موجود چارچوب / پایه / هسته ای / RES / فایل res / values / config.xml را .
برای تنظیم همپوشانی منابع بر روی این فایل ، فهرست پوشه را با استفاده از یکی از موارد زیر به buildfile پروژه اضافه کنید:
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
جایگزینی فایل کسانی که در فایل اصلی.
ساختن یک محصول
می توانید فایلهای منبع دستگاه خود را به روشهای مختلف سازماندهی کنید. در اینجا شرح مختصری از یک راه برای سازماندهی پیاده سازی پیکسل آمده است.
پیکسل با یک پیکربندی دستگاه اصلی به نام اجرا marlin
. از این پیکربندی دستگاه ، محصولی با makefile تعریف محصول ایجاد می شود که اطلاعات مربوط به محصول در مورد دستگاه مانند نام و مدل را اعلام می کند. شما می توانید مشاهده و device/google/marlin
دایرکتوری تا ببینید که چگونه همه از این است راه اندازی.
نوشتن آرایشهای محصول
مراحل زیر نحوه تنظیم گرایش محصولات به روشی مشابه خط تولید Pixel را شرح می دهد:
- درست
device/ <company-name> / <device-name>
دایرکتوری برای محصول خود را. به عنوان مثال،device/google/marlin
. این فهرست شامل کد منبع دستگاه شما به همراه makefiles برای ساخت آنها می باشد. - درست
device.mk
makefile در که اعلام فایل ها و ماژول های مورد نیاز برای دستگاه. برای مثال، وdevice/google/marlin/device-marlin.mk
. - ایجاد یک 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
مشاهده تنظیم متغیرهای تعریف محصول برای متغیرهای کالا مشخص اضافی که شما می توانید به Makefile ها خود را اضافه کنید.
- ایجاد یک
AndroidProducts.mk
فایل است که امتیاز به Makefile ها محصول است. در این مثال ، فقط 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
- درست
BoardConfig.mk
makefile در که شامل تنظیمات هیئت مدیره خاص. برای مثال، وdevice/google/marlin/BoardConfig.mk
. - برای آندروید 9 و تنها کاهش، ایجاد یک
vendorsetup.sh
فایل برای اضافه کردن محصول خود را (یک "دسته کوچک موسیقی جاز ناهار") به ساخت همراه با یک نوع ساخت آن یک خط تیره از هم جدا. به عنوان مثال:add_lunch_combo <product-name>-userdebug
- در این مرحله ، می توانید انواع محصول بیشتری را بر اساس یک دستگاه ایجاد کنید.
تنظیم متغیرهای تعریف محصول
متغیرهای خاص محصول در 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، اما نه کاربر) بیش از ADB بدون مجوز کتابچه راهنمای کاربر. به طور معمول adb یک کلید احراز هویت RSA منحصر به فرد برای هر رایانه مشتری ایجاد می کند ، که آن را به هر دستگاه متصل ارسال می کند. این کلید RSA است که در گفتگوی مجوز adb نشان داده شده است. به عنوان جایگزین ، می توانید کلیدهای شناخته شده را در تصویر سیستم ایجاد کرده و آنها را با سرویس گیرنده adb به اشتراک بگذارید. این برای توسعه سیستم عامل و به ویژه برای آزمایش مفید است زیرا از نیاز به تعامل دستی با گفتگوی مجوز adb جلوگیری می کند.
برای ایجاد کلیدهای فروشنده ، یک نفر (معمولاً مدیر انتشار) باید:
- ایجاد یک جفت کلید با استفاده از
adb keygen
. برای دستگاه های Google ، Google برای هر نسخه سیستم عامل جدید یک جفت کلید جدید ایجاد می کند. - جفت کلیدها را در جایی در درخت منبع بررسی کنید. فروشگاه های گوگل آنها را در
vendor/google/security/adb/
، برای مثال. - تنظیم متغیر ساخت
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
اگر در حال تنظیم نشده است.