Penjual APEX

Anda dapat menggunakan format file APEX untuk mengemas dan menginstal modul OS Android tingkat rendah. Hal ini memungkinkan pembangunan independen dan instalasi komponen seperti layanan dan perpustakaan asli, implementasi HAL, firmware, file konfigurasi, dll.

Vendor APEX diinstal oleh sistem build secara otomatis di partisi /vendor dan diaktifkan saat runtime oleh apexd sama seperti APEX di partisi lain.

Kasus penggunaan

Modularisasi gambar vendor

APEX memfasilitasi bundling alami dan modularisasi implementasi fitur pada image vendor.

Ketika image vendor dibuat sebagai kombinasi APEX vendor yang dibuat secara independen, produsen perangkat dapat dengan mudah memilih implementasi vendor tertentu yang diinginkan pada perangkat mereka. Produsen bahkan dapat membuat vendor APEX baru jika tidak ada APEX yang disediakan sesuai kebutuhan mereka, atau mereka memiliki perangkat keras khusus yang baru.

Misalnya, OEM dapat memilih untuk menyusun perangkatnya dengan implementasi wifi AOSP APEX, implementasi bluetooth SoC APEX, dan APEX implementasi telepon OEM khusus.

Tanpa vendor APEX, implementasi dengan begitu banyak ketergantungan antar komponen vendor memerlukan koordinasi dan pelacakan yang cermat. Dengan menggabungkan semua komponen (termasuk file konfigurasi dan perpustakaan tambahan) dalam APEX dengan antarmuka yang jelas pada setiap titik komunikasi lintas fitur, komponen yang berbeda menjadi dapat dipertukarkan.

Iterasi pengembang

Vendor APEX membantu pengembang melakukan iterasi lebih cepat saat mengembangkan modul vendor dengan menggabungkan seluruh implementasi fitur, seperti wifi HAL, di dalam APEX vendor. Pengembang kemudian dapat membangun dan secara individual mendorong APEX vendor untuk menguji perubahan, alih-alih membangun kembali keseluruhan citra vendor.

Hal ini menyederhanakan dan mempercepat siklus iterasi pengembang untuk pengembang yang terutama bekerja di satu area fitur dan ingin melakukan iterasi hanya pada area fitur tersebut.

Penggabungan alami area fitur ke dalam APEX juga menyederhanakan proses pembuatan, penerapan, dan pengujian perubahan untuk area fitur tersebut. Misalnya, menginstal ulang APEX secara otomatis memperbarui semua pustaka atau file konfigurasi yang disertakan APEX.

Menggabungkan area fitur ke dalam APEX juga menyederhanakan proses debug atau pengembalian ketika perilaku perangkat buruk terlihat. Misalnya, jika telepon tidak berfungsi dengan baik pada versi baru, maka pengembang dapat mencoba menginstal implementasi telepon lama APEX pada perangkat (tanpa perlu mem-flash versi lengkap) dan melihat apakah perilaku yang baik telah dipulihkan.

Contoh alur kerja:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

Contoh

Dasar-dasar

Lihat halaman utama Format File APEX untuk informasi umum APEX, termasuk persyaratan perangkat, detail format file, dan langkah-langkah instalasi.

Di Android.bp , menyetel properti vendor: true menjadikan modul APEX menjadi vendor APEX.

apex {
  ..
  vendor: true,
  ..
}

Biner dan perpustakaan bersama

APEX menyertakan dependensi transitif di dalam payload APEX kecuali APEX memiliki antarmuka yang stabil.

Antarmuka asli yang stabil untuk dependensi vendor APEX mencakup cc_library dengan stubs , ndk_library , atau llndk_library . Ketergantungan ini dikecualikan dari pengemasan, dan ketergantungan dicatat dalam manifes APEX. Manifes diproses oleh linkerconfig sehingga dependensi asli eksternal tersedia saat runtime.

Tidak seperti APEX di partisi /system , APEX vendor biasanya terikat pada versi VNDK tertentu. Pustaka VNDK menjamin stabilitas ABI dalam rilis, sehingga kita dapat memperlakukan pustaka VNDK sebagai pustaka yang stabil dan mengurangi ukuran APEX vendor dengan mengecualikannya dari APEX menggunakan properti use_vndk_as_stable .

