Kamera Kendaraan HAL

Android berisi HIDL Hardware Abstraction Layer (HAL) otomotif yang menyediakan pengambilan citra dan tampilan sangat awal dalam proses boot Android dan terus berfungsi selama masa pakai sistem. HAL mencakup sistem tampilan eksterior (EVS) stack dan biasanya digunakan untuk mendukung tampilan kamera spion dan tampilan surround di kendaraan dengan sistem In-Vehicle Infotainment (IVI) berbasis Android. EVS juga memungkinkan fitur-fitur canggih untuk diimplementasikan dalam aplikasi pengguna.

Android juga menyertakan antarmuka driver pengambilan dan tampilan khusus EVS (dalam /hardware/interfaces/automotive/evs/1.0 ). Meskipun dimungkinkan untuk membangun aplikasi kamera spion di atas layanan kamera dan tampilan Android yang ada, aplikasi semacam itu kemungkinan akan berjalan terlambat dalam proses boot Android. Menggunakan HAL khusus memungkinkan antarmuka yang disederhanakan dan memperjelas apa yang perlu diterapkan OEM untuk mendukung tumpukan EVS.

Komponen sistem

EVS mencakup komponen sistem berikut:

aplikasi EVS

Contoh aplikasi C++ EVS ( /packages/services/Car/evs/app ) berfungsi sebagai implementasi referensi. Aplikasi ini bertanggung jawab untuk meminta frame video dari EVS Manager dan mengirimkan frame yang sudah jadi untuk ditampilkan kembali ke EVS Manager. Diperkirakan akan dimulai oleh init segera setelah EVS dan Layanan Mobil tersedia, ditargetkan dalam waktu dua (2) detik setelah dihidupkan. OEM dapat memodifikasi atau mengganti aplikasi EVS sesuai keinginan.

Manajer EVS

EVS Manager ( /packages/services/Car/evs/manager ) menyediakan blok bangunan yang dibutuhkan oleh aplikasi EVS untuk mengimplementasikan apa pun mulai dari tampilan kamera spion sederhana hingga rendering multi-kamera 6DOF. Antarmukanya disajikan melalui HIDL dan dibangun untuk menerima beberapa klien bersamaan. Aplikasi dan layanan lain (khususnya Layanan Mobil) dapat menanyakan status Manajer EVS untuk mengetahui kapan sistem EVS aktif.

Antarmuka EVS HIDL

Sistem EVS, baik kamera maupun elemen tampilan, didefinisikan dalam paket android.hardware.automotive.evs . Contoh implementasi yang melatih antarmuka (menghasilkan gambar uji sintetis dan memvalidasi gambar untuk perjalanan bolak-balik) disediakan di /hardware/interfaces/automotive/evs/1.0/default .

OEM bertanggung jawab untuk mengimplementasikan API yang diekspresikan oleh file .hal di /hardware/interfaces/automotive/evs . Implementasi tersebut bertanggung jawab untuk mengonfigurasi dan mengumpulkan data dari kamera fisik dan mengirimkannya melalui buffer memori bersama yang dapat dikenali oleh Gralloc. Sisi tampilan dari implementasi bertanggung jawab untuk menyediakan buffer memori bersama yang dapat diisi oleh aplikasi (biasanya melalui rendering EGL) dan menampilkan frame yang telah selesai dalam preferensi untuk hal lain yang mungkin ingin ditampilkan pada tampilan fisik. Implementasi vendor dari antarmuka EVS dapat disimpan di bawah /vendor/… /device/… atau hardware/… (misalnya, /hardware/[vendor]/[platform]/evs ).

Driver kernel

Perangkat yang mendukung tumpukan EVS memerlukan driver kernel. Alih-alih membuat driver baru, OEM memiliki opsi untuk mendukung fitur yang diperlukan EVS melalui kamera yang ada dan/atau driver perangkat keras tampilan. Menggunakan kembali driver dapat menguntungkan, terutama untuk driver tampilan di mana presentasi gambar mungkin memerlukan koordinasi dengan utas aktif lainnya. Android 8.0 menyertakan driver sampel berbasis v4l2 (dalam packages/services/Car/evs/sampleDriver ) yang bergantung pada kernel untuk dukungan v4l2 dan pada SurfaceFlinger untuk menampilkan gambar keluaran.

Deskripsi antarmuka perangkat keras EVS

Bagian ini menjelaskan HAL. Vendor diharapkan menyediakan implementasi API ini yang disesuaikan untuk perangkat keras mereka.

IEvsEnumerator

Objek ini bertanggung jawab untuk menghitung perangkat keras EVS yang tersedia dalam sistem (satu atau lebih kamera dan perangkat tampilan tunggal).

getCameraList() generates (vec<CameraDesc> cameras);

Mengembalikan vektor yang berisi deskripsi untuk semua kamera dalam sistem. Diasumsikan set kamera sudah diperbaiki dan dapat diketahui saat boot. Untuk detail tentang deskripsi kamera, lihat CameraDesc .

openCamera(string camera_id) generates (IEvsCamera camera);

