از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.

این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

یک دستگاه جدید اضافه کنید

از اطلاعات موجود در این صفحه برای ایجاد فایل‌های سازنده (makefiles) برای دستگاه و محصول خود استفاده کنید.

هر ماژول جدید اندروید باید یک فایل پیکربندی داشته باشد تا سیستم ساخت را با ابرداده‌های ماژول، وابستگی‌های زمان کامپایل و دستورالعمل‌های بسته‌بندی هدایت کند. اندروید از سیستم ساخت 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`	این طعم پیش‌فرض است. ماژول‌هایی که با `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 در حین آزمایش به توسعه‌دهندگان دستگاه کمک می‌کند تا عملکرد و قدرت نسخه‌های در حال توسعه را درک کنند. برای حفظ سازگاری بین نسخه‌های user و userdebug و دستیابی به معیارهای قابل اعتماد در نسخه‌های مورد استفاده برای اشکال‌زدایی، توسعه‌دهندگان دستگاه باید این دستورالعمل‌ها را دنبال کنند:

userdebug به عنوان یک ساخت کاربر با دسترسی ریشه فعال تعریف می‌شود، به جز:
- برنامه‌های فقط اشکال‌زدایی کاربر که فقط بنا به درخواست کاربر اجرا می‌شوند
- عملیاتی که فقط در زمان تعمیر و نگهداری غیرفعال (با شارژر/شارژ کامل) اجرا می‌شوند، مانند استفاده از dex2oatd در مقابل dex2oat برای کامپایل‌های پس‌زمینه
ویژگی‌هایی را که به طور پیش‌فرض بر اساس نوع ساخت فعال/غیرفعال هستند، لحاظ نکنید. توسعه‌دهندگان از استفاده از هر نوع گزارش‌گیری که بر عمر باتری تأثیر می‌گذارد، مانند گزارش‌گیری اشکال‌زدایی یا تخلیه پشته، منع می‌شوند.
هر ویژگی اشکال‌زدایی که به طور پیش‌فرض در 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

هر رشته یا آرایه رشته‌ای که در فایل config.xml لایه پوششی یافت شود، جایگزین موارد موجود در فایل اصلی می‌شود.

ساخت یک محصول

شما می‌توانید فایل‌های منبع دستگاه خود را به روش‌های مختلفی سازماندهی کنید. در اینجا توضیح مختصری از یک روش سازماندهی پیاده‌سازی Pixel ارائه شده است.

پیکسل با پیکربندی دستگاه اصلی به نام marlin پیاده‌سازی شده است. از این پیکربندی دستگاه، یک محصول با یک فایل تعریف محصول ایجاد می‌شود که اطلاعات خاص محصول در مورد دستگاه مانند نام و مدل را اعلام می‌کند. می‌توانید دایرکتوری device/google/marlin را مشاهده کنید تا ببینید چگونه همه این موارد تنظیم شده‌اند.

نوشتن فایل‌های ساخت محصول

مراحل زیر نحوه تنظیم فایل‌های ساخت محصول را به روشی مشابه خط تولید پیکسل شرح می‌دهد:

یک دایرکتوری device/ <company-name> / <device-name> برای محصول خود ایجاد کنید. برای مثال، device/google/marlin . این دایرکتوری شامل کد منبع دستگاه شما به همراه فایل‌های makefile برای ساخت آنها خواهد بود.
یک فایل makefile با نام device.mk ایجاد کنید که فایل‌ها و ماژول‌های مورد نیاز دستگاه را تعریف کند. برای مثال، به device/google/marlin/device-marlin.mk مراجعه کنید.
برای ایجاد یک محصول خاص بر اساس دستگاه، یک فایل makefile تعریف محصول ایجاد کنید. فایل makefile زیر به عنوان مثال از device/google/marlin/aosp_marlin.mk گرفته شده است. توجه داشته باشید که محصول از طریق فایل makefile از فایل‌های device/google/marlin/device-marlin.mk و vendor/google/marlin/device-vendor-marlin.mk ارث بری می‌کند و در عین حال اطلاعات خاص محصول مانند نام، برند و مدل را نیز اعلام می‌کند.
```
# 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 گرفته شده است (که شامل 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
```
یک فایل ساخت BoardConfig.mk ایجاد کنید که شامل پیکربندی‌های مخصوص برد باشد. برای مثال، به device/google/marlin/BoardConfig.mk مراجعه کنید.
فقط برای اندروید ۹ و پایین‌تر ، یک فایل vendorsetup.sh ایجاد کنید تا محصول خود (یک "lunch combo") را به همراه یک نسخه از نسخه قبلی که با خط تیره از هم جدا شده است، به نسخه نهایی اضافه کنید. برای مثال:
```
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 ، همانطور که در زیر نشان داده شده است، اطمینان حاصل می‌کنید که از پارتیشن 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 به تولیدکنندگان دستگاه این امکان را می‌دهد که بدون نیاز به مجوز دستی، به نسخه‌های قابل اشکال‌زدایی (-userdebug و -eng، اما نه -user) از طریق adb دسترسی داشته باشند. معمولاً adb برای هر رایانه کلاینت یک کلید احراز هویت RSA منحصر به فرد تولید می‌کند که آن را به هر دستگاه متصل ارسال می‌کند. این کلید RSA در کادر محاوره‌ای مجوز adb نشان داده شده است. به عنوان یک جایگزین، می‌توانید کلیدهای شناخته شده را در تصویر سیستم ایجاد کرده و آنها را با کلاینت adb به اشتراک بگذارید. این برای توسعه سیستم عامل و به ویژه برای آزمایش مفید است زیرا از نیاز به تعامل دستی با کادر محاوره‌ای مجوز adb جلوگیری می‌کند.

برای ایجاد کلیدهای فروشنده، یک نفر (معمولاً یک مدیر انتشار) باید:

با استفاده از adb keygen یک جفت کلید ایجاد کنید. برای دستگاه‌های گوگل، گوگل برای هر نسخه جدید سیستم عامل، یک جفت کلید جدید تولید می‌کند.
جفت کلیدها را در جایی از درخت منبع بررسی کنید. به عنوان مثال، گوگل آنها را در vendor/google/security/adb/ ذخیره می‌کند.
متغیر ساخت PRODUCT_ADB_KEYS را طوری تنظیم کنید که به دایرکتوری کلید شما اشاره کند. گوگل این کار را با اضافه کردن یک فایل Android.mk در دایرکتوری کلید که عبارت PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub را دارد، انجام می‌دهد، که به ما کمک می‌کند تا مطمئن شویم که برای هر نسخه سیستم عامل، یک جفت کلید جدید ایجاد می‌کنیم.

این فایل makefile ای است که گوگل در دایرکتوری که جفت کلیدهای بررسی شده خود را برای هر نسخه ذخیره می‌کنیم، استفاده می‌کند:

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 تنظیم کنید، اگر قبلاً تنظیم نشده باشد.