DriverUI

UI cluster biasanya ditempatkan di belakang kemudi dalam layar terpisah. OEM secara bertahap menggabungkan cluster dan IVI menjadi satu tampilan. UI gabungan ini adalah DriverUI.

Gambar 1. DriverUI.

DriverUI adalah aplikasi sistem Android yang merender seluruh tampilan panel instrumen, tidak termasuk elemen yang relevan dengan keselamatan atau peraturan yang dirender oleh perender ketersediaan tinggi (HAR). DriverUI menampilkan informasi yang terkait dengan pemutaran media, panggilan telepon, peta, navigasi, dan lainnya, serta mengimplementasikan Desain Automotive untuk Compose.

DriverUI sebagai aktivitas cluster default

DriverUI berjalan sebagai aplikasi cluster dengan hak istimewa di Android dan AAOS memulainya secara otomatis.

AAOS menggunakan class ClusterHomeManager, yang juga disebut sebagai Cluster2, untuk membuat panel instrumen. Class ini menentukan konfigurasi yang diperlukan untuk mengidentifikasi implementasi panel instrumen dan cara AAOS berinteraksi dengannya. Google menyediakan implementasi referensi API Cluster2.

Platform

Anda dapat membangun dan menjalankan Display Safety di SDV. Platform software-defined vehicle (SDV):

• Memerlukan dua VM tamu.
• Menjalankan HAR di Media SDV (juga dikenal sebagai VM booting cepat) di VM tamu.
• Menjalankan DriverUI di VM IVI SDV tamu lain.
• Menjalankan Safety Monitor di VM Media SDV.

Gambar 2. Arsitektur platform SDV.

Menggabungkan output HAR dan DriverUI

HAR dan DriverUI menggunakan layar terpisah untuk merender UI-nya. Kedua output tersebut digabungkan dan muncul sebagai satu gambar di DriverUI.

Untuk mencapai hal ini, HAR mengontrol transparansi area tempat output Android muncul berdasarkan pesan heartbeat dari DriverUI. Jika DriverUI tidak tersedia, HAR akan mendeteksi tidak adanya heartbeat dan merender area DriverUI menjadi buram serta menampilkan placeholder. Saat heartbeat diterima, placeholder akan dihapus dan area DriverUI akan disetel menjadi transparan.

Gambar 3. Komposisi HAR dan DriverUI.

Memecahkan masalah komposisi alfa dan punch-through

Karena HAR sangat penting untuk keselamatan, bidang tampilan hardware-nya berada di atas bidang tampilan IVI Android. Saat Anda mem-build atau men-debug tampilan kustom atau platform OpenGL ES eksternal di HAR, verifikasi cara nilai alfa ditetapkan:

• Output DriverUI tidak ada di bidang HAR: Meskipun HAR menerima pesan HeartbeatRequest yang valid dari DriverUI, HAR harus mengosongkan area area pandang DriverUI menjadi transparan (alpha = 0.0) sehingga UI cluster Android yang mendasarinya terlihat. Jika lapisan atau latar belakang HAR kustom menggambar piksel buram (alpha = 1.0) di atas area DriverUI, lapisan atau latar belakang tersebut akan memblokir output Android di bawahnya.
• Lubang transparan yang tidak diinginkan di permukaan 3D atau OpenGL kustom: Saat Anda merender permukaan OpenGL ES atau 3D eksternal ke dalam node HAR (seperti pengukur atau scene 3D kustom yang menulis piksel RGB dengan byte alfa yang tidak digunakan dibiarkan di 0x00), tetapkan saluran alfa piksel buram secara eksplisit ke 0xFF (alpha = 1.0). Membiarkan byte alfa di 0x00 akan menyebabkan compositor memperlakukan piksel tersebut sebagai transparan (alpha = 0.0) dan membuat lubang langsung melalui lapisan HAR ke bidang IVI Android yang mendasarinya.
• Diagnostik tampilan lintas VM: Karena HAR (sdv_media_har_cf) dan IVI Android (sdv_ivi_cf_ds) berjalan di VM tamu yang terpisah, menjalankan adb shell dumpsys SurfaceFlinger di VM IVI Android hanya akan memeriksa lapisan Android dan tidak memiliki visibilitas ke bidang HAR yang ada di atasnya.

Komunikasi DriverUI dan HAR

DriverUI dan HAR berkomunikasi satu sama lain menggunakan remote procedure call (RPC). Pesan heartbeat adalah contoh data yang dikirim melalui saluran RPC dan terdiri dari stempel waktu sebagai salah satu kolomnya.

gRPC digunakan untuk RPC. Di SDV, komunikasi SDV menyediakan Klien Gateway SDV untuk menemukan dan membuat saluran dari DriverUI ke HAR. Layanan gRPC menentukan file buffering protokol:

// Heartbeat.
rpc Heartbeat(HeartbeatRequest) returns (HeartbeatResponse) {}

// Document switched in the DriverUI.
rpc DocumentSwitched(DocumentSwitchedRequest) returns (DocumentSwitchedResponse) {}