Dalam cuplikan di bawah, APEX akan berisi biner ( my_service ) dan dependensinya yang tidak stabil ( file *.so ). Itu tidak akan berisi perpustakaan VNDK, bahkan ketika my_service dibangun dengan perpustakaan VNDK seperti libbase . Sebaliknya, saat runtime my_service akan menggunakan libbase dari perpustakaan VNDK yang disediakan oleh sistem.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

Dalam cuplikan di bawah, APEX akan berisi perpustakaan bersama my_standalone_lib dan semua dependensi non-stabilnya (seperti dijelaskan di atas).

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

implementasi HAL

Untuk menentukan implementasi HAL, sediakan binari dan pustaka yang sesuai di dalam APEX vendor serupa dengan contoh berikut:

Untuk sepenuhnya merangkum implementasi HAL, APEX juga harus menentukan fragmen VINTF dan skrip init yang relevan.

Fragmen VINTF

Fragmen VINTF dapat disajikan dari vendor APEX ketika fragmen berada di etc/vintf APEX.

Gunakan properti prebuilts untuk menyematkan fragmen VINTF di APEX.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

Init skrip

APEX dapat menyertakan skrip init dalam dua cara: (A) file teks bawaan dalam payload APEX, atau (B) skrip init biasa di /vendor/etc . Anda dapat mengatur keduanya untuk APEX yang sama.

Skrip init di APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

Skrip init dalam APEX hanya dapat memiliki definisi service . Skrip init di Vendor APEX juga dapat memiliki arahan on <property> .

Hati-hati saat menggunakan on . Karena skrip init di APEX diurai dan dieksekusi setelah APEX diaktifkan, beberapa peristiwa atau properti tidak dapat digunakan. Gunakan apex.all.ready=true untuk menjalankan tindakan sedini mungkin.

Firmware

Contoh:

Embed firmware pada vendor APEX dengan tipe modul prebuilt_firmware , seperti berikut.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

