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

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

افزودن یک دستگاه جدید

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