Memperoleh objek antarmuka yang digunakan untuk berinteraksi dengan kamera tertentu yang diidentifikasi oleh string camera_id unik. Mengembalikan NULL pada kegagalan. Upaya untuk membuka kembali kamera yang sudah terbuka tidak dapat gagal. Untuk menghindari kondisi balapan yang terkait dengan startup dan shutdown aplikasi, membuka kembali kamera harus mematikan instance sebelumnya sehingga permintaan baru dapat dipenuhi. Instance kamera yang telah didahulukan dengan cara ini harus berada dalam status tidak aktif, menunggu penghancuran akhir dan menanggapi permintaan apa pun untuk memengaruhi status kamera dengan kode pengembalian OWNERSHIP_LOST .

closeCamera(IEvsCamera camera);

Melepaskan antarmuka IevsCamera (dan merupakan kebalikan dari panggilan openCamera() ). Aliran video kamera harus dihentikan dengan memanggil stopVideoStream() sebelum memanggil closeCamera .

openDisplay() generates (IEvsDisplay display);

Memperoleh objek antarmuka yang digunakan untuk berinteraksi secara eksklusif dengan tampilan EVS sistem. Hanya satu klien yang dapat memegang instance fungsional IevsDisplay pada satu waktu. Mirip dengan perilaku terbuka agresif yang dijelaskan dalam openCamera , objek IEvsDisplay baru dapat dibuat kapan saja dan akan menonaktifkan instance sebelumnya. Instance yang tidak valid terus ada dan merespons panggilan fungsi dari pemiliknya, tetapi tidak boleh melakukan operasi mutasi saat mati. Akhirnya, aplikasi klien diharapkan memperhatikan kode pengembalian kesalahan OWNERSHIP_LOST dan menutup dan melepaskan antarmuka yang tidak aktif.

closeDisplay(IEvsDisplay display);

Melepaskan antarmuka IevsDisplay (dan merupakan kebalikan dari panggilan openDisplay() ). Buffer luar biasa yang diterima melalui panggilan getTargetBuffer() harus dikembalikan ke tampilan sebelum menutup tampilan.

getDisplayState() generates (DisplayState state);

Mendapatkan status tampilan saat ini. Implementasi HAL harus melaporkan keadaan aktual saat ini, yang mungkin berbeda dari keadaan yang paling baru diminta. Logika yang bertanggung jawab untuk mengubah status tampilan harus ada di atas lapisan perangkat, sehingga implementasi HAL tidak diinginkan untuk mengubah status tampilan secara spontan. Jika tampilan saat ini tidak dipegang oleh klien mana pun (dengan panggilan ke openDisplay), maka fungsi ini mengembalikan NOT_OPEN . Jika tidak, ini akan melaporkan status EVS Display saat ini (lihat API IEvsDisplay ).

struct CameraDesc {
    string      camera_id;
    int32       vendor_flags;       // Opaque value
}

• camera_id . String yang secara unik mengidentifikasi kamera tertentu. Dapat berupa nama perangkat kernel atau nama perangkat, seperti spion . Nilai untuk string ini dipilih oleh implementasi HAL dan digunakan secara tidak jelas oleh tumpukan di atas.
• vendor_flags . Metode untuk meneruskan informasi kamera khusus secara samar dari pengemudi ke aplikasi EVS khusus. Ini diteruskan tanpa interpretasi dari driver hingga aplikasi EVS, yang bebas untuk mengabaikannya.

IEvsKamera

Objek ini mewakili satu kamera dan merupakan antarmuka utama untuk menangkap gambar.

getCameraInfo() generates (CameraDesc info);

Mengembalikan CameraDesc dari kamera ini.

setMaxFramesInFlight(int32 bufferCount) generates (EvsResult result);

Menentukan kedalaman rantai penyangga yang diminta untuk didukung oleh kamera. Hingga saat ini, banyak frame dapat disimpan secara bersamaan oleh klien IevsCamera. Jika banyak frame telah dikirimkan ke penerima tanpa dikembalikan oleh doneWithFrame , aliran akan melewati frame hingga buffer dikembalikan untuk digunakan kembali. Adalah sah untuk panggilan ini untuk datang kapan saja, bahkan ketika aliran sudah berjalan, dalam hal ini buffer harus ditambahkan atau dihapus dari rantai yang sesuai. Jika tidak ada panggilan yang dilakukan ke titik masuk ini, IEvsCamera mendukung setidaknya satu frame secara default; dengan lebih dapat diterima.

Jika bufferCount yang diminta tidak dapat diakomodasi, fungsi mengembalikan BUFFER_NOT_AVAILABLE atau kode kesalahan lain yang relevan. Dalam hal ini, sistem terus beroperasi dengan nilai yang telah ditetapkan sebelumnya.

startVideoStream(IEvsCameraStream receiver) generates (EvsResult result);