// Document updated in the DriverUI. Unary RPC.
rpc DocumentUpdated(DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

// Document updated in the DriverUI. Requests are streamed with each request
// containing a part of the document and the entire document is assembled from these
// chunks by the server.
rpc DocumentUpdatedStreaming(stream DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

/// Request for HAR to change design tokens.
rpc DesignTokenUpdate(DesignTokenUpdateRequest) returns (DesignTokenUpdateResponse) {}

// Request to change the current locale used in HAR.
rpc LocaleUpdate(LocaleUpdateRequest) returns (LocaleUpdateResponse) {}

// Requests to swap a certain variant at a Figma node.
rpc ChangeVariant(ChangeVariantRequest) returns (ChangeVariantResponse) {}

// Requests to change the container (display/root node) configuration (dpi, size) in HAR.
rpc ChangeContainerConfiguration(ChangeContainerConfigurationRequest) returns (ChangeContainerConfigurationResponse) {}

Detail permintaan dan respons ada di sumber Display Safety di packages/apps/Car/DriverUI/proto/driverui.proto dalam repositori kode sumber ub-automotive.

Di platform SDV, komunikasi SDV menyediakan Klien Gateway SDV untuk menemukan dan membuat saluran gRPC dari DriverUI ke HAR.

Menjalankan perintah ini menggunakan terminal IVI akan mengirimkan komunikasi ke SDV Media, sehingga memicu update tema di seluruh cluster.

adb shell cmd car_service inject-key -d 1 9 # Purple Theme
adb shell cmd car_service inject-key -d 1 8 # Blue Theme

Gambar 4. Komunikasi RPC untuk mengubah tema DriverUI dan HAR.

Menampilkan informasi Media, Maps, dan Telepon di cluster

Melalui komunikasi dengan IVI, DriverUI dapat menampilkan informasi untuk Media, Maps, dan Telepon dalam cluster referensi. Meskipun Media berfungsi sebagai status default dalam implementasi referensi, tampilan akan diperbarui berdasarkan layanan aktif sesuai dengan prioritas berikut:

1. Maps
2. Telepon
3. Media

Sistem akan otomatis memprioritaskan menampilkan navigasi Maps atau layanan Telepon aktif daripada status Media default.

Berbagai status tampilan DriverUI diilustrasikan dalam gambar berikut:

Gambar 5. DriverUI menampilkan bagian Media dan Telepon di cluster lengkap.

Desain Otomotif untuk integrasi Compose

DriverUI mengimplementasikan Automotive Design for Compose untuk memungkinkan desain (Figma) ditampilkan dan diiterasi langsung dalam aplikasi Android. Integrasi ini menjembatani kesenjangan antara desain dan pengembangan dengan memungkinkan rendering dokumen desain di lingkungan runtime.

Mengakses aset desain

Contoh dokumen Figma untuk DriverUI adalah bagian dari codebase. Untuk mengakses dan mengubah desain ini:

1. Luncurkan DriverUI dengan file desain DCF Automotive Design for Compose lokal dari packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
2. Temukan file aset packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
3. Impor file ini ke Figma untuk melihat desain sumber atau melakukan perubahan.

Versi Automotive Design for Compose

• Gradle menggunakan versi Automotive Design for Compose yang ditentukan untuk designcompose di packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml.
• Rilis Automotive Design for Compose tersedia di halaman rilis.

Konfigurasi live update

Automotive Design for Compose mendukung live update dalam mode pengembangan, sehingga perubahan yang dibuat di Figma dapat langsung dirender di DriverUI. Hal ini memfasilitasi siklus pengujian cepat dan iterasi desain yang lebih cepat.

Jalankan perintah berikut untuk menetapkan token Figma untuk DriverUI:

adb shell am startservice \
  -n "com.android.car.driverui/com.android.designcompose.ApiKeyService" \
  -a setApiKey \
  -e ApiKey $FIGMA_ACCESS_TOKEN \
  --user 0

Sinkronisasi dokumen desain VM ganda

Dalam penyiapan VM ganda, update desain harus diterapkan di seluruh batas untuk menjaga konsistensi.

• DriverUI mengambil dokumen desain Figma terbaru dan mengirimkannya ke HAR menggunakan saluran komunikasi gRPC yang dijelaskan di halaman ini.
• Hasilnya, seluruh cluster akan diupdate dengan iterasi desain Figma terbaru, sehingga kedua VM tetap sinkron dengan sumber desain.

Gambar 6. Update langsung dokumen desain dari Figma ke DriverUI dan HAR.

Mengamankan saluran gRPC

gRPC memiliki integrasi SSL dan TLS serta mendukung penggunaan SSL dan TLS untuk mengautentikasi server dan mengenkripsi semua data yang dipertukarkan antara klien dan server. Mekanisme opsional tersedia bagi klien untuk memberikan sertifikat untuk autentikasi bersama. Untuk mengetahui informasi selengkapnya tentang autentikasi gRPC, lihat Autentikasi.