Menambahkan perangkat baru

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 petunjuk pengemasan. Android menggunakan sistem build Soong . Lihat Membangun Android untuk informasi selengkapnya tentang sistem pembangunan Android.

Memahami membangun lapisan

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

Lapisan Contoh Keterangan
Produk myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk Lapisan produk menentukan 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 dari definisi produk lain, yang 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 radionya (CDMA versus GSM) dapat mewarisi dari produk dasar yang sama yang tidak mendefinisikan radio.
Papan/perangkat marlin, garis biru, koral 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 tulis 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 tulis.

Menggunakan varian build

Saat membuat produk tertentu, ada gunanya memiliki variasi kecil pada versi rilis final. Dalam definisi modul, modul dapat menentukan tag dengan LOCAL_MODULE_TAGS , yang dapat berupa satu atau beberapa nilai optional (default), debug , dan eng .

Jika sebuah modul tidak menentukan tag (oleh LOCAL_MODULE_TAGS ), default tag-nya adalah optional . Modul opsional dipasang hanya jika diperlukan oleh konfigurasi produk dengan PRODUCT_PACKAGES .

Ini adalah varian build yang saat ini ditentukan.

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

Pedoman untuk userdebug

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

  • userdebug didefinisikan sebagai build pengguna dengan akses root diaktifkan, kecuali:
    • aplikasi khusus userdebug yang dijalankan hanya sesuai permintaan oleh pengguna
    • Operasi yang berjalan hanya selama pemeliharaan tidak aktif (dengan pengisi daya/terisi penuh), seperti menggunakan dex2oatd versus dex2oat untuk kompilasi latar belakang
  • Jangan sertakan fitur yang diaktifkan/dinonaktifkan secara default berdasarkan tipe build. Pengembang tidak disarankan untuk menggunakan segala bentuk logging yang memengaruhi masa pakai baterai, seperti logging debug atau heap dumping.
  • Setiap fitur debug yang diaktifkan secara default di userdebug harus didefinisikan dengan jelas dan dibagikan dengan semua pengembang yang mengerjakan proyek. Anda harus mengaktifkan fitur debug hanya dalam waktu terbatas hingga masalah yang Anda coba debug teratasi.

Menyesuaikan bangunan dengan hamparan sumber daya

Sistem build Android menggunakan overlay sumber daya untuk menyesuaikan produk pada waktu build. Hamparan sumber daya menentukan file sumber daya yang diterapkan di atas default. Untuk menggunakan overlay sumber daya, ubah file build proyek untuk menyetel PRODUCT_PACKAGE_OVERLAYS ke jalur relatif ke direktori tingkat teratas Anda. Jalur itu menjadi akar bayangan yang dicari bersama dengan akar saat ini saat sistem pembangunan mencari sumber daya.

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

Untuk menyiapkan overlay sumber daya pada file ini, tambahkan direktori overlay ke project buildfile menggunakan salah satu dari yang 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 larik string yang ditemukan di file overlay config.xml menggantikan yang ditemukan di file asli.

Membangun produk

Anda dapat mengatur file sumber untuk perangkat Anda dengan berbagai cara. Berikut adalah deskripsi 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 mendeklarasikan informasi khusus produk tentang perangkat seperti nama dan model. Anda dapat melihat direktori device/google/marlin untuk melihat bagaimana semua ini diatur.

Menulis makefile produk

Langkah-langkah berikut menjelaskan cara menyiapkan makefile 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 bersama dengan makefile untuk membangunnya.
  2. Buat makefile device.mk yang mendeklarasikan file dan modul yang diperlukan untuk perangkat. Sebagai 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 sementara juga menyatakan 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 Mengatur variabel definisi produk untuk variabel khusus produk tambahan yang dapat Anda tambahkan ke makefile Anda.

  4. Buat file AndroidProducts.mk yang mengarah ke makefile produk. Dalam contoh ini, hanya makefile definisi produk yang diperlukan. Contoh di bawah ini 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 papan. Sebagai contoh, lihat device/google/marlin/BoardConfig.mk .
  6. Hanya 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
    
  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 menunjukkan beberapa variabel yang dipertahankan 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.
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 dalam config/makefile .
PRODUCT_DEVICE Nama desain industri. Ini juga merupakan nama papan, dan sistem pembangunan menggunakannya untuk menemukan BoardConfig.mk . tuna
PRODUCT_LOCALES Daftar kode bahasa dua huruf yang dipisahkan spasi, pasangan kode negara dua huruf yang menjelaskan beberapa setelan untuk pengguna, seperti bahasa UI dan pemformatan waktu, tanggal, dan 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 yang terlihat oleh pengguna akhir untuk produk 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 hamparan khusus produk apa pun. 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 .

Mengonfigurasi bahasa sistem default dan filter lokal

Gunakan informasi ini untuk mengonfigurasi bahasa default dan filter lokal sistem, lalu aktifkan 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 variabel PRODUCT_LOCALES ; Anda dapat mengganti nilai itu. (Untuk informasi selengkapnya, lihat tabel Menetapkan 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.

Mengaktifkan filter lokal

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

Dengan menyetel nilai properti filter dan bahasa default melalui oem/oem.prop selama kalibrasi pabrik, Anda dapat mengonfigurasi batasan tanpa memasukkan filter ke dalam citra 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.

Menyetel 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 dalam dialog otorisasi adb. Sebagai alternatif, Anda dapat membuat kunci yang dikenal ke dalam image sistem dan membaginya dengan klien adb. 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 manajer rilis) harus:

  1. Hasilkan 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 di pohon sumber. Google menyimpannya di vendor/google/security/adb/ , misalnya.
  3. Setel 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.

Inilah makefile yang digunakan Google di direktori tempat kami menyimpan pasangan kunci yang didaftarkan 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, seorang insinyur hanya perlu menyetel variabel lingkungan ADB_VENDOR_KEYS untuk menunjuk ke direktori tempat pasangan kunci disimpan. Ini memberi tahu adb untuk mencoba kunci kanonis ini terlebih dahulu, sebelum kembali ke kunci host yang dihasilkan yang memerlukan otorisasi manual. Saat adb tidak dapat tersambung ke perangkat yang tidak sah, pesan kesalahan akan menyarankan agar Anda menyetel ADB_VENDOR_KEYS jika belum disetel.