Meminta pengiriman bingkai kamera EVS dari kamera ini. IevsCameraStream mulai menerima panggilan berkala dengan bingkai gambar baru hingga stopVideoStream() dipanggil. Bingkai harus mulai dikirimkan dalam 500 md dari panggilan startVideoStream dan setelah dimulai, harus dibuat minimal 10 FPS. Waktu yang diperlukan untuk memulai streaming video secara efektif diperhitungkan terhadap persyaratan waktu startup kamera spion apa pun. Jika streaming tidak dimulai, kode kesalahan harus dikembalikan; jika tidak OK dikembalikan.

oneway doneWithFrame(BufferDesc buffer);

Mengembalikan bingkai yang dikirimkan oleh ke IevsCameraStream. Setelah selesai menggunakan bingkai yang dikirimkan ke antarmuka IEvsCameraStream, bingkai harus dikembalikan ke IEvsCamera untuk digunakan kembali. Sejumlah kecil, terbatas buffer tersedia (mungkin sekecil satu), dan jika pasokan habis, tidak ada frame lebih lanjut yang dikirimkan sampai buffer dikembalikan, berpotensi mengakibatkan frame dilewati (buffer dengan pegangan nol menunjukkan akhir aliran dan tidak perlu dikembalikan melalui fungsi ini). Mengembalikan OK jika berhasil, atau kode kesalahan yang sesuai berpotensi termasuk INVALID_ARG atau BUFFER_NOT_AVAILABLE .

stopVideoStream();

Menghentikan pengiriman bingkai kamera EVS. Karena pengiriman tidak sinkron, frame dapat terus tiba untuk beberapa waktu setelah panggilan ini kembali. Setiap frame harus dikembalikan sampai penutupan aliran ditandai ke IevsCameraStream. Adalah sah untuk memanggil stopVideoStream pada aliran yang telah dihentikan atau tidak pernah dimulai, dalam hal ini diabaikan.

getExtendedInfo(int32 opaqueIdentifier) generates (int32 value);

Meminta informasi khusus pengemudi dari implementasi HAL. Nilai yang diizinkan untuk opaqueIdentifier adalah khusus driver, tetapi tidak ada nilai yang diteruskan yang dapat membuat driver mogok. Pengemudi harus mengembalikan 0 untuk setiap opaqueIdentifier tidak dikenal.

setExtendedInfo(int32 opaqueIdentifier, int32 opaqueValue) generates (EvsResult result);

Mengirim nilai khusus driver ke implementasi HAL. Ekstensi ini disediakan hanya untuk memfasilitasi ekstensi khusus kendaraan dan tidak ada implementasi HAL yang mengharuskan panggilan ini berfungsi dalam status default. Jika driver mengenali dan menerima nilainya, OK harus dikembalikan; jika tidak, INVALID_ARG atau kode kesalahan perwakilan lainnya harus dikembalikan.

struct BufferDesc {
    uint32  width;      // Units of pixels
    uint32  height;     // Units of pixels
    uint32  stride;     // Units of pixels
    uint32  pixelSize;  // Size of single pixel in bytes
    uint32  format;     // May contain values from android_pixel_format_t
    uint32  usage;      // May contain values from Gralloc.h
    uint32  bufferId;   // Opaque value
    handle  memHandle;  // gralloc memory buffer handle
}

Menjelaskan gambar yang melewati API. Drive HAL bertanggung jawab untuk mengisi struktur ini untuk menggambarkan buffer gambar dan klien HAL harus memperlakukan struktur ini sebagai hanya-baca. Kolom berisi informasi yang cukup untuk memungkinkan klien merekonstruksi objek ANativeWindowBuffer , seperti yang mungkin diperlukan untuk menggunakan gambar dengan EGL melalui ekstensi eglCreateImageKHR() .

• width . Lebar dalam piksel dari gambar yang disajikan.
• height . Tinggi dalam piksel dari gambar yang disajikan.
• stride . Jumlah piksel yang sebenarnya ditempati setiap baris dalam memori, memperhitungkan setiap padding untuk penyelarasan baris. Dinyatakan dalam piksel agar sesuai dengan konvensi yang diadopsi oleh gralloc untuk deskripsi buffernya.
• pixelSize . Jumlah byte yang ditempati oleh setiap piksel individu, memungkinkan perhitungan ukuran dalam byte yang diperlukan untuk melangkah di antara baris dalam gambar ( stride in bytes = stride in pixels * pixelSize ).
• format . Format piksel yang digunakan oleh gambar. Format yang disediakan harus kompatibel dengan implementasi OpenGL platform. Untuk lulus pengujian kompatibilitas, HAL_PIXEL_FORMAT_YCRCB_420_SP harus lebih disukai untuk penggunaan kamera, dan RGBA atau BGRA harus lebih disukai untuk tampilan.
• usage . Bendera penggunaan ditetapkan oleh implementasi HAL. Klien HAL diharapkan lulus tanpa modifikasi ini (untuk detailnya, lihat flag terkait Gralloc.h ).
• bufferId . Nilai unik yang ditentukan oleh implementasi HAL untuk memungkinkan buffer dikenali setelah perjalanan bolak-balik melalui API HAL. Nilai yang disimpan dalam bidang ini dapat dipilih secara sewenang-wenang oleh implementasi HAL.
• memHandle . Pegangan untuk buffer memori yang mendasari yang berisi data gambar. Implementasi HAL mungkin memilih untuk menyimpan pegangan buffer Gralloc di sini.

