Gunakan informasi di halaman ini untuk membuat makefile untuk perangkat dan produk Anda.
Setiap modul Android baru harus memiliki file konfigurasi untuk mengarahkan sistem build dengan metadata modul, dependensi waktu kompilasi, dan instruksi pengemasan. Android menggunakan sistem build Soong . Lihat Membangun Android untuk informasi selengkapnya tentang sistem build Android.
Pahami lapisan build
Hirarki build mencakup lapisan abstraksi yang sesuai dengan susunan fisik perangkat. Lapisan-lapisan ini dijelaskan pada tabel di bawah ini. Setiap lapisan berhubungan dengan lapisan di atasnya dalam hubungan satu-ke-banyak. Misalnya, suatu arsitektur dapat memiliki lebih dari satu papan dan setiap papan dapat memiliki lebih dari satu produk. Anda dapat mendefinisikan elemen di lapisan tertentu sebagai spesialisasi elemen di lapisan yang sama, sehingga menghilangkan penyalinan dan menyederhanakan pemeliharaan.
Lapisan | Contoh | Keterangan |
---|---|---|
Produk | Produk saya, Produk saya_eu, Produk saya_eu_fr, j2, SDK | Lapisan produk mendefinisikan spesifikasi fitur produk pengiriman seperti modul yang akan dibuat, lokal yang didukung, dan konfigurasi untuk berbagai lokal. Dengan kata lain, ini adalah nama produk secara keseluruhan. Variabel khusus produk didefinisikan dalam makefile definisi produk. Suatu produk dapat mewarisi definisi produk lain, sehingga menyederhanakan pemeliharaan. Cara yang umum dilakukan adalah dengan membuat produk dasar yang berisi fitur-fitur yang berlaku untuk semua produk, kemudian membuat varian produk berdasarkan produk dasar tersebut. Misalnya, dua produk yang hanya berbeda berdasarkan radionya (CDMA versus GSM) dapat mewarisi produk dasar yang sama yang tidak mendefinisikan radio. |
Papan/perangkat | marlin, garis biru, karang | Lapisan papan/perangkat mewakili lapisan fisik plastik pada perangkat (yaitu, desain industri perangkat). Lapisan ini juga mewakili skema telanjang suatu produk. Ini termasuk periferal di papan dan konfigurasinya. Nama yang digunakan hanyalah kode untuk konfigurasi papan/perangkat yang berbeda. |
Lengkungan | lengan, x86, lengan64, x86_64 | Lapisan arsitektur menjelaskan konfigurasi prosesor dan antarmuka biner aplikasi (ABI) yang berjalan di papan. |
Gunakan varian build
Saat membuat produk tertentu, ada gunanya memiliki sedikit variasi pada versi rilis akhir. Dalam definisi modul, modul dapat menentukan tag dengan LOCAL_MODULE_TAGS
, yang dapat berupa satu atau lebih nilai optional
(default), debug
, dan eng
.
Jika modul tidak menentukan tag (menurut LOCAL_MODULE_TAGS
), tag defaultnya adalah optional
. Modul opsional dipasang hanya jika diperlukan oleh konfigurasi produk dengan PRODUCT_PACKAGES
.
Ini adalah varian build yang ditentukan saat ini.
Varian | Keterangan |
---|---|
eng | Ini adalah rasa default.
|
user | Varian tersebut dimaksudkan sebagai bit rilis final.
|
userdebug | Sama seperti user , dengan pengecualian berikut:
|
Pedoman untuk debug pengguna
Menjalankan build userdebug dalam pengujian membantu pengembang perangkat memahami kinerja dan kekuatan rilis dalam pengembangan. Untuk menjaga konsistensi antara build pengguna dan userdebug, dan untuk mencapai metrik yang andal dalam build yang digunakan untuk proses debug, pengembang perangkat harus mengikuti panduan berikut:
- userdebug didefinisikan sebagai build pengguna dengan akses root diaktifkan, kecuali:
- aplikasi khusus debug pengguna yang dijalankan hanya sesuai permintaan oleh pengguna
- Operasi yang berjalan hanya selama pemeliharaan menganggur (saat pengisi daya/terisi penuh), seperti menggunakan
dex2oatd
versusdex2oat
untuk kompilasi latar belakang
- Jangan sertakan fitur yang diaktifkan/dinonaktifkan secara default berdasarkan jenis build. Pengembang tidak disarankan menggunakan segala bentuk logging yang memengaruhi masa pakai baterai, seperti logging debug atau heap dumping.
- Fitur debugging apa pun yang diaktifkan secara default di userdebug harus didefinisikan dengan jelas dan dibagikan kepada semua pengembang yang mengerjakan proyek. Anda harus mengaktifkan fitur debug hanya dalam waktu terbatas hingga masalah yang Anda coba debug teratasi.
Sesuaikan build dengan hamparan sumber daya
Sistem pembangunan Android menggunakan hamparan sumber daya untuk menyesuaikan produk pada waktu pembangunan. Hamparan sumber daya menentukan file sumber daya yang diterapkan di atas default. Untuk menggunakan hamparan sumber daya, ubah file build proyek untuk menyetel PRODUCT_PACKAGE_OVERLAYS
ke jalur yang berhubungan dengan direktori tingkat teratas Anda. Jalur tersebut menjadi akar bayangan yang dicari bersama dengan akar saat ini ketika sistem pembangunan mencari sumber daya.
Pengaturan yang paling umum disesuaikan terdapat dalam file frameworks/base/core/res/res/values/config.xml .
Untuk menyiapkan overlay sumber daya pada file ini, tambahkan direktori overlay ke file build proyek menggunakan salah satu hal berikut:
PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay
atau
PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay
Kemudian tambahkan file overlay ke direktori, misalnya:
vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml
Setiap string atau array string yang ditemukan di file overlay config.xml
menggantikan yang ditemukan di file asli.
Membangun sebuah produk
Anda dapat mengatur file sumber untuk perangkat Anda dengan berbagai cara. Berikut penjelasan singkat tentang salah satu cara mengatur implementasi Pixel.
Pixel diimplementasikan dengan konfigurasi perangkat utama bernama marlin
. Dari konfigurasi perangkat ini, produk dibuat dengan makefile definisi produk yang menyatakan informasi spesifik produk tentang perangkat seperti nama dan model. Anda dapat melihat direktori device/google/marlin
untuk melihat bagaimana semua ini diatur.
Tulis makefile produk
Langkah-langkah berikut menjelaskan cara menyiapkan makefile produk dengan cara yang mirip dengan lini produk Pixel:
- Buat direktori
device/ <company-name> / <device-name>
untuk produk Anda. Misalnya,device/google/marlin
. Direktori ini akan berisi kode sumber untuk perangkat Anda beserta makefile untuk membuatnya. - Buat makefile
device.mk
yang mendeklarasikan file dan modul yang diperlukan untuk perangkat. Misalnya, lihatdevice/google/marlin/device-marlin.mk
. - Buat makefile definisi produk untuk membuat produk tertentu berdasarkan perangkat. Makefile berikut diambil dari
device/google/marlin/aosp_marlin.mk
sebagai contoh. Perhatikan bahwa produk mewarisi filedevice/google/marlin/device-marlin.mk
danvendor/google/marlin/device-vendor-marlin.mk
melalui makefile sekaligus mendeklarasikan informasi khusus produk seperti nama, merek, dan model.# 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
Lihat Menetapkan variabel definisi produk untuk variabel khusus produk tambahan yang dapat Anda tambahkan ke makefile Anda.
- Buat file
AndroidProducts.mk
yang mengarah ke makefile produk. Dalam contoh ini, hanya makefile definisi produk yang diperlukan. Contoh di bawah ini berasal daridevice/google/marlin/AndroidProducts.mk
(yang berisi marlin, Pixel, dan ikan layar, Pixel XL, yang memiliki sebagian besar konfigurasi):PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/aosp_marlin.mk \ $(LOCAL_DIR)/aosp_sailfish.mk COMMON_LUNCH_CHOICES := \ aosp_marlin-userdebug \ aosp_sailfish-userdebug
- Buat makefile
BoardConfig.mk
yang berisi konfigurasi khusus board. Misalnya, lihatdevice/google/marlin/BoardConfig.mk
. - Khusus untuk Android 9 dan yang lebih rendah , buat file
vendorsetup.sh
untuk menambahkan produk Anda ("kombo makan siang") ke build bersama dengan varian build yang dipisahkan dengan tanda hubung. Misalnya:add_lunch_combo <product-name>-userdebug
- Pada tahap ini, Anda dapat membuat lebih banyak varian produk berdasarkan perangkat yang sama.
Tetapkan variabel definisi produk
Variabel khusus produk ditentukan dalam makefile produk. Tabel ini menunjukkan beberapa variabel yang disimpan dalam file definisi produk.
Variabel | Keterangan | Contoh |
---|---|---|
PRODUCT_AAPT_CONFIG | konfigurasi aapt untuk digunakan saat membuat paket. | |
PRODUCT_BRAND | Merek (misalnya, operator) yang disesuaikan dengan perangkat lunak tersebut. | |
PRODUCT_CHARACTERISTICS | karakteristik aapt untuk memungkinkan penambahan sumber daya khusus varian ke sebuah paket. | tablet , nosdcard |
PRODUCT_COPY_FILES | Daftar kata-kata seperti source_path:destination_path . File di jalur sumber harus disalin ke jalur tujuan saat membuat produk ini. Aturan untuk langkah penyalinan ditentukan di config/makefile . | |
PRODUCT_DEVICE | Nama desain industri. Ini juga merupakan nama papan, dan sistem pembangunan menggunakannya untuk menemukan lokasi BoardConfig.mk . | tuna |
PRODUCT_LOCALES | Daftar kode bahasa dua huruf, pasangan kode negara dua huruf yang dipisahkan spasi yang menjelaskan beberapa pengaturan untuk pengguna, seperti bahasa UI dan waktu, tanggal, serta format mata uang. Lokal pertama yang tercantum dalam PRODUCT_LOCALES digunakan sebagai lokal default produk. | en_GB , de_DE , es_ES , fr_CA |
PRODUCT_MANUFACTURER | Nama pabrikan. | acme |
PRODUCT_MODEL | Nama produk akhir yang terlihat oleh pengguna akhir. | |
PRODUCT_NAME | Nama yang terlihat oleh pengguna akhir untuk keseluruhan produk. Muncul di layar Pengaturan > Tentang . | |
PRODUCT_OTA_PUBLIC_KEYS | Daftar kunci publik over-the-air (OTA) untuk produk. | |
PRODUCT_PACKAGES | Daftar APK dan modul yang akan diinstal. | Kontak kalender |
PRODUCT_PACKAGE_OVERLAYS | Menunjukkan apakah akan menggunakan sumber daya default atau menambahkan overlay khusus produk. | vendor/acme/overlay |
PRODUCT_SYSTEM_PROPERTIES | Daftar penetapan properti sistem dalam format "key=value" untuk partisi sistem. Properti sistem untuk partisi lain dapat diatur melalui PRODUCT_<PARTITION>_PROPERTIES seperti pada PRODUCT_VENDOR_PROPERTIES untuk partisi vendor. Nama partisi yang didukung: SYSTEM , VENDOR , ODM , SYSTEM_EXT , dan PRODUCT . |
Konfigurasikan bahasa sistem default dan filter lokal
Gunakan informasi ini untuk mengonfigurasi bahasa default dan filter lokal sistem, lalu mengaktifkan filter lokal untuk jenis perangkat baru.
Properti
Konfigurasikan bahasa default dan filter lokal sistem menggunakan properti sistem khusus:
-
ro.product.locale
: untuk menyetel lokal default. Ini awalnya disetel ke lokal pertama dalam variabelPRODUCT_LOCALES
; Anda dapat mengganti nilai itu. (Untuk informasi selengkapnya, lihat tabel Mengatur variabel definisi produk .) -
ro.localization.locale_filter
: untuk menyetel filter lokal, menggunakan ekspresi reguler yang diterapkan pada nama lokal. Misalnya:- Filter inklusif:
^(de-AT|de-DE|en|uk).*
- hanya mengizinkan bahasa Jerman (varian Austria dan Jerman), semua varian bahasa Inggris dari bahasa Inggris, dan bahasa Ukraina - Filter eksklusif:
^(?!de-IT|es).*
- tidak termasuk bahasa Jerman (varian Italia), dan semua varian bahasa Spanyol.
- Filter inklusif:
Aktifkan filter lokal
Untuk mengaktifkan filter, setel nilai string properti sistem ro.localization.locale_filter
.
Dengan mengatur nilai properti filter dan bahasa default melalui oem/oem.prop
selama kalibrasi pabrik, Anda dapat mengonfigurasi pembatasan tanpa memasukkan filter ke dalam image sistem. Anda memastikan bahwa properti ini diambil dari partisi OEM dengan menambahkannya ke variabel PRODUCT_OEM_PROPERTIES
seperti yang ditunjukkan di bawah ini:
# Delegation for OEM customization PRODUCT_OEM_PROPERTIES += \ ro.product.locale \ ro.localization.locale_filter
Kemudian dalam produksi, nilai aktual ditulis ke oem/oem.prop
, untuk mencerminkan persyaratan target. Dengan pendekatan ini, nilai default dipertahankan selama reset pabrik, sehingga pengaturan awal terlihat persis seperti pengaturan pertama bagi pengguna.
Setel ADB_VENDOR_KEYS untuk terhubung melalui USB
Variabel lingkungan ADB_VENDOR_KEYS
memungkinkan produsen perangkat mengakses build yang dapat di-debug (-userdebug dan -eng, tetapi bukan -user) melalui adb tanpa otorisasi manual. Biasanya adb menghasilkan kunci otentikasi RSA unik untuk setiap komputer klien, yang akan dikirimkan ke perangkat mana pun yang terhubung. Ini adalah kunci RSA yang ditampilkan dalam dialog otorisasi adb. Sebagai alternatif, Anda dapat memasukkan kunci yang diketahui ke dalam citra sistem dan membaginya dengan klien adb. Hal ini berguna untuk pengembangan OS dan khususnya untuk pengujian karena menghindari kebutuhan untuk berinteraksi secara manual dengan dialog otorisasi adb.
Untuk membuat kunci vendor, satu orang (biasanya manajer rilis) harus:
- Hasilkan pasangan kunci menggunakan
adb keygen
. Untuk perangkat Google, Google membuat pasangan kunci baru untuk setiap versi OS baru. - Periksa pasangan kunci, di suatu tempat di pohon sumber. Google menyimpannya di
vendor/google/security/adb/
, misalnya. - Setel variabel build
PRODUCT_ADB_KEYS
agar mengarah ke direktori kunci Anda. Google melakukan ini dengan menambahkan fileAndroid.mk
di direktori kunci yang bertuliskanPRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub
, yang membantu memastikan bahwa kita ingat untuk membuat pasangan kunci baru untuk setiap versi OS.
Inilah makefile yang digunakan Google di direktori tempat kami menyimpan pasangan kunci yang kami check-in untuk setiap rilis:
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
Untuk menggunakan kunci vendor ini, teknisi hanya perlu mengatur variabel lingkungan ADB_VENDOR_KEYS
agar mengarah ke direktori tempat pasangan kunci disimpan. Ini memberitahu adb
untuk mencoba kunci kanonik ini terlebih dahulu, sebelum kembali ke kunci host yang dihasilkan yang memerlukan otorisasi manual. Ketika adb
tidak dapat terhubung ke perangkat yang tidak sah, pesan kesalahan akan menyarankan Anda menyetel ADB_VENDOR_KEYS
jika belum disetel.