Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Tambahkan perangkat baru

Gunakan informasi di halaman ini untuk membuat makefile untuk perangkat Anda dan Google.

Setiap modul Android baru harus memiliki file konfigurasi untuk mengarahkan sistem build dengan metadata modul, dependensi waktu kompilasi, dan petunjuk pengemasan. Android menggunakan Sistem build segera. Lihat Membangun Android untuk mengetahui informasi selengkapnya tentang Android sistem build.

Memahami lapisan build

Hierarki build mencakup lapisan abstraksi yang sesuai dengan struktur fisik dari sebuah perangkat. Lapisan ini dijelaskan dalam tabel di bawah. Setiap lapisan berkaitan dengan lapisan di atasnya dalam hubungan {i>one-to-many<i}. Sebagai sebuah arsitektur dapat memiliki lebih dari satu papan dan setiap papan dapat memiliki lebih dari satu produk. Anda dapat mendefinisikan sebuah elemen di lapisan tertentu sebagai spesialisasi elemen pada lapisan yang sama, yang menghilangkan penyalinan dan menyederhanakan pemeliharaan.

Layer	Contoh	Deskripsi
Produk	myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk	Lapisan produk menentukan spesifikasi fitur pengiriman seperti modul untuk dibangun, lokalitas yang didukung, dan untuk berbagai lokalitas. Dengan kata lain, ini adalah name dari keseluruhan produk. Variabel khusus produk ditentukan dalam makefile definisi produk. Sebuah produk dapat mewarisi dari definisi produk, sehingga menyederhanakan pemeliharaan. Metode umum adalah untuk membuat produk dasar yang berisi fitur yang berlaku untuk semua produk, kemudian buat varian produk berdasarkan basis tersebut Google. Misalnya, dua produk yang hanya berbeda pada radio mereka (CDMA versus GSM) dapat mewarisi dari produk dasar yang sama yang tidak mendefinisikan radio.
Board/perangkat	marlin, blueline, koral	Lapisan papan/perangkat mewakili lapisan fisik plastik pada (yaitu, desain industri perangkat). Lapisan ini juga mewakili skema produk. Termasuk periferal di board dan konfigurasi Anda. Nama yang digunakan hanyalah kode untuk board/perangkat yang berbeda konfigurasi standar.
Arch	grup, x86, arm64, x86_64	Lapisan arsitektur menjelaskan konfigurasi prosesor dan application {i>binary interface <i}(ABI) yang berjalan di board.

Menggunakan varian build

Saat membuat produk untuk produk tertentu, ada baiknya memiliki yang berbeda pada build rilis final. Dalam modul definisinya, modul ini dapat menentukan tag dengan LOCAL_MODULE_TAGS, yang dapat berupa satu atau beberapa nilai optional (default), debug, dan eng.

Jika modul tidak menentukan tag (oleh LOCAL_MODULE_TAGS), elemen default ke optional. Modul opsional diinstal hanya jika yang diperlukan oleh konfigurasi produk dengan PRODUCT_PACKAGES.

Berikut adalah varian build yang saat ini ditentukan.

Varian	Deskripsi
`eng`	Ini adalah rasa default. Menginstal modul yang diberi tag dengan `eng` atau `debug`. Menginstal modul sesuai dengan file definisi produk, di selain modul yang diberi tag. `ro.secure=0` `ro.debuggable=1` `ro.kernel.android.checkjni=1` `adb` diaktifkan secara default.
`user`	Varian yang dimaksudkan untuk menjadi bit rilis akhir. Menginstal modul yang diberi tag dengan `user`. Menginstal modul sesuai dengan file definisi produk, di selain modul yang diberi tag. `ro.secure=1` `ro.debuggable=0` `adb` dinonaktifkan secara default.
`userdebug`	Sama seperti `user`, dengan pengecualian berikut: Juga menginstal modul yang diberi tag dengan `debug`. `ro.debuggable=1` `adb` diaktifkan secara default.

Panduan untuk userdebug

Menjalankan build userdebug dalam pengujian membantu developer perangkat memahami performa dan kekuatan rilis dalam pengembangan. Untuk menjaga konsistensi antara build pengguna dan userdebug, serta untuk mencapai metrik yang andal dalam build digunakan untuk proses debug, developer perangkat harus mengikuti panduan berikut:

userdebug didefinisikan sebagai build pengguna dengan akses root yang diaktifkan, kecuali:
- aplikasi khusus debug pengguna yang dijalankan hanya sesuai permintaan oleh pengguna
- Operasi yang hanya berjalan selama pemeliharaan tidak ada aktivitas (pada pengisi daya/sepenuhnya dikenai biaya), seperti menggunakan dex2oatd dibandingkan dex2oat untuk kompilasi latar belakang
Jangan menyertakan fitur yang diaktifkan/dinonaktifkan secara default berdasarkan jenis build. Developer tidak disarankan menggunakan segala bentuk logging apa pun yang memengaruhi masa pakai baterai, seperti logging debug atau heap dump.
Setiap fitur proses debug yang diaktifkan secara default di userdebug harus didefinisikan dengan jelas dengan semua developer yang mengerjakan project tersebut. Anda harus mengaktifkan fitur proses debug hanya dalam waktu terbatas sampai masalah yang Anda coba debug diselesaikan.

