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

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 pembangunan dengan metadata modul, dependensi waktu kompilasi, dan instruksi pengemasan. Android menggunakan Soong membangun sistem . Lihat Building Android untuk informasi lebih lanjut tentang membangun sistem Android.

Memahami membangun lapisan

Hirarki build mencakup lapisan abstraksi yang sesuai dengan susunan fisik perangkat. Lapisan-lapisan ini dijelaskan dalam tabel di bawah ini. Setiap lapisan berhubungan dengan satu 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 di lapisan tertentu sebagai spesialisasi elemen di lapisan yang sama, yang menghilangkan penyalinan dan menyederhanakan perawatan.

Lapisan Contoh Keterangan
Produk myProduct, myProduct_eu, myProduct_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. Sebuah produk dapat mewarisi dari definisi produk lain, yang menyederhanakan perawatan. 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, 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.

Menggunakan varian build

Saat membangun untuk produk tertentu, ada gunanya memiliki sedikit variasi pada versi rilis final. Dalam definisi modul, modul dapat menentukan tag dengan LOCAL_MODULE_TAGS , yang dapat menjadi salah satu atau lebih nilai-nilai optional (default), debug , dan eng .

Jika modul tidak menentukan tag (oleh LOCAL_MODULE_TAGS ), default tag untuk 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.
  • Modul Menginstall 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 sebagai bit rilis final.
  • Modul Menginstall 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 ini:
  • Juga menginstal modul ditandai dengan debug .
  • ro.debuggable=1
  • adb diaktifkan secara default.

Pedoman untuk debug pengguna

Menjalankan pengujian build userdebug 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 debugging, pengembang perangkat harus mengikuti panduan berikut:

  • userdebug didefinisikan sebagai build pengguna dengan akses root diaktifkan, kecuali:
    • aplikasi khusus userdebug yang hanya dijalankan sesuai permintaan oleh pengguna
    • Operasi yang berjalan hanya selama pemeliharaan idle (pada charger / terisi penuh), seperti menggunakan dex2oatd dibandingkan dex2oat untuk mengkompilasi latar belakang
  • Jangan sertakan fitur yang diaktifkan/dinonaktifkan secara default berdasarkan tipe build. Pengembang tidak disarankan untuk menggunakan segala bentuk pencatatan yang memengaruhi masa pakai baterai, seperti pencatatan debug atau pembuangan tumpukan.
  • Setiap fitur debugging 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. Overlay sumber daya menentukan file sumber daya yang diterapkan di atas default. Untuk menggunakan overlay sumber daya, memodifikasi Buildfile proyek untuk set PRODUCT_PACKAGE_OVERLAYS untuk path relatif ke direktori tingkat atas Anda. Jalur itu menjadi akar bayangan yang dicari bersama dengan akar saat ini ketika sistem pembangunan mencari sumber daya.

Pengaturan yang paling umum disesuaikan yang terkandung dalam file kerangka / dasar / inti / res / res / values / config.xml .

Untuk menyiapkan overlay sumber daya pada file ini, tambahkan direktori overlay ke file build proyek 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

Setiap string atau array string yang ditemukan di overlay config.xml file yang 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 untuk mengatur implementasi Pixel.

Pixel diimplementasikan dengan konfigurasi perangkat bernama utama 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 device/google/marlin direktori untuk melihat bagaimana semua ini sudah diatur.

Menulis makefile produk

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

  1. Buat device/ <company-name> / <device-name> direktori untuk produk Anda. Sebagai contoh, device/google/marlin . Direktori ini akan berisi kode sumber untuk perangkat Anda bersama dengan makefile untuk membuatnya.
  2. Buat device.mk makefile yang menyatakan file dan modul yang dibutuhkan untuk perangkat. Untuk contoh, lihat device/google/marlin/device-marlin.mk .
  3. Buat makefile definisi produk untuk membuat produk tertentu berdasarkan perangkat. Makefile berikut ini diambil dari device/google/marlin/aosp_marlin.mk sebagai contoh. Perhatikan bahwa mewarisi produk dari device/google/marlin/device-marlin.mk dan vendor/google/marlin/device-vendor-marlin.mk file melalui makefile sementara juga menyatakan informasi produk-spesifik 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 Pengaturan variabel definisi produk untuk tambahan variabel khusus produk yang dapat Anda tambahkan ke makefiles Anda.

  4. Buat AndroidProducts.mk file yang menunjuk ke makefiles produk. Dalam contoh ini, hanya makefile definisi produk yang diperlukan. Contoh di bawah adalah dari device/google/marlin/AndroidProducts.mk (yang berisi baik marlin, Pixel, dan sailfish, Pixel XL, yang berbagi sebagian konfigurasi):
    PRODUCT_MAKEFILES := \
    	$(LOCAL_DIR)/aosp_marlin.mk \
    	$(LOCAL_DIR)/aosp_sailfish.mk
    
    COMMON_LUNCH_CHOICES := \
    	aosp_marlin-userdebug \
    	aosp_sailfish-userdebug
    
  5. Buat BoardConfig.mk makefile yang berisi konfigurasi papan-spesifik. Untuk contoh, lihat device/google/marlin/BoardConfig.mk .
  6. Untuk Android 9 dan hanya menurunkan, membuat vendorsetup.sh file untuk menambahkan produk Anda ( "makan siang combo") untuk membangun bersama dengan membangun varian dipisahkan dengan tanda hubung. Sebagai contoh:
    add_lunch_combo <product-name>-userdebug
    
  7. Pada titik ini, Anda dapat membuat lebih banyak varian produk berdasarkan perangkat yang sama.