Modul prebuilt_firmware dipasang di direktori <apex name>/etc/firmware APEX. ueventd memindai direktori /apex/*/etc/firmware untuk menemukan modul firmware.

file_contexts dari APEX harus memberi label pada setiap entri muatan firmware dengan benar untuk memastikan bahwa file-file ini dapat diakses oleh ueventd saat runtime; biasanya, label vendor_file sudah cukup. Misalnya:

(/.*)? u:object_r:vendor_file:s0

Modul kernel

Sematkan modul kernel di vendor APEX sebagai modul bawaan, sebagai berikut.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

file_contexts dari APEX harus memberi label entri muatan modul kernel dengan benar. Misalnya:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

Modul kernel harus diinstal secara eksplisit. Contoh skrip init berikut di partisi vendor menunjukkan instalasi melalui insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

Hamparan sumber daya waktu proses

Contoh:

Sematkan hamparan sumber daya runtime di APEX vendor menggunakan properti rros .

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

File konfigurasi lainnya

Vendor APEX mendukung berbagai file konfigurasi lain yang biasanya ditemukan di partisi vendor sebagai bawaan di dalam vendor APEX, dan masih banyak lagi yang ditambahkan.

Contoh:

Fitur pengembangan ekstra

Pemilihan APEX saat boot

Contoh:

Pengembang juga dapat menginstal beberapa versi APEX vendor yang berbagi nama dan kunci APEX yang sama, lalu memilih versi mana yang diaktifkan selama setiap bootup menggunakan sysprops persisten. Untuk kasus penggunaan pengembang tertentu, ini mungkin lebih sederhana daripada menginstal salinan APEX baru menggunakan adb install .

Contoh kasus penggunaan:

  • Instal 3 versi vendor wifi HAL APEX: Tim QA dapat menjalankan pengujian manual atau otomatis menggunakan satu versi, lalu reboot ke versi lain dan jalankan kembali pengujian, lalu bandingkan hasil akhirnya.
  • Instal 2 versi kamera HAL vendor APEX, terkini dan eksperimental : Pengguna Dogfood dapat menggunakan versi eksperimental tanpa mengunduh dan menginstal file tambahan, sehingga mereka dapat dengan mudah menukarnya kembali.

Selama bootup, apexd mencari sysprops yang mengikuti format tertentu untuk mengaktifkan versi APEX yang tepat.

Format yang diharapkan untuk kunci properti adalah:

  • Konfigurasi boot
    • Digunakan untuk menetapkan nilai default, di BoardConfig.mk .
    • androidboot.vendor.apex.<apex name>
  • Sysprop yang persisten
    • Digunakan untuk mengubah nilai default, yang ditetapkan pada perangkat yang sudah di-boot.
    • Menggantikan nilai bootconfig jika ada.
    • persist.vendor.apex.<apex name>

Nilai properti harus berupa nama file APEX yang harus diaktifkan.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

Versi default juga harus dikonfigurasi menggunakan bootconfig di BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

Setelah perangkat di-boot, ubah versi yang diaktifkan dengan mengatur sysprop persisten:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

Jika perangkat mendukung pembaruan bootconfig setelah melakukan flashing (misalnya melalui perintah fastboot oem ), maka mengubah properti bootconfig untuk APEX multi-instal juga akan mengubah versi yang diaktifkan saat bootup.

Untuk perangkat referensi virtual berdasarkan Cuttlefish , Anda dapat menggunakan perintah --extra_bootconfig_args untuk menyetel properti bootconfig secara langsung saat diluncurkan. Misalnya:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";
,

Anda dapat menggunakan format file APEX untuk mengemas dan menginstal modul OS Android tingkat rendah. Hal ini memungkinkan pembangunan independen dan instalasi komponen seperti layanan dan perpustakaan asli, implementasi HAL, firmware, file konfigurasi, dll.

Vendor APEX diinstal oleh sistem build secara otomatis di partisi /vendor dan diaktifkan saat runtime oleh apexd sama seperti APEX di partisi lain.

Kasus penggunaan

Modularisasi gambar vendor

APEX memfasilitasi bundling alami dan modularisasi implementasi fitur pada image vendor.

Ketika image vendor dibuat sebagai kombinasi APEX vendor yang dibuat secara independen, produsen perangkat dapat dengan mudah memilih implementasi vendor tertentu yang diinginkan pada perangkat mereka. Produsen bahkan dapat membuat vendor APEX baru jika tidak ada APEX yang disediakan sesuai kebutuhan mereka, atau mereka memiliki perangkat keras khusus yang baru.

Misalnya, OEM dapat memilih untuk menyusun perangkatnya dengan implementasi wifi AOSP APEX, implementasi bluetooth SoC APEX, dan APEX implementasi telepon OEM khusus.

Tanpa vendor APEX, implementasi dengan begitu banyak ketergantungan antar komponen vendor memerlukan koordinasi dan pelacakan yang cermat. Dengan menggabungkan semua komponen (termasuk file konfigurasi dan perpustakaan tambahan) dalam APEX dengan antarmuka yang jelas pada setiap titik komunikasi lintas fitur, komponen yang berbeda menjadi dapat dipertukarkan.

Iterasi pengembang

Vendor APEX membantu pengembang melakukan iterasi lebih cepat saat mengembangkan modul vendor dengan menggabungkan seluruh implementasi fitur, seperti wifi HAL, di dalam APEX vendor. Pengembang kemudian dapat membangun dan secara individual mendorong APEX vendor untuk menguji perubahan, alih-alih membangun kembali keseluruhan citra vendor.

Hal ini menyederhanakan dan mempercepat siklus iterasi pengembang untuk pengembang yang terutama bekerja di satu area fitur dan ingin melakukan iterasi hanya pada area fitur tersebut.

Penggabungan alami area fitur ke dalam APEX juga menyederhanakan proses pembuatan, penerapan, dan pengujian perubahan untuk area fitur tersebut. Misalnya, menginstal ulang APEX secara otomatis memperbarui semua pustaka atau file konfigurasi yang disertakan APEX.

Menggabungkan area fitur ke dalam APEX juga menyederhanakan proses debug atau pengembalian ketika perilaku perangkat buruk terlihat. Misalnya, jika telepon tidak berfungsi dengan baik pada versi baru, maka pengembang dapat mencoba menginstal implementasi telepon lama APEX pada perangkat (tanpa perlu mem-flash versi lengkap) dan melihat apakah perilaku yang baik telah dipulihkan.

Contoh alur kerja:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

Contoh

Dasar-dasar

Lihat halaman utama Format File APEX untuk informasi umum APEX, termasuk persyaratan perangkat, detail format file, dan langkah-langkah instalasi.

Di Android.bp , menyetel properti vendor: true menjadikan modul APEX menjadi vendor APEX.

apex {
  ..
  vendor: true,
  ..
}

Biner dan perpustakaan bersama

APEX menyertakan dependensi transitif di dalam payload APEX kecuali APEX memiliki antarmuka yang stabil.

Antarmuka asli yang stabil untuk dependensi vendor APEX mencakup cc_library dengan stubs , ndk_library , atau llndk_library . Ketergantungan ini dikecualikan dari pengemasan, dan ketergantungan dicatat dalam manifes APEX. Manifes diproses oleh linkerconfig sehingga dependensi asli eksternal tersedia saat runtime.

Tidak seperti APEX di partisi /system , APEX vendor biasanya terikat pada versi VNDK tertentu. Pustaka VNDK menjamin stabilitas ABI dalam rilis, sehingga kita dapat memperlakukan pustaka VNDK sebagai pustaka yang stabil dan mengurangi ukuran APEX vendor dengan mengecualikannya dari APEX menggunakan properti use_vndk_as_stable .

Dalam cuplikan di bawah, APEX akan berisi biner ( my_service ) dan dependensi non-stabilnya ( file *.so ). Itu tidak akan berisi perpustakaan VNDK, bahkan ketika my_service dibangun dengan perpustakaan VNDK seperti libbase . Sebaliknya, saat runtime my_service akan menggunakan libbase dari perpustakaan VNDK yang disediakan oleh sistem.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

Dalam cuplikan di bawah, APEX akan berisi perpustakaan bersama my_standalone_lib dan semua dependensi non-stabilnya (seperti dijelaskan di atas).

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

implementasi HAL

Untuk menentukan implementasi HAL, sediakan binari dan pustaka yang sesuai di dalam APEX vendor serupa dengan contoh berikut:

Untuk sepenuhnya merangkum implementasi HAL, APEX juga harus menentukan fragmen VINTF dan skrip init yang relevan.

Fragmen VINTF

Fragmen VINTF dapat disajikan dari vendor APEX ketika fragmen berada di etc/vintf APEX.

Gunakan properti prebuilts untuk menyematkan fragmen VINTF di APEX.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

Init skrip

APEX dapat menyertakan skrip init dalam dua cara: (A) file teks bawaan dalam payload APEX, atau (B) skrip init biasa di /vendor/etc . Anda dapat mengatur keduanya untuk APEX yang sama.

Skrip init di APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

Skrip init dalam APEX hanya dapat memiliki definisi service . Skrip init di Vendor APEX juga dapat memiliki arahan on <property> .

Hati-hati saat menggunakan on . Karena skrip init di APEX diurai dan dieksekusi setelah APEX diaktifkan, beberapa peristiwa atau properti tidak dapat digunakan. Gunakan apex.all.ready=true untuk menjalankan tindakan sedini mungkin.

Firmware

Contoh:

Embed firmware pada vendor APEX dengan tipe modul prebuilt_firmware , seperti berikut.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

Modul prebuilt_firmware dipasang di direktori <apex name>/etc/firmware APEX. ueventd memindai direktori /apex/*/etc/firmware untuk menemukan modul firmware.