Menyesuaikan build dengan overlay resource

Sistem build Android menggunakan overlay resource untuk menyesuaikan produk pada waktu build. Overlay resource menentukan resource file yang diterapkan di atas {i>default<i}. Untuk menggunakan overlay resource, ubah project buildfile untuk menyetel PRODUCT_PACKAGE_OVERLAYS ke jalur relatif ke direktori tingkat atas Anda. Jalur itu menjadi {i>shadow root<i} yang dicari bersama dengan {i>root <i}saat ini ketika sistem build mencari sumber daya.

Setelan yang paling umum disesuaikan terdapat dalam file frameworks/base/core/res/res/values/config.xml.

Untuk mengatur overlay sumber daya pada file ini, tambahkan direktori overlay ke buildfile project dengan menggunakan salah satu dari berikut ini:

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

String atau array string apa pun yang ditemukan dalam file config.xml overlay menggantikan yang ditemukan dalam {i>file<i} asli.

Membangun produk

Anda dapat mengelola file sumber untuk perangkat dengan berbagai cara. Berikut ringkasannya deskripsi salah satu cara untuk mengatur implementasi Pixel.

Pixel diimplementasikan dengan konfigurasi perangkat utama yang diberi nama marlin. Dari konfigurasi perangkat ini, produk dibuat dengan makefile definisi produk yang mendeklarasikan informasi khusus produk tentang perangkat seperti nama dan model. Anda dapat melihat device/google/marlin untuk melihat penyiapannya.

Menulis makefile produk

Langkah-langkah berikut menjelaskan cara menyiapkan makefile produk dengan cara yang serupa dengan lini produk Pixel:

Membuat device/<company-name>/<device-name> direktori untuk Google. Misalnya, device/google/marlin. Direktori ini akan berisi kode sumber untuk perangkat beserta makefile untuk membuatnya.
Buat makefile device.mk yang mendeklarasikan file dan modul yang diperlukan untuk perangkat seluler. Untuk contoh, lihat device/google/marlin/device-marlin.mk.

Membuat makefile definisi produk untuk membuat produk tertentu berdasarkan perangkat. Tujuan makefile berikut diambil dari device/google/marlin/aosp_marlin.mk sebagai contoh. Perhatikan bahwa produk mewarisi dari device/google/marlin/device-marlin.mk dan vendor/google/marlin/device-vendor-marlin.mk file melalui makefile sambil mendeklarasikan informasi spesifik per 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 artikel Menetapkan variabel definisi produk untuk mengetahui variabel khusus produk yang dapat Anda tambahkan ke makefile.