Mengatur variabel definisi produk

Variabel khusus produk didefinisikan dalam makefile produk. Tabel menunjukkan beberapa variabel yang dipertahankan dalam file definisi produk.

Variabel Keterangan Contoh
PRODUCT_AAPT_CONFIG aapt konfigurasi untuk digunakan saat membuat paket.
PRODUCT_BRAND Merek (misalnya, operator) perangkat lunak disesuaikan untuk, jika ada.
PRODUCT_CHARACTERISTICS aapt karakteristik untuk memungkinkan menambahkan sumber varian khusus untuk 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-langkah copy didefinisikan dalam config/makefile .
PRODUCT_DEVICE Nama desain industri. Ini juga merupakan nama papan, dan membangun sistem menggunakannya untuk mencari 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. Lokal pertama yang terdaftar di 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 Settings> About layar.
PRODUCT_OTA_PUBLIC_KEYS Daftar kunci publik over-the-air (OTA) untuk produk.
PRODUCT_PACKAGES Daftar APK dan modul yang akan dipasang. 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 tugas properti sistem dalam format "key=value" untuk partisi sistem. Sifat sistem untuk partisi lain dapat diatur melalui PRODUCT_<PARTITION>_PROPERTIES seperti dalam PRODUCT_VENDOR_PROPERTIES untuk partisi penjual. Nama partisi 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 pengaturan lokal default. Hal ini awalnya diatur ke lokal pertama di PRODUCT_LOCALES variabel; Anda dapat mengganti nilai itu. (Untuk informasi lebih lanjut, lihat produk Pengaturan variabel definisi tabel.)
  • ro.localization.locale_filter : untuk menetapkan lokal filter, menggunakan ekspresi reguler diterapkan untuk locale nama. Sebagai contoh:
    • Filter inklusif: ^(de-AT|de-DE|en|uk).* - memungkinkan hanya Jerman (Austria dan Jerman varian), semua Inggris varian dari bahasa Inggris, dan Ukraina
    • Filter eksklusif: ^(?!de-IT|es).* - tidak termasuk Jerman (Italia varian), dan semua varian dari Spanyol.

Mengaktifkan filter lokal

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

Dengan menetapkan nilai properti filter dan bahasa default melalui oem/oem.prop selama kalibrasi pabrik Anda dapat mengkonfigurasi pembatasan tanpa memanggang filter ke dalam sistem gambar. Anda memastikan bahwa sifat ini diambil dari partisi OEM dengan menambahkan mereka ke PRODUCT_OEM_PROPERTIES variabel seperti yang ditunjukkan di bawah ini:

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

Kemudian pada produksi nilai yang sebenarnya ditulis untuk oem/oem.prop , untuk mencerminkan persyaratan sasaran. Dengan pendekatan ini, nilai default dipertahankan selama pengaturan ulang pabrik, sehingga pengaturan awal terlihat persis seperti pengaturan pertama bagi pengguna.

Menyetel ADB_VENDOR_KEYS untuk terhubung melalui USB

The ADB_VENDOR_KEYS variabel lingkungan memungkinkan produsen perangkat untuk mengakses debuggable membangun (-userdebug dan -eng, tapi tidak -user) lebih 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 citra sistem dan membaginya dengan klien adb. 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:

  1. Menghasilkan sepasang 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. Toko Google mereka di vendor/google/security/adb/ , misalnya.
  3. Set variabel membangun PRODUCT_ADB_KEYS untuk menunjuk ke direktori kunci Anda. Google melakukan ini dengan menambahkan Android.mk file dalam direktori kunci yang mengatakan PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub , yang membantu memastikan bahwa kita ingat untuk menghasilkan pasangan kunci baru untuk setiap versi OS.

Inilah makefile yang digunakan Google di direktori tempat kami menyimpan pasangan kunci check-in kami 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 tombol penjual ini, seorang insinyur hanya perlu mengatur ADB_VENDOR_KEYS variabel lingkungan untuk menunjuk ke direktori di mana pasangan kunci disimpan. Ini memberitahu adb untuk mencoba kunci-kunci kanonik pertama, sebelum jatuh kembali ke kunci tuan rumah dihasilkan yang membutuhkan otorisasi manual. Ketika adb tidak dapat terhubung ke perangkat yang tidak sah, pesan kesalahan akan menyarankan bahwa Anda mengatur ADB_VENDOR_KEYS jika tidak sudah ditetapkan.