file_contexts dari APEX harus memberi label pada setiap entri muatan firmware dengan benar untuk memastikan bahwa file-file ini dapat diakses oleh ueventd saat runtime; biasanya, label vendor_file sudah cukup. Misalnya:

(/.*)? u:object_r:vendor_file:s0

Modul kernel

Sematkan modul kernel di vendor APEX sebagai modul bawaan, sebagai berikut.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

file_contexts dari APEX harus memberi label entri muatan modul kernel dengan benar. Misalnya:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

Modul kernel harus diinstal secara eksplisit. Contoh skrip init berikut di partisi vendor menunjukkan instalasi melalui insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

Hamparan sumber daya waktu proses

Contoh:

Sematkan hamparan sumber daya runtime di APEX vendor menggunakan properti rros .

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

File konfigurasi lainnya

Vendor APEX mendukung berbagai file konfigurasi lain yang biasanya ditemukan di partisi vendor sebagai bawaan di dalam vendor APEX, dan masih banyak lagi yang ditambahkan.

Contoh:

Fitur pengembangan ekstra

Pemilihan APEX saat boot

Contoh:

Pengembang juga dapat menginstal beberapa versi APEX vendor yang berbagi nama dan kunci APEX yang sama, lalu memilih versi mana yang diaktifkan selama setiap bootup menggunakan sysprops persisten. Untuk kasus penggunaan pengembang tertentu, ini mungkin lebih sederhana daripada menginstal salinan APEX baru menggunakan adb install .

