از اطلاعات موجود در این صفحه برای ایجاد فایل های makefi برای دستگاه و محصول خود استفاده کنید.
هر ماژول جدید اندروید باید دارای یک فایل پیکربندی برای هدایت سیستم ساخت با فراداده های ماژول، وابستگی های زمان کامپایل و دستورالعمل های بسته بندی باشد. اندروید از سیستم ساخت 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 به عنوان یک ساخت کاربر با دسترسی روت فعال تعریف می شود، به جز:
- برنامههایی که فقط کاربر اشکال دارند که فقط بر اساس درخواست کاربر اجرا میشوند
- عملیاتی که فقط در حین تعمیر و نگهداری بیحرکت (در شارژر/کاملا شارژ) اجرا میشوند، مانند استفاده از
dex2oatd
در مقابلdex2oat
برای کامپایلهای پسزمینه
- ویژگیهایی را که به طور پیشفرض بر اساس نوع ساخت فعال/غیرفعال میشوند، درج نکنید. توسعهدهندگان از استفاده از هر شکلی از گزارشگیری که بر عمر باتری تأثیر میگذارد، مانند گزارشگیری اشکالزدایی یا heap dumping، دلسرد میشوند.
- هر ویژگی اشکال زدایی که به طور پیش فرض در userdebug فعال می شود باید به وضوح تعریف شده و با همه توسعه دهندگانی که روی پروژه کار می کنند به اشتراک گذاشته شود. باید ویژگیهای اشکالزدایی را فقط به صورت محدود فعال کنید تا زمانی که مشکلی که میخواهید اشکالزدایی کنید برطرف شود.
ساخت را با همپوشانی منابع سفارشی کنید
سیستم ساخت اندروید از همپوشانی منابع برای سفارشی کردن یک محصول در زمان ساخت استفاده می کند. پوششهای منابع، فایلهای منبعی را مشخص میکنند که در بالای پیشفرضها اعمال میشوند. برای استفاده از همپوشانی منابع، فایل ساخت پروژه را تغییر دهید تا 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
هر رشته یا آرایه رشته ای که در فایل overlay config.xml
یافت می شود جایگزین رشته های موجود در فایل اصلی می شود.
یک محصول بسازید
شما می توانید فایل های منبع را برای دستگاه خود به روش های مختلف سازماندهی کنید. در اینجا توضیح مختصری از یکی از راههای سازماندهی پیادهسازی Pixel آمده است.
پیکسل با پیکربندی دستگاه اصلی به نام marlin
پیاده سازی شده است. از پیکربندی این دستگاه، یک محصول با یک فایل ساخت تعریف محصول ایجاد میشود که اطلاعات خاص محصول را درباره دستگاه مانند نام و مدل اعلام میکند. میتوانید دایرکتوری device/google/marlin
را مشاهده کنید تا ببینید همه اینها چگونه تنظیم شدهاند.
فایل های ساخت محصول را بنویسید
مراحل زیر نحوه راهاندازی فایلهای سازنده محصول را به روشی مشابه با خط محصول Pixel شرح میدهد:
- دایرکتوری
device/ <company-name> / <device-name>
برای محصول خود ایجاد کنید. به عنوان مثال،device/google/marlin
. این دایرکتوری حاوی کد منبع برای دستگاه شما به همراه فایل های ساخت آنها خواهد بود. - یک فایل make-file
device.mk
ایجاد کنید که فایل ها و ماژول های مورد نیاز دستگاه را اعلام می کند. برای مثال،device/google/marlin/device-marlin.mk
را ببینید. - برای ایجاد یک محصول خاص بر اساس دستگاه، یک فایل تعریف محصول ایجاد کنید. فایل make زیر به عنوان نمونه از
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
به تنظیم متغیرهای تعریف محصول برای متغیرهای خاص محصول اضافی که میتوانید به فایلهای ساخت خود اضافه کنید، مراجعه کنید.
- یک فایل
AndroidProducts.mk
ایجاد کنید که به فایلهای ساخت محصول اشاره میکند. در این مثال، فقط به فایل تعریف محصول نیاز است. مثال زیر ازdevice/google/marlin/AndroidProducts.mk
است (که شامل هر دو مارلین، پیکسل و sailfish، Pixel XL است که بیشترین پیکربندی را دارد):PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/aosp_marlin.mk \ $(LOCAL_DIR)/aosp_sailfish.mk COMMON_LUNCH_CHOICES := \ aosp_marlin-userdebug \ aosp_sailfish-userdebug
- یک فایل میک
BoardConfig.mk
ایجاد کنید که حاوی پیکربندی های مخصوص تخته باشد. برای مثال،device/google/marlin/BoardConfig.mk
را ببینید. - فقط برای Android 9 و پایینتر ، یک فایل
vendorsetup.sh
ایجاد کنید تا محصول خود (یک ترکیب ناهار) را به همراه یک نوع ساخت که با یک خط تیره جدا شده است، به آن اضافه کنید. به عنوان مثال:add_lunch_combo <product-name>-userdebug
- در این مرحله، می توانید انواع محصولات بیشتری را بر اساس همان دستگاه ایجاد کنید.
متغیرهای تعریف محصول را تنظیم کنید
متغیرهای خاص محصول در فایل ساخت محصول تعریف شده است. جدول برخی از متغیرهای نگهداری شده در فایل تعریف محصول را نشان می دهد.
متغیر | توضیحات | مثال |
---|---|---|
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
همانطور که در زیر نشان داده شده است، اطمینان حاصل می کنید که این ویژگی ها از پارتیشن OEM انتخاب می شوند:
# Delegation for OEM customization PRODUCT_OEM_PROPERTIES += \ ro.product.locale \ ro.localization.locale_filter
سپس در تولید، مقادیر واقعی به oem/oem.prop
نوشته میشوند تا نیازمندیهای هدف را منعکس کنند. با این رویکرد، مقادیر پیشفرض در طول بازنشانی کارخانه حفظ میشوند، بنابراین تنظیمات اولیه دقیقاً مانند تنظیمات اولیه برای کاربر به نظر میرسد.
ADB_VENDOR_KEYS را برای اتصال از طریق USB تنظیم کنید
متغیر محیطی ADB_VENDOR_KEYS
سازندگان دستگاه را قادر میسازد تا به ساختهای قابل اشکالزدایی (-userdbug و -eng، اما نه -user) از طریق adb بدون مجوز دستی دسترسی داشته باشند. معمولاً adb برای هر رایانه مشتری یک کلید تأیید اعتبار RSA منحصر به فرد ایجاد می کند که آن را به هر دستگاه متصل ارسال می کند. این کلید RSA است که در گفتگوی مجوز adb نشان داده شده است. به عنوان یک جایگزین، می توانید کلیدهای شناخته شده را در تصویر سیستم بسازید و آنها را با مشتری adb به اشتراک بگذارید. این برای توسعه سیستم عامل و به ویژه برای آزمایش مفید است زیرا از نیاز به تعامل دستی با گفتگوی مجوز adb جلوگیری می کند.
برای ایجاد کلیدهای فروشنده، یک نفر (معمولاً یک مدیر انتشار) باید:
- با استفاده از
adb keygen
یک جفت کلید ایجاد کنید. برای دستگاههای Google، 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
را تنظیم کنید، اگر قبلاً تنظیم نشده است.