Buat file AndroidProducts.mk yang mengarah ke makefile produk. Di beberapa contoh ini, hanya makefile definisi produk yang diperlukan. Contoh di bawah ini adalah dari device/google/marlin/AndroidProducts.mk (yang berisi marlin, yaitu Pixel, dan sailfish, Pixel XL, yang memiliki konfigurasi paling banyak):
```
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. Untuk contoh, lihat device/google/marlin/BoardConfig.mk.
Khusus dan versi Android 9 yang lebih rendah, buat vendorsetup.sh untuk menambahkan produk Anda ("kombo makan siang") ke build beserta varian build yang dipisahkan oleh tanda hubung. Contoh:
```
add_lunch_combo <product-name>-userdebug
```
Pada tahap ini, Anda dapat membuat lebih banyak varian produk berdasarkan perangkat yang sama.

Menetapkan variabel definisi produk

Variabel khusus produk ditentukan dalam makefile produk. Tabel menunjukkan beberapa variabel yang dikelola dalam file definisi produk.

Variabel	Deskripsi	Contoh
`PRODUCT_AAPT_CONFIG`	Konfigurasi `aapt` yang akan digunakan saat membuat paket.
`PRODUCT_BRAND`	Merek (misalnya, operator) yang menjadi dasar penyesuaian software.
`PRODUCT_CHARACTERISTICS`	`aapt` untuk memungkinkan penambahan resource khusus varian ke sebuah paket.	`tablet`, `nosdcard`
`PRODUCT_COPY_FILES`	Daftar kata seperti `source_path:destination_path`. File di jalur sumber harus disalin ke jalur tujuan saat membuat produk ini. Aturan untuk penyalinan langkah ditentukan di `config/makefile`.
`PRODUCT_DEVICE`	Nama desain industri. Ini juga merupakan nama board, dan sistem build menggunakannya untuk menemukan `BoardConfig.mk`.	`tuna`
`PRODUCT_LOCALES`	Daftar kode bahasa dua huruf yang dipisahkan spasi, pasangan kode negara dua huruf yang menjelaskan beberapa pengaturan untuk pengguna, seperti bahasa UI dan waktu, tanggal, dan pemformatan mata uang. Lokalitas pertama yang tercantum di `PRODUCT_LOCALES` digunakan sebagai lokalitas default produk.	`en_GB`, `de_DE`, `es_ES`, `fr_CA`
`PRODUCT_MANUFACTURER`	Nama produsen.	`acme`
`PRODUCT_MODEL`	Nama produk akhir yang dapat dilihat oleh pengguna akhir.
`PRODUCT_NAME`	Nama keseluruhan produk yang dapat dilihat pengguna akhir. Muncul di Setelan > 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 resource 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 dalam `PRODUCT_VENDOR_PROPERTIES` untuk partisi vendor. Partisi yang didukung nama: `SYSTEM`, `VENDOR`, `ODM`, `SYSTEM_EXT`, dan `PRODUCT`.

Mengonfigurasi filter bahasa dan lokalitas sistem default

Gunakan informasi ini untuk mengonfigurasi filter bahasa default dan lokalitas sistem, lalu aktifkan filter lokalitas untuk tipe perangkat baru.

Properti

Mengonfigurasi bahasa default dan filter lokalitas sistem menggunakan sistem khusus properti:

ro.product.locale: untuk menyetel lokalitas default. Ini awalnya diatur ke lokal dalam variabel PRODUCT_LOCALES; Anda dapat mengganti nilai tersebut. (Untuk informasi selengkapnya, lihat tabel Menetapkan variabel definisi produk.)
ro.localization.locale_filter: untuk menyetel filter lokalitas, menggunakan ekspresi reguler yang diterapkan ke nama lokal. Contoh:
- Filter inklusif: ^(de-AT|de-DE|en|uk).* - hanya mengizinkan bahasa Jerman (Austria dan Jerman varian), semua varian bahasa Inggris untuk bahasa Inggris, dan Ukraina
- Filter eksklusif: ^(?!de-IT|es).* - mengecualikan bahasa Jerman (varian Italia), dan semua varian bahasa Spanyol.

Aktifkan filter lokalitas

Untuk mengaktifkan filter, tetapkan nilai string properti sistem ro.localization.locale_filter.

Dengan menetapkan nilai properti filter dan bahasa default melalui oem/oem.prop selama kalibrasi pabrik, Anda dapat mengonfigurasi batasan tanpa memasukkan filter ke dalam image sistem. Pastikan bahwa properti ini diambil dari partisi OEM dengan menambahkannya ke PRODUCT_OEM_PROPERTIES seperti yang ditunjukkan di bawah:

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

Kemudian dalam produksi, nilai sebenarnya ditulis ke oem/oem.prop untuk mencerminkan target lainnya. Dengan pendekatan ini, nilai default dipertahankan selama {i>factory reset<i}, sehingga pengaturan awal terlihat persis seperti pengaturan pertama yang dilakukan pengguna.

Setel ADB_VENDOR_KEYS untuk terhubung melalui USB

Variabel lingkungan ADB_VENDOR_KEYS memungkinkan produsen perangkat untuk 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 dikirim ke perangkat apa pun yang terhubung. Ini adalah kunci RSA yang ditampilkan dalam dialog otorisasi adb. Sebagai seorang Anda dapat membangun kunci yang dikenal ke dalam image sistem dan membagikannya dengan klien adb. Ini berguna untuk pengembangan OS dan terutama untuk pengujian karena menghindari keharusan berinteraksi dengan dialog otorisasi adb.

Untuk membuat kunci vendor, satu orang (biasanya pengelola rilis) harus:

Buat pasangan kunci menggunakan adb keygen. Untuk perangkat Google, Google membuat pasangan kunci untuk setiap versi OS baru.
Periksa pasangan kunci, di suatu tempat dalam hierarki sumber. Google menyimpannya di vendor/google/security/adb/, misalnya.
Tetapkan variabel build PRODUCT_ADB_KEYS agar mengarah ke direktori kunci Anda. Google melakukannya dengan menambahkan file Android.mk di direktori kunci yang bertuliskan PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, yang membantu memastikan bahwa kita ingat untuk membuat pasangan kunci baru untuk setiap versi OS.

Berikut makefile yang digunakan Google di direktori tempat kami menyimpan pasangan kunci yang 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, engineer hanya perlu menyetel ADB_VENDOR_KEYS variabel lingkungan untuk menunjuk ke direktori tempat pasangan kunci disimpan. Tindakan ini akan memberi tahu adb untuk mencoba kunci kanonis ini terlebih dahulu, sebelum beralih kembali ke kunci yang dibuat kunci {i>host<i} yang membutuhkan otorisasi manual. Jika adb tidak dapat terhubung ke jaringan yang tidak sah perangkat, pesan error akan menyarankan agar Anda menyetel ADB_VENDOR_KEYS jika sudah disetel.