Contoh kasus penggunaan:

  • Instal 3 versi vendor wifi HAL APEX: Tim QA dapat menjalankan pengujian manual atau otomatis menggunakan satu versi, lalu reboot ke versi lain dan jalankan kembali pengujian, lalu bandingkan hasil akhirnya.
  • Instal 2 versi kamera HAL vendor APEX, terkini dan eksperimental : Pengguna Dogfood dapat menggunakan versi eksperimental tanpa mengunduh dan menginstal file tambahan, sehingga mereka dapat dengan mudah menukarnya kembali.

Selama bootup, apexd mencari sysprops yang mengikuti format tertentu untuk mengaktifkan versi APEX yang tepat.

Format yang diharapkan untuk kunci properti adalah:

  • Konfigurasi boot
    • Digunakan untuk menetapkan nilai default, di BoardConfig.mk .
    • androidboot.vendor.apex.<apex name>
  • Sysprop yang persisten
    • Digunakan untuk mengubah nilai default, yang ditetapkan pada perangkat yang sudah di-boot.
    • Menggantikan nilai bootconfig jika ada.
    • persist.vendor.apex.<apex name>

Nilai properti harus berupa nama file APEX yang harus diaktifkan.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

Versi default juga harus dikonfigurasi menggunakan bootconfig di BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

Setelah perangkat di-boot, ubah versi yang diaktifkan dengan mengatur sysprop persisten:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

Jika perangkat mendukung pembaruan bootconfig setelah melakukan flashing (misalnya melalui perintah fastboot oem ), maka mengubah properti bootconfig untuk APEX multi-instal juga akan mengubah versi yang diaktifkan saat bootup.

Untuk perangkat referensi virtual berdasarkan Cuttlefish , Anda dapat menggunakan perintah --extra_bootconfig_args untuk menyetel properti bootconfig secara langsung saat diluncurkan. Misalnya:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";
,

Anda dapat menggunakan format file APEX untuk mengemas dan menginstal modul OS Android tingkat rendah. Hal ini memungkinkan pembangunan independen dan instalasi komponen seperti layanan dan perpustakaan asli, implementasi HAL, firmware, file konfigurasi, dll.

Vendor APEX diinstal oleh sistem build secara otomatis di partisi /vendor dan diaktifkan saat runtime oleh apexd sama seperti APEX di partisi lain.

Kasus penggunaan

Modularisasi gambar vendor

APEX memfasilitasi bundling alami dan modularisasi implementasi fitur pada image vendor.

Ketika image vendor dibuat sebagai kombinasi APEX vendor yang dibuat secara independen, produsen perangkat dapat dengan mudah memilih implementasi vendor tertentu yang diinginkan pada perangkat mereka. Produsen bahkan dapat membuat vendor APEX baru jika tidak ada APEX yang disediakan sesuai kebutuhan mereka, atau mereka memiliki perangkat keras khusus yang baru.

Misalnya, OEM dapat memilih untuk menyusun perangkatnya dengan implementasi wifi AOSP APEX, implementasi bluetooth SoC APEX, dan APEX implementasi telepon OEM khusus.

