Menambahkan perangkat baru

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Gunakan informasi di halaman ini untuk membuat file make untuk perangkat dan produk Anda.

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 Soong. Lihat Mem-build Android untuk mengetahui informasi selengkapnya tentang sistem build Android.

Memahami lapisan build

Hierarki build mencakup lapisan abstraksi yang sesuai dengan komposisi fisik perangkat. Lapisan ini dijelaskan dalam tabel di bawah. Setiap lapisan terkait dengan lapisan di atasnya dalam hubungan satu-ke-banyak. Misalnya, arsitektur dapat memiliki lebih dari satu board dan setiap board dapat memiliki lebih dari satu produk. Anda dapat menentukan elemen di lapisan tertentu sebagai spesialisasi elemen di lapisan yang sama, yang menghilangkan penyalinan dan menyederhanakan pemeliharaan.

Menggunakan varian build

Saat mem-build untuk produk tertentu, sebaiknya buat variasi kecil pada build rilis akhir. Dalam definisi modul, modul 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), tagnya akan ditetapkan secara default ke optional. Modul opsional hanya diinstal jika diperlukan oleh konfigurasi produk dengan PRODUCT_PACKAGES.

Ini adalah varian build yang saat ini ditentukan.

Panduan untuk userdebug

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

• userdebug ditentukan sebagai build pengguna dengan akses root diaktifkan, kecuali:
  • aplikasi khusus userdebug yang hanya dijalankan sesuai permintaan oleh pengguna
  • Operasi yang hanya berjalan selama pemeliharaan tidak ada aktivitas (di pengisi daya/terisi penuh), seperti menggunakan dex2oatd versus dex2oat untuk kompilasi latar belakang
• Jangan sertakan fitur yang diaktifkan/dinonaktifkan secara default berdasarkan jenis build. Developer tidak disarankan untuk menggunakan bentuk logging apa pun yang memengaruhi masa pakai baterai, seperti logging debug atau pembuangan heap.
• Setiap fitur proses debug yang diaktifkan secara default di userdebug harus ditentukan dengan jelas dan dibagikan kepada semua developer yang mengerjakan project. Anda hanya boleh mengaktifkan fitur proses debug untuk waktu terbatas hingga masalah yang Anda coba debug teratasi.

Menyesuaikan build dengan overlay resource

Sistem build Android menggunakan overlay resource untuk menyesuaikan produk pada waktu build. Overlay resource menentukan file resource yang diterapkan di atas default. Untuk menggunakan overlay resource, ubah buildfile project untuk menetapkan PRODUCT_PACKAGE_OVERLAYS ke jalur yang relatif terhadap direktori level teratas Anda. Jalur tersebut menjadi root bayangan yang ditelusuri bersama root saat ini saat sistem build menelusuri resource.

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

Untuk menyiapkan overlay resource pada file ini, tambahkan direktori overlay ke buildfile project menggunakan salah satu dari 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

Semua string atau array string yang ditemukan dalam file config.xml overlay akan menggantikan string atau array string yang ditemukan dalam file asli.

Membuat produk

Anda dapat mengatur file sumber untuk perangkat dengan berbagai cara. Berikut adalah penjelasan singkat tentang salah satu cara untuk mengatur penerapan Pixel.

Pixel diterapkan dengan konfigurasi perangkat utama bernama 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 direktori device/google/marlin untuk melihat cara penyiapannya.

Menulis makefile produk

Langkah-langkah berikut menjelaskan cara menyiapkan file make produk dengan cara yang mirip dengan lini produk Pixel:

1. 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 mem-build-nya.
2. Buat makefile device.mk yang mendeklarasikan file dan modul yang diperlukan untuk perangkat. Untuk contoh, lihat device/google/marlin/device-marlin.mk.
3. 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 dari file device/google/marlin/device-marlin.mk dan vendor/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.

4. Buat file AndroidProducts.mk yang mengarah ke makefile produk. Dalam contoh ini, hanya makefile definisi produk yang diperlukan. Contoh di bawah ini berasal dari device/google/marlin/AndroidProducts.mk (yang berisi marlin, Pixel, dan sailfish, Pixel XL, yang berbagi sebagian besar konfigurasi):

   PRODUCT_MAKEFILES := \
   	$(LOCAL_DIR)/aosp_marlin.mk \
   	$(LOCAL_DIR)/aosp_sailfish.mk
   
   COMMON_LUNCH_CHOICES := \
   	aosp_marlin-userdebug \
   	aosp_sailfish-userdebug
   

5. Buat makefile BoardConfig.mk yang berisi konfigurasi khusus board. Untuk contoh, lihat device/google/marlin/BoardConfig.mk.
6. Khusus Android 9 dan yang lebih lama , buat file vendorsetup.sh untuk menambahkan produk Anda ("kombo makan siang") ke build beserta varian build yang dipisahkan dengan tanda hubung. Contoh:

   add_lunch_combo <product-name>-userdebug
   

7. 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 ini menunjukkan beberapa variabel yang dikelola dalam file definisi produk.

Mengonfigurasi filter lokalitas dan bahasa sistem default

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

Properti

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

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

Mengaktifkan 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. 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 sebenarnya ditulis ke oem/oem.prop, untuk mencerminkan persyaratan target. Dengan pendekatan ini, nilai default akan dipertahankan selama reset pabrik, sehingga setelan awal terlihat persis seperti penyiapan pertama bagi pengguna.

Menetapkan 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 autentikasi RSA unik untuk setiap komputer klien, yang akan dikirim ke perangkat apa pun yang terhubung. Ini adalah kunci RSA yang ditampilkan di dialog otorisasi adb. Sebagai alternatif, Anda dapat mem-build kunci yang diketahui ke dalam image sistem dan membagikannya dengan klien adb. Hal ini berguna untuk pengembangan OS dan terutama untuk pengujian karena menghindari kebutuhan untuk berinteraksi secara manual dengan dialog otorisasi adb.

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

1. Buat pasangan kunci menggunakan adb keygen. Untuk perangkat Google, Google membuat pasangan kunci baru untuk setiap versi OS baru.
2. Periksa pasangan kunci di suatu tempat dalam hierarki sumber. Google menyimpannya di vendor/google/security/adb/, misalnya.
3. 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 tidak lupa membuat pasangan kunci baru untuk setiap versi OS.

Berikut adalah makefile yang digunakan Google di direktori tempat kita menyimpan pasangan kunci yang di-checkin 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 menetapkan variabel lingkungan ADB_VENDOR_KEYS agar mengarah ke direktori tempat pasangan kunci disimpan. Hal ini memberi tahu adb untuk mencoba kunci kanonis ini terlebih dahulu, sebelum kembali ke kunci host yang dihasilkan yang memerlukan otorisasi manual. Jika adb tidak dapat terhubung ke perangkat yang tidak sah, pesan error akan menyarankan Anda menetapkan ADB_VENDOR_KEYS jika belum ditetapkan.