IEvsCameraStream

Klien mengimplementasikan antarmuka ini untuk menerima pengiriman bingkai video asinkron.

deliverFrame(BufferDesc buffer);

Menerima panggilan dari HAL setiap kali bingkai video siap untuk diperiksa. Pegangan penyangga yang diterima oleh metode ini harus dikembalikan melalui panggilan ke IEvsCamera::doneWithFrame() . Saat aliran video dihentikan melalui panggilan ke IEvsCamera::stopVideoStream() , panggilan balik ini mungkin berlanjut saat saluran pipa habis. Setiap frame masih harus dikembalikan; ketika frame terakhir dalam aliran telah dikirimkan, bufferHandle NULL akan dikirimkan, menandakan akhir aliran dan tidak ada pengiriman frame lebih lanjut yang terjadi. BufferHandle NULL itu sendiri tidak perlu dikirim kembali melalui doneWithFrame() , tetapi semua pegangan lainnya harus dikembalikan

Meskipun format buffer eksklusif dimungkinkan secara teknis, pengujian kompatibilitas memerlukan buffer dalam salah satu dari empat format yang didukung: NV21 (YCrCb 4:2:0 Semi-Planar), YV12 (YCrCb 4:2:0 Planar), YUYV (YCrCb 4: 2:2 Interleaved), RGBA (32 bit R:G:B:x), BGRA (32 bit B:G:R:x). Format yang dipilih harus merupakan sumber tekstur GL yang valid pada implementasi GLES platform.

Aplikasi tidak boleh bergantung pada korespondensi apa pun antara bidang bufferId dan memHandle dalam struktur BufferDesc . Nilai bufferId pada dasarnya bersifat pribadi untuk implementasi driver HAL, dan dapat menggunakan (dan menggunakannya kembali) sesuai keinginan.

Tampilan Ievs

Objek ini mewakili tampilan Evs, mengontrol status tampilan, dan menangani presentasi gambar yang sebenarnya.

getDisplayInfo() generates (DisplayDesc info);

Mengembalikan informasi dasar tentang tampilan EVS yang disediakan oleh sistem (lihat DisplayDesc ).

setDisplayState(DisplayState state) generates (EvsResult result);

Mengatur status tampilan. Klien dapat mengatur status tampilan untuk mengekspresikan status yang diinginkan, dan implementasi HAL harus menerima permintaan untuk status apa pun saat berada di status lain, meskipun responsnya mungkin mengabaikan permintaan.

Setelah inisialisasi, tampilan ditetapkan untuk memulai dalam status NOT_VISIBLE , setelah itu klien diharapkan meminta status VISIBLE_ON_NEXT_FRAME dan mulai menyediakan video. Saat tampilan tidak lagi diperlukan, klien diharapkan meminta status NOT_VISIBLE setelah melewati bingkai video terakhir.

Ini berlaku untuk negara bagian mana pun untuk diminta kapan saja. Jika tampilan sudah terlihat, itu akan tetap terlihat jika disetel ke VISIBLE_ON_NEXT_FRAME . Selalu mengembalikan OK kecuali jika status yang diminta adalah nilai enum yang tidak dikenal, dalam hal ini INVALID_ARG dikembalikan.

getDisplayState() generates (DisplayState state);

Mendapatkan status tampilan. Implementasi HAL harus melaporkan keadaan aktual saat ini, yang mungkin berbeda dari keadaan yang paling baru diminta. Logika yang bertanggung jawab untuk mengubah status tampilan harus ada di atas lapisan perangkat, sehingga implementasi HAL tidak diinginkan untuk mengubah status tampilan secara spontan.

getTargetBuffer() generates (handle bufferHandle);

Mengembalikan pegangan ke buffer bingkai yang terkait dengan tampilan. Buffer ini dapat dikunci dan ditulis oleh perangkat lunak dan/atau GL. Buffer ini harus dikembalikan melalui panggilan ke returnTargetBufferForDisplay() meskipun tampilan tidak lagi terlihat.

Meskipun format buffer eksklusif dimungkinkan secara teknis, pengujian kompatibilitas memerlukan buffer dalam salah satu dari empat format yang didukung: NV21 (YCrCb 4:2:0 Semi-Planar), YV12 (YCrCb 4:2:0 Planar), YUYV (YCrCb 4: 2:2 Interleaved), RGBA (32 bit R:G:B:x), BGRA (32 bit B:G:R:x). Format yang dipilih harus merupakan target render GL yang valid pada implementasi GLES platform.

Jika terjadi kesalahan, buffer dengan pegangan nol dikembalikan, tetapi buffer seperti itu tidak perlu diteruskan kembali ke returnTargetBufferForDisplay .

returnTargetBufferForDisplay(handle bufferHandle) generates (EvsResult result);