Tanpa vendor APEX, implementasi dengan begitu banyak ketergantungan antar komponen vendor memerlukan koordinasi dan pelacakan yang cermat. Dengan menggabungkan semua komponen (termasuk file konfigurasi dan perpustakaan tambahan) dalam APEX dengan antarmuka yang jelas pada setiap titik komunikasi lintas fitur, komponen yang berbeda menjadi dapat dipertukarkan.

Iterasi pengembang

Vendor APEX membantu pengembang melakukan iterasi lebih cepat saat mengembangkan modul vendor dengan menggabungkan seluruh implementasi fitur, seperti wifi HAL, di dalam APEX vendor. Pengembang kemudian dapat membangun dan secara individual mendorong APEX vendor untuk menguji perubahan, alih-alih membangun kembali keseluruhan citra vendor.

Hal ini menyederhanakan dan mempercepat siklus iterasi pengembang bagi pengembang yang terutama bekerja di satu area fitur dan ingin melakukan iterasi hanya pada area fitur tersebut.

Penggabungan alami area fitur ke dalam APEX juga menyederhanakan proses pembuatan, penerapan, dan pengujian perubahan untuk area fitur tersebut. Misalnya, menginstal ulang APEX secara otomatis memperbarui semua pustaka atau file konfigurasi yang disertakan APEX.

Menggabungkan area fitur ke dalam APEX juga menyederhanakan proses debug atau pengembalian ketika perilaku perangkat buruk terlihat. Misalnya, jika telepon tidak berfungsi dengan baik pada versi baru, maka pengembang dapat mencoba menginstal implementasi telepon lama APEX pada perangkat (tanpa perlu mem-flash versi lengkap) dan melihat apakah perilaku yang baik telah dipulihkan.

Contoh alur kerja:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

Contoh

Dasar-dasar

Lihat halaman utama Format File APEX untuk informasi umum APEX, termasuk persyaratan perangkat, detail format file, dan langkah-langkah instalasi.

Di Android.bp , menyetel properti vendor: true menjadikan modul APEX menjadi vendor APEX.

apex {
  ..
  vendor: true,
  ..
}

Biner dan perpustakaan bersama

APEX menyertakan dependensi transitif di dalam payload APEX kecuali APEX memiliki antarmuka yang stabil.

Antarmuka asli yang stabil untuk dependensi vendor APEX mencakup cc_library dengan stubs , ndk_library , atau llndk_library . Ketergantungan ini dikecualikan dari pengemasan, dan ketergantungan dicatat dalam manifes APEX. Manifes diproses oleh linkerconfig sehingga dependensi asli eksternal tersedia saat runtime.

Tidak seperti APEX di partisi /system , APEX vendor biasanya terikat pada versi VNDK tertentu. Pustaka VNDK menjamin stabilitas ABI dalam rilis, sehingga kita dapat memperlakukan pustaka VNDK sebagai pustaka yang stabil dan mengurangi ukuran APEX vendor dengan mengecualikannya dari APEX menggunakan properti use_vndk_as_stable .

Dalam cuplikan di bawah, APEX akan berisi biner ( my_service ) dan dependensi non-stabilnya ( file *.so ). Itu tidak akan berisi perpustakaan VNDK, bahkan ketika my_service dibangun dengan perpustakaan VNDK seperti libbase . Sebaliknya, saat runtime my_service akan menggunakan libbase dari perpustakaan VNDK yang disediakan oleh sistem.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

Dalam cuplikan di bawah, APEX akan berisi perpustakaan bersama my_standalone_lib dan semua dependensi non-stabilnya (seperti dijelaskan di atas).

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

implementasi HAL

Untuk menentukan implementasi HAL, sediakan binari dan pustaka yang sesuai di dalam APEX vendor serupa dengan contoh berikut:

Untuk sepenuhnya merangkum implementasi HAL, APEX juga harus menentukan fragmen VINTF dan skrip init yang relevan.

Fragmen VINTF

Fragmen VINTF dapat disajikan dari vendor APEX ketika fragmen berada di etc/vintf APEX.

Gunakan properti prebuilts untuk menyematkan fragmen VINTF di APEX.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

Init skrip

APEX dapat menyertakan skrip init dalam dua cara: (A) file teks bawaan dalam payload APEX, atau (B) skrip init biasa di /vendor/etc . Anda dapat mengatur keduanya untuk APEX yang sama.