Memberitahu tampilan buffer siap untuk ditampilkan. Hanya buffer yang diambil melalui panggilan ke getTargetBuffer() yang valid untuk digunakan dengan panggilan ini, dan konten BufferDesc tidak boleh dimodifikasi oleh aplikasi klien. Setelah panggilan ini, buffer tidak lagi valid untuk digunakan oleh klien. Mengembalikan OK jika berhasil, atau kode kesalahan yang sesuai berpotensi termasuk INVALID_ARG atau BUFFER_NOT_AVAILABLE .

struct DisplayDesc {
     string  display_id;
     int32   vendor_flags;  // Opaque value
}

Menjelaskan properti dasar tampilan EVS dan diperlukan oleh implementasi EVS. HAL bertanggung jawab untuk mengisi struktur ini untuk menggambarkan tampilan EVS. Bisa berupa tampilan fisik atau tampilan virtual yang di-overlay atau dicampur dengan perangkat presentasi lain.

• display_id . String yang secara unik mengidentifikasi tampilan. Ini bisa berupa nama perangkat kernel, atau nama perangkat, seperti rearview . Nilai untuk string ini dipilih oleh implementasi HAL dan digunakan secara tidak jelas oleh tumpukan di atas.
• vendor_flags . Metode untuk meneruskan informasi kamera khusus secara samar dari pengemudi ke Aplikasi EVS khusus. Itu diteruskan tanpa interpretasi dari driver hingga Aplikasi EVS, yang bebas untuk mengabaikannya.

enum DisplayState : uint32 {
    NOT_OPEN,               // Display has not been “opened” yet
    NOT_VISIBLE,            // Display is inhibited
    VISIBLE_ON_NEXT_FRAME,  // Will become visible with next frame
    VISIBLE,                // Display is currently active
    DEAD,                   // Display is not available. Interface should be closed
}

Menjelaskan status tampilan EVS, yang dapat dinonaktifkan (tidak terlihat oleh pengemudi) atau diaktifkan (menampilkan gambar kepada pengemudi). Mencakup status sementara di mana tampilan belum terlihat tetapi siap untuk terlihat dengan pengiriman bingkai citra berikutnya melalui panggilan returnTargetBufferForDisplay() .

Manajer EVS

EVS Manager menyediakan antarmuka publik ke sistem EVS untuk mengumpulkan dan menyajikan tampilan kamera eksternal. Di mana driver perangkat keras hanya mengizinkan satu antarmuka aktif per sumber daya (kamera atau layar), Manajer EVS memfasilitasi akses bersama ke kamera. Satu aplikasi EVS utama adalah klien pertama dari EVS Manager, dan merupakan satu-satunya klien yang diizinkan untuk menulis data tampilan (klien tambahan dapat diberikan akses baca-saja ke gambar kamera).

EVS Manager mengimplementasikan API yang sama dengan driver HAL yang mendasarinya dan menyediakan layanan yang diperluas dengan mendukung beberapa klien bersamaan (lebih dari satu klien dapat membuka kamera melalui EVS Manager dan menerima aliran video).

Aplikasi tidak melihat perbedaan saat beroperasi melalui implementasi EVS Hardware HAL atau EVS Manager API kecuali bahwa EVS Manager API memungkinkan akses aliran kamera secara bersamaan. EVS Manager itu sendiri adalah klien yang diizinkan dari lapisan EVS Hardware HAL, dan bertindak sebagai proxy untuk EVS Hardware HAL.

Bagian berikut hanya menjelaskan panggilan yang memiliki perilaku berbeda (diperpanjang) dalam implementasi EVS Manager; panggilan yang tersisa identik dengan deskripsi EVS HAL.

IEvsEnumerator

openCamera(string camera_id) generates (IEvsCamera camera);

Memperoleh objek antarmuka yang digunakan untuk berinteraksi dengan kamera tertentu yang diidentifikasi oleh string camera_id unik. Mengembalikan NULL pada kegagalan. Pada lapisan EVS Manager, selama sumber daya sistem yang memadai tersedia, kamera yang sudah terbuka dapat dibuka kembali oleh proses lain, memungkinkan tee streaming video ke beberapa aplikasi konsumen. String camera_id pada lapisan EVS Manager sama dengan yang dilaporkan ke lapisan EVS Hardware.

IEvsKamera

Manajer EVS menyediakan implementasi IevsCamera yang divirtualisasikan secara internal sehingga operasi pada kamera oleh satu klien tidak memengaruhi klien lain, yang mempertahankan akses independen ke kamera mereka.

startVideoStream(IEvsCameraStream receiver) generates (EvsResult result);

Memulai streaming video. Klien dapat secara mandiri memulai dan menghentikan streaming video pada kamera dasar yang sama. Kamera yang mendasari dimulai ketika klien pertama dimulai.

doneWithFrame(uint32 frameId, handle bufferHandle) generates (EvsResult result);

Mengembalikan bingkai. Setiap klien harus mengembalikan bingkai mereka setelah selesai, tetapi diizinkan untuk memegang bingkai mereka selama yang mereka inginkan. Ketika jumlah bingkai yang dipegang oleh klien mencapai batas yang dikonfigurasi, itu tidak akan menerima bingkai lagi sampai mengembalikannya. Lompatan bingkai ini tidak memengaruhi klien lain, yang terus menerima semua bingkai seperti yang diharapkan.

stopVideoStream();

Menghentikan streaming video. Setiap klien dapat menghentikan streaming videonya kapan saja tanpa memengaruhi klien lain. Aliran kamera yang mendasari pada lapisan perangkat keras dihentikan ketika klien terakhir dari kamera tertentu menghentikan alirannya.

setExtendedInfo(int32 opaqueIdentifier, int32 opaqueValue) generates (EvsResult result);

Mengirim nilai khusus driver, yang berpotensi memungkinkan satu klien memengaruhi klien lain. Karena Manajer EVS tidak dapat memahami implikasi dari kata kontrol yang ditentukan vendor, kata tersebut tidak divirtualisasikan dan efek samping apa pun berlaku untuk semua klien kamera tertentu. Misalnya, jika vendor menggunakan panggilan ini untuk mengubah kecepatan bingkai, semua klien dari kamera lapisan perangkat keras yang terpengaruh akan menerima bingkai dengan kecepatan baru.

Tampilan Ievs

Hanya satu pemilik layar yang diizinkan, bahkan di level EVS Manager. Manajer tidak menambahkan fungsionalitas dan hanya meneruskan antarmuka IEvsDisplay langsung ke implementasi HAL yang mendasarinya.

aplikasi EVS

Android menyertakan implementasi referensi C++ asli dari aplikasi EVS yang berkomunikasi dengan EVS Manager dan Vehicle HAL untuk menyediakan fungsi kamera spion dasar. Aplikasi diharapkan untuk memulai sangat awal dalam proses boot sistem, dengan video yang sesuai ditampilkan tergantung pada kamera yang tersedia dan keadaan mobil (keadaan roda gigi dan lampu sein). OEM dapat memodifikasi atau mengganti aplikasi EVS dengan logika dan presentasi khusus kendaraan mereka sendiri.

Karena data gambar disajikan ke aplikasi dalam buffer grafik standar, aplikasi bertanggung jawab untuk memindahkan gambar dari buffer sumber ke buffer output. Sementara ini memperkenalkan biaya salinan data, itu juga menawarkan kesempatan bagi aplikasi untuk merender gambar ke buffer tampilan dengan cara apa pun yang diinginkannya.

Misalnya, aplikasi dapat memilih untuk memindahkan data piksel itu sendiri, berpotensi dengan skala inline atau operasi rotasi. Aplikasi juga dapat memilih untuk menggunakan gambar sumber sebagai tekstur OpenGL dan merender adegan kompleks ke buffer keluaran, termasuk elemen virtual seperti ikon, pedoman, dan animasi. Aplikasi yang lebih canggih juga dapat memilih beberapa kamera input bersamaan dan menggabungkannya ke dalam bingkai output tunggal (seperti untuk digunakan dalam tampilan virtual lingkungan kendaraan dari atas ke bawah).

Gunakan EGL/SurfaceFlinger di EVS Display HAL

Bagian ini menjelaskan cara menggunakan EGL untuk merender implementasi EVS Display HAL di Android 10.

Implementasi referensi EVS HAL menggunakan EGL untuk merender pratinjau kamera di layar dan menggunakan libgui untuk membuat permukaan render EGL target. Di Android 8 (dan lebih tinggi), libgui diklasifikasikan sebagai VNDK-private , yang merujuk ke grup library yang tersedia untuk library VNDK yang tidak dapat digunakan oleh proses vendor. Karena implementasi HAL harus berada di partisi vendor, vendor dicegah menggunakan Surface dalam implementasi HAL.

Membangun libgui untuk proses vendor

Penggunaan libgui berfungsi sebagai satu-satunya opsi untuk menggunakan EGL/SurfaceFlinger dalam implementasi EVS Display HAL. Cara paling mudah untuk mengimplementasikan libgui adalah melalui frameworks/native/libs/gui secara langsung dengan menggunakan target build tambahan di skrip build. Target ini persis sama dengan target libgui kecuali untuk penambahan dua bidang:

• name
• vendor_available