Skrip init di APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

Skrip init dalam APEX hanya dapat memiliki definisi service . Skrip init di Vendor APEX juga dapat memiliki arahan on <property> .

Hati-hati saat menggunakan on . Karena skrip init di APEX diurai dan dieksekusi setelah APEX diaktifkan, beberapa peristiwa atau properti tidak dapat digunakan. Gunakan apex.all.ready=true untuk menjalankan tindakan sedini mungkin.

Firmware

Contoh:

Embed firmware pada vendor APEX dengan tipe modul prebuilt_firmware , seperti berikut.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

Modul prebuilt_firmware dipasang di direktori <apex name>/etc/firmware APEX. ueventd memindai direktori /apex/*/etc/firmware untuk menemukan modul firmware.

file_contexts dari APEX harus memberi label pada setiap entri muatan firmware dengan benar untuk memastikan bahwa file-file ini dapat diakses oleh ueventd saat runtime; biasanya, label vendor_file sudah cukup. Misalnya:

(/.*)? u:object_r:vendor_file:s0

Modul kernel

Sematkan modul kernel di vendor APEX sebagai modul bawaan, sebagai berikut.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

file_contexts dari APEX harus memberi label entri muatan modul kernel dengan benar. Misalnya:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

Modul kernel harus diinstal secara eksplisit. Contoh skrip init berikut di partisi vendor menunjukkan instalasi melalui insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

Hamparan sumber daya waktu proses

Contoh:

Sematkan hamparan sumber daya runtime di APEX vendor menggunakan properti rros .

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

File konfigurasi lainnya

Vendor APEX mendukung berbagai file konfigurasi lain yang biasanya ditemukan di partisi vendor sebagai bawaan di dalam vendor APEX, dan masih banyak lagi yang ditambahkan.

Contoh:

Fitur pengembangan ekstra

Pemilihan APEX saat boot

Contoh:

Pengembang juga dapat menginstal beberapa versi APEX vendor yang berbagi nama dan kunci APEX yang sama, lalu memilih versi mana yang diaktifkan selama setiap bootup menggunakan sysprops persisten. Untuk kasus penggunaan pengembang tertentu, ini mungkin lebih sederhana daripada menginstal salinan APEX baru menggunakan adb install .

Contoh kasus penggunaan:

  • Instal 3 versi vendor wifi HAL APEX: Tim QA dapat menjalankan pengujian manual atau otomatis menggunakan satu versi, lalu reboot ke versi lain dan jalankan kembali pengujian, lalu bandingkan hasil akhirnya.
  • Instal 2 versi kamera HAL vendor APEX, terkini dan eksperimental : Pengguna Dogfood dapat menggunakan versi eksperimental tanpa mengunduh dan menginstal file tambahan, sehingga mereka dapat dengan mudah menukarnya kembali.

Selama bootup, apexd mencari sysprops yang mengikuti format tertentu untuk mengaktifkan versi APEX yang tepat.

Format yang diharapkan untuk kunci properti adalah:

  • Konfigurasi boot
    • Digunakan untuk menetapkan nilai default, di BoardConfig.mk .
    • androidboot.vendor.apex.<apex name>
  • Sysprop yang persisten
    • Digunakan untuk mengubah nilai default, yang ditetapkan pada perangkat yang sudah di-boot.
    • Menggantikan nilai bootconfig jika ada.
    • persist.vendor.apex.<apex name>

Nilai properti harus berupa nama file APEX yang harus diaktifkan.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

Versi default juga harus dikonfigurasi menggunakan bootconfig di BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

Setelah perangkat di-boot, ubah versi yang diaktifkan dengan mengatur sysprop persisten:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

Jika perangkat mendukung pembaruan bootconfig setelah melakukan flashing (misalnya melalui perintah fastboot oem ), maka mengubah properti bootconfig untuk APEX multi-instal juga akan mengubah versi yang diaktifkan saat bootup.

Untuk perangkat referensi virtual berdasarkan Cuttlefish , Anda dapat menggunakan perintah --extra_bootconfig_args untuk menyetel properti bootconfig secara langsung saat diluncurkan. Misalnya:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";