cc_library_shared {
    name: "libgui_vendor",
    vendor_available: true,
    vndk: {
        enabled: false,
    },
    double_loadable: true,


    defaults: ["libgui_bufferqueue-defaults"],


    srcs: [
    …
    // bufferhub is not used when building libgui for vendors
    target: {
        vendor: {
            cflags: [
                "-DNO_BUFFERHUB",
                "-DNO_INPUT",
            ],
    …

Catatan: Target vendor dibuat dengan makro NO_INPUT , yang menghapus satu kata 32-bit dari data paket. Karena SurfaceFlinger mengharapkan bidang ini yang telah dihapus, SurfaceFlinger gagal mengurai parsel. Ini diamati sebagai kegagalan fcntl :

W Parcel  : Attempt to read object from Parcel 0x78d9cffad8 at offset 428 that is not in the object list
E Parcel  : fcntl(F_DUPFD_CLOEXEC) failed in Parcel::read, i is 0, fds[i] is 0, fd_count is 20, error: Unknown error 2147483647
W Parcel  : Attempt to read object from Parcel 0x78d9cffad8 at offset 544 that is not in the object list

Untuk mengatasi kondisi ini:

diff --git a/libs/gui/LayerState.cpp b/libs/gui/LayerState.cpp
index 6066421fa..25cf5f0ce 100644
--- a/libs/gui/LayerState.cpp
+++ b/libs/gui/LayerState.cpp
@@ -54,6 +54,9 @@ status_t layer_state_t::write(Parcel& output) const
     output.writeFloat(color.b);
 #ifndef NO_INPUT
     inputInfo.write(output);
+#else
+    // Write a dummy 32-bit word.
+    output.writeInt32(0);
 #endif
     output.write(transparentRegion);
     output.writeUint32(transform);

Contoh instruksi pembuatan disediakan di bawah ini. Berharap untuk menerima $(ANDROID_PRODUCT_OUT)/system/lib64/libgui_vendor.so .

$ cd <your_android_source_tree_top>
$ . ./build/envsetup.
$ lunch <product_name>-<build_variant>
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=10
TARGET_PRODUCT=<product_name>
TARGET_BUILD_VARIANT=<build_variant>
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm64
TARGET_ARCH_VARIANT=armv8-a
TARGET_CPU_VARIANT=generic
TARGET_2ND_ARCH=arm
TARGET_2ND_ARCH_VARIANT=armv7-a-neon
TARGET_2ND_CPU_VARIANT=cortex-a9
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=<host_linux_version>
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=QT
OUT_DIR=out
============================================


$ m -j libgui_vendor
…
$ find $ANDROID_PRODUCT_OUT/system -name "libgui_vendor*"
.../out/target/product/hawk/system/lib64/libgui_vendor.so
.../out/target/product/hawk/system/lib/libgui_vendor.so

Menggunakan pengikat dalam implementasi EVS HAL

Di Android 8 (dan lebih tinggi), node perangkat /dev/binder menjadi eksklusif untuk proses kerangka kerja dan, oleh karena itu, tidak dapat diakses oleh proses vendor. Sebagai gantinya, proses vendor harus menggunakan /dev/hwbinder dan harus mengonversi antarmuka AIDL apa pun ke HIDL. Bagi mereka yang ingin terus menggunakan antarmuka AIDL antar proses vendor, gunakan domain pengikat, /dev/vndbinder .

Sementara SurfaceFlinger mendefinisikan antarmuka AIDL, proses vendor hanya dapat menggunakan antarmuka HIDL untuk berkomunikasi dengan proses kerangka kerja. Sejumlah pekerjaan non-sepele diperlukan untuk mengubah antarmuka AIDL yang ada menjadi HIDL. Untungnya, Android menyediakan metode untuk memilih driver pengikat untuk libbinder , yang ditautkan ke proses perpustakaan ruang pengguna.

diff --git a/evs/sampleDriver/service.cpp b/evs/sampleDriver/service.cpp
index d8fb3166..5fd02935 100644
--- a/evs/sampleDriver/service.cpp
+++ b/evs/sampleDriver/service.cpp
@@ -21,6 +21,7 @@
 #include <utils/Errors.h>
 #include <utils/StrongPointer.h>
 #include <utils/Log.h>
+#include <binder/ProcessState.h>

 #include "ServiceNames.h"
 #include "EvsEnumerator.h"
@@ -43,6 +44,9 @@ using namespace android;
 int main() {
     ALOGI("EVS Hardware Enumerator service is starting");


+    // Use /dev/binder for SurfaceFlinger
+    ProcessState::initWithDriver("/dev/binder");
+


     // Start a thread to listen to video device addition events.
     std::atomic<bool> running { true };
     std::thread ueventHandler(EvsEnumerator::EvsUeventThread, std::ref(running));

Catatan: Proses vendor harus memanggil ini sebelum memanggil Process atau IPCThreadState , atau sebelum membuat panggilan binder.

Kebijakan SELinux

Jika implementasi perangkat treble penuh, SELinux mencegah proses vendor menggunakan /dev/binder . Misalnya, implementasi sampel EVS HAL ditetapkan ke domain hal_evs_driver dan memerlukan izin r/w ke domain binder_device .

W ProcessState: Opening '/dev/binder' failed: Permission denied
F ProcessState: Binder driver could not be opened. Terminating.
F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 9145 (android.hardwar), pid 9145 (android.hardwar)
W android.hardwar: type=1400 audit(0.0:974): avc: denied { read write } for name="binder" dev="tmpfs" ino=2208 scontext=u:r:hal_evs_driver:s0 tcontext=u:object_r:binder_device:s0 tclass=chr_file permissive=0

Namun, menambahkan izin ini menyebabkan kegagalan build karena melanggar aturan neverallow berikut yang ditentukan di system/sepolicy/domain.te untuk perangkat full-treble.

libsepol.report_failure: neverallow on line 631 of system/sepolicy/public/domain.te (or line 12436 of policy.conf) violated by allow hal_evs_driver binder_device:chr_file { read write };
libsepol.check_assertions: 1 neverallow failures occurred

full_treble_only(`
  neverallow {
    domain
    -coredomain
    -appdomain
    -binder_in_vendor_violators
  } binder_device:chr_file rw_file_perms;
')

binder_in_vendor_violators adalah atribut yang disediakan untuk menangkap bug dan memandu pengembangan. Itu juga dapat digunakan untuk menyelesaikan pelanggaran Android 10 yang dijelaskan di atas.

diff --git a/evs/sepolicy/evs_driver.te b/evs/sepolicy/evs_driver.te
index f1f31e9fc..6ee67d88e 100644
--- a/evs/sepolicy/evs_driver.te
+++ b/evs/sepolicy/evs_driver.te
@@ -3,6 +3,9 @@ type hal_evs_driver, domain, coredomain;
 hal_server_domain(hal_evs_driver, hal_evs)
 hal_client_domain(hal_evs_driver, hal_evs)

+# Allow to use /dev/binder
+typeattribute hal_evs_driver binder_in_vendor_violators;
+
 # allow init to launch processes in this context
 type hal_evs_driver_exec, exec_type, file_type, system_file_type;
 init_daemon_domain(hal_evs_driver)

Membangun implementasi referensi EVS HAL sebagai proses vendor

Sebagai referensi, Anda dapat menerapkan perubahan berikut ke packages/services/Car/evs/Android.mk . Pastikan untuk mengonfirmasi bahwa semua perubahan yang dijelaskan berfungsi untuk penerapan Anda.

diff --git a/evs/sampleDriver/Android.mk b/evs/sampleDriver/Android.mk
index 734feea7d..0d257214d 100644
--- a/evs/sampleDriver/Android.mk
+++ b/evs/sampleDriver/Android.mk
@@ -16,7 +16,7 @@ LOCAL_SRC_FILES := \
 LOCAL_SHARED_LIBRARIES := \
     android.hardware.automotive.evs@1.0 \
     libui \
-    libgui \
+    libgui_vendor \
     libEGL \
     libGLESv2 \
     libbase \
@@ -33,6 +33,7 @@ LOCAL_SHARED_LIBRARIES := \
 LOCAL_INIT_RC := android.hardware.automotive.evs@1.0-sample.rc

 LOCAL_MODULE := android.hardware.automotive.evs@1.0-sample
+LOCAL_PROPRIETARY_MODULE := true

 LOCAL_MODULE_TAGS := optional
 LOCAL_STRIP_MODULE := keep_symbols
@@ -40,6 +41,7 @@ LOCAL_STRIP_MODULE := keep_symbols
 LOCAL_CFLAGS += -DLOG_TAG=\"EvsSampleDriver\"
 LOCAL_CFLAGS += -DGL_GLEXT_PROTOTYPES -DEGL_EGLEXT_PROTOTYPES
 LOCAL_CFLAGS += -Wall -Werror -Wunused -Wunreachable-code
+LOCAL_CFLAGS += -Iframeworks/native/include

 # NOTE:  It can be helpful, while debugging, to disable optimizations
 #LOCAL_CFLAGS += -O0 -g
diff --git a/evs/sampleDriver/service.cpp b/evs/sampleDriver/service.cpp
index d8fb31669..5fd029358 100644
--- a/evs/sampleDriver/service.cpp
+++ b/evs/sampleDriver/service.cpp
@@ -21,6 +21,7 @@
 #include <utils/Errors.h>
 #include <utils/StrongPointer.h>
 #include <utils/Log.h>
+#include <binder/ProcessState.h>

 #include "ServiceNames.h"
 #include "EvsEnumerator.h"
@@ -43,6 +44,9 @@ using namespace android;
 int main() {
     ALOGI("EVS Hardware Enumerator service is starting");
+    // Use /dev/binder for SurfaceFlinger
+    ProcessState::initWithDriver("/dev/binder");
+
     // Start a thread to listen video device addition events.
     std::atomic<bool> running { true };
     std::thread ueventHandler(EvsEnumerator::EvsUeventThread, std::ref(running));
diff --git a/evs/sepolicy/evs_driver.te b/evs/sepolicy/evs_driver.te
index f1f31e9fc..632fc7337 100644
--- a/evs/sepolicy/evs_driver.te
+++ b/evs/sepolicy/evs_driver.te
@@ -3,6 +3,9 @@ type hal_evs_driver, domain, coredomain;
 hal_server_domain(hal_evs_driver, hal_evs)
 hal_client_domain(hal_evs_driver, hal_evs)

+# allow to use /dev/binder
+typeattribute hal_evs_driver binder_in_vendor_violators;
+
 # allow init to launch processes in this context
 type hal_evs_driver_exec, exec_type, file_type, system_file_type;
 init_daemon_domain(hal_evs_driver)
@@ -22,3 +25,7 @@ allow hal_evs_driver ion_device:chr_file r_file_perms;

 # Allow the driver to access kobject uevents
 allow hal_evs_driver self:netlink_kobject_uevent_socket create_socket_perms_no_ioctl;
+
+# Allow the driver to use the binder device
+allow hal_evs_driver binder_device:chr_file rw_file_perms;