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

Kamera Kendaraan HAL

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

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

Komponen sistem

EVS mencakup komponen sistem berikut:

Diagram komponen Sistem EVS.
Gambar 1. Gambaran umum komponen Sistem EVS.

Aplikasi EVS

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

EVS Manager

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

Antarmuka EVS HIDL

Sistem EVS, baik kamera maupun elemen tampilan, ditentukan dalam paket android.hardware.automotive.evs . Contoh implementasi yang melatih antarmuka (menghasilkan gambar uji sintetis dan memvalidasi gambar yang dibuat pulang pergi) tersedia di /hardware/interfaces/automotive/evs/1.0/default .

OEM bertanggung jawab untuk mengimplementasikan API yang dinyatakan 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 implementasi bertanggung jawab untuk menyediakan buffer memori bersama yang dapat diisi oleh aplikasi (biasanya melalui rendering EGL) dan menampilkan frame yang sudah selesai dalam preferensi untuk hal lain yang mungkin ingin muncul pada tampilan fisik. Implementasi vendor dari antarmuka EVS dapat disimpan di /vendor/… /device/… atau hardware/… (misalnya, /hardware/[vendor]/[platform]/evs ).

Driver kernel

Perangkat yang mendukung tumpukan EVS membutuhkan 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 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 di sistem (satu atau lebih kamera dan perangkat layar tunggal).

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

Mengembalikan vektor yang berisi deskripsi untuk semua kamera di sistem. Diasumsikan bahwa set kamera sudah diperbaiki dan dapat diketahui pada 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 jika gagal. Upaya untuk membuka kembali kamera yang sudah terbuka tidak bisa 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 didahului dengan cara ini harus dalam keadaan tidak aktif, menunggu penghancuran akhir dan menanggapi permintaan apa pun untuk memengaruhi status kamera dengan kode pengembalian OWNERSHIP_LOST .

closeCamera(IEvsCamera camera);

Merilis antarmuka IEvsCamera (dan merupakan kebalikan dari panggilan openCamera() ). Streaming 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 contoh fungsional IEvsDisplay pada saat itu. Mirip dengan perilaku terbuka agresif yang dijelaskan dalam openCamera , objek IEvsDisplay baru dapat dibuat kapan saja dan akan menonaktifkan semua instance sebelumnya. Instance yang tidak divalidasi terus ada dan merespons panggilan fungsi dari pemiliknya, tetapi tidak boleh melakukan operasi mutasi saat mati. Akhirnya, aplikasi klien diharapkan untuk melihat kode pengembalian kesalahan OWNERSHIP_LOST dan menutup dan melepaskan antarmuka yang tidak aktif.

closeDisplay(IEvsDisplay display);

Merilis antarmuka IEvsDisplay (dan merupakan kebalikan dari panggilan openDisplay() ). Buffer yang diterima melalui panggilan getTargetBuffer() harus dikembalikan ke tampilan sebelum menutup tampilan.

getDisplayState() generates (DisplayState state);

Mendapat status tampilan saat ini. Implementasi HAL harus melaporkan status aktual saat ini, yang mungkin berbeda dari status 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 melaporkan status EVS Display saat ini (lihat IEvsDisplay API ).

struct CameraDesc {
    string      camera_id;
    int32       vendor_flags;       // Opaque value
}
  • camera_id . String yang secara unik mengidentifikasi kamera tertentu. Bisa menjadi nama perangkat kernel dari perangkat atau nama untuk 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 tidak jelas dari pengemudi ke aplikasi EVS khusus. Itu diteruskan tanpa ditafsirkan dari pengemudi hingga aplikasi EVS, yang bebas untuk mengabaikannya.

IEvsCamera

Objek ini mewakili kamera tunggal dan merupakan antarmuka utama untuk mengambil gambar.

getCameraInfo() generates (CameraDesc info);

Mengembalikan CameraDesc kamera ini.

setMaxFramesInFlight(int32 bufferCount) generates (EvsResult result);

Menentukan kedalaman rantai penyangga yang diminta untuk didukung oleh kamera. Hingga saat ini, banyak frame dapat dipegang secara bersamaan oleh klien IEvsCamera. Jika banyak frame ini telah dikirim ke penerima tanpa dikembalikan oleh doneWithFrame , streaming melewati frame sampai buffer dikembalikan untuk digunakan kembali. Ini sah untuk panggilan ini datang kapan saja, bahkan saat streaming sudah berjalan, dalam hal ini buffer harus ditambahkan atau dihapus dari rantai sebagaimana mestinya. Jika tidak ada panggilan yang dilakukan ke titik masuk ini, IEvsCamera mendukung setidaknya satu frame secara default; dengan lebih bisa 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 startVideoStream panggilan startVideoStream dan setelah dimulai, harus dibuat minimal 10 FPS. Waktu yang diperlukan untuk memulai streaming video secara efektif dihitung terhadap persyaratan waktu mulai kamera tampak belakang. Jika streaming tidak dimulai, kode kesalahan harus dikembalikan; jika tidak OK dikembalikan.

oneway doneWithFrame(BufferDesc buffer);

Mengembalikan bingkai yang dikirim oleh ke IEvsCameraStream. Ketika selesai mengonsumsi bingkai yang dikirim ke antarmuka IEvsCameraStream, bingkai harus dikembalikan ke IEvsCamera untuk digunakan kembali. Sejumlah kecil buffer tersedia (mungkin sekecil satu), dan jika persediaan habis, tidak ada frame lagi yang dikirim sampai buffer dikembalikan, berpotensi menghasilkan frame yang dilewati (buffer dengan pegangan null 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 pengirimannya asinkron, frame mungkin terus datang selama beberapa waktu setelah panggilan ini kembali. Setiap bingkai harus dikembalikan hingga penutupan aliran ditandai ke IEvsCameraStream. Adalah legal untuk memanggil stopVideoStream pada aliran yang telah dihentikan atau tidak pernah dimulai, yang dalam kasus ini akan diabaikan.

getExtendedInfo(int32 opaqueIdentifier) generates (int32 value);

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

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

Mengirimkan 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 keadaan default. Jika pengemudi mengenali dan menerima nilai, 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 guna mendeskripsikan buffering gambar dan klien HAL harus memperlakukan struktur ini sebagai hanya-baca. Bidang berisi informasi yang cukup untuk memungkinkan klien merekonstruksi objek ANativeWindowBuffer , karena mungkin diperlukan untuk menggunakan gambar dengan EGL melalui ekstensi eglCreateImageKHR() .

  • width . Lebar piksel dari gambar yang disajikan.
  • height . Tinggi dalam piksel dari gambar yang disajikan.
  • stride . Jumlah piksel yang ditempati setiap baris dalam memori, memperhitungkan padding apa pun 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, yang memungkinkan perhitungan ukuran dalam byte yang diperlukan untuk langkah antara baris dalam gambar ( stride dalam byte = stride dalam pixel * pixelSize ).
  • format . Format piksel yang digunakan oleh gambar. Format yang diberikan harus kompatibel dengan implementasi OpenGL platform. Untuk lulus pengujian kompatibilitas, HAL_PIXEL_FORMAT_YCRCB_420_SP harus diutamakan untuk penggunaan kamera, dan RGBA atau BGRA harus diutamakan untuk tampilan.
  • usage . Bendera penggunaan yang ditetapkan oleh implementasi HAL. Klien HAL diharapkan untuk meneruskan ini tanpa modifikasi (untuk detailnya, lihat flag terkait Gralloc.h ).
  • bufferId . Nilai unik yang ditentukan oleh implementasi HAL untuk memungkinkan buffer dikenali setelah perjalanan bolak-balik melalui HAL API. Nilai yang disimpan di 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. Tuas penyangga yang diterima oleh metode ini harus dikembalikan melalui panggilan ke IEvsCamera::doneWithFrame() . Saat aliran video dihentikan melalui panggilan ke IEvsCamera::stopVideoStream() , callback ini mungkin berlanjut saat pipeline habis. Setiap bingkai masih harus dikembalikan; ketika frame terakhir dalam streaming telah dikirim, bufferHandle NULL akan dikirimkan, yang menandakan akhir dari streaming 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

Sementara format buffer berpemilik secara teknis dimungkinkan, 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 menjadi 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 menggunakan kembali) sesuai keinginan.

IEvsDisplay

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);

Setel status tampilan. Klien dapat menyetel status tampilan untuk mengekspresikan status yang diinginkan, dan implementasi HAL harus dengan baik hati menerima permintaan untuk status apa pun saat berada dalam status lain, meskipun responsnya mungkin mengabaikan permintaan tersebut.

Setelah inisialisasi, tampilan didefinisikan untuk memulai dalam status NOT_VISIBLE , setelah itu klien diharapkan untuk meminta status VISIBLE_ON_NEXT_FRAME dan mulai menyediakan video. Ketika 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 display sudah terlihat, itu akan tetap terlihat jika disetel ke VISIBLE_ON_NEXT_FRAME . Selalu mengembalikan OK kecuali status yang diminta adalah nilai enum yang tidak dikenal, dalam hal ini INVALID_ARG dikembalikan.

getDisplayState() generates (DisplayState state);

Mendapat status tampilan. Implementasi HAL harus melaporkan status aktual saat ini, yang mungkin berbeda dari status 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 penyangga bingkai yang terkait dengan tampilan. Buffer ini mungkin dikunci dan ditulis oleh perangkat lunak dan / atau GL. Buffer ini harus dikembalikan melalui panggilan ke returnTargetBufferForDisplay() meskipun tampilan tidak lagi terlihat.

Sementara format buffer berpemilik secara teknis dimungkinkan, 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 menjadi target render GL yang valid pada implementasi GLES platform.

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

returnTargetBufferForDisplay(handle bufferHandle) generates (EvsResult result);

Memberi tahu 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 mendeskripsikan tampilan EVS. Dapat berupa tampilan fisik atau tampilan virtual yang dilapisi atau dicampur dengan perangkat presentasi lain.

  • display_id . Sebuah string yang secara unik mengidentifikasi tampilan. Ini bisa menjadi nama perangkat kernel dari perangkat tersebut, atau nama untuk perangkat tersebut, seperti "spion". Nilai untuk string ini dipilih oleh implementasi HAL dan digunakan secara tidak jelas oleh tumpukan di atas.
  • vendor_flags . Sebuah metode untuk meneruskan informasi kamera khusus secara opaquely dari pengemudi ke Aplikasi EVS kustom. Itu diteruskan tanpa ditafsirkan dari pengemudi ke 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 (menunjukkan gambar kepada pengemudi). Menyertakan status sementara di mana tampilan belum terlihat tetapi disiapkan untuk menjadi terlihat dengan pengiriman bingkai citra berikutnya melalui panggilan returnTargetBufferForDisplay() .

EVS Manager

EVS Manager menyediakan antarmuka publik ke sistem EVS untuk mengumpulkan dan menyajikan tampilan kamera eksternal. Jika driver perangkat keras hanya mengizinkan satu antarmuka aktif per sumber daya (kamera atau layar), EVS Manager memfasilitasi akses bersama ke kamera. Aplikasi EVS utama tunggal adalah klien pertama dari EVS Manager, dan merupakan satu-satunya klien yang diizinkan untuk menulis data tampilan (klien tambahan dapat diberikan akses hanya baca 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 streaming video).

EVS Manager dan diagram EVS Hardware API.
Gambar 2. EVS Manager mencerminkan EVS Hardware API yang mendasari

Aplikasi tidak melihat perbedaan saat beroperasi melalui implementasi EVS Hardware HAL atau EVS Manager API, kecuali bahwa EVS Manager API memungkinkan akses streaming 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 menjelaskan hanya panggilan yang memiliki perilaku (diperpanjang) berbeda 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 jika gagal. Pada lapisan EVS Manager, selama sumber daya sistem yang memadai tersedia, kamera yang sudah terbuka dapat dibuka lagi oleh proses lain, memungkinkan teeing aliran video ke beberapa aplikasi konsumen. String camera_id di lapisan EVS Manager sama dengan yang dilaporkan ke lapisan EVS Hardware.

IEvsCamera

EVS Manager menyediakan implementasi IEvsCamera divirtualisasi 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 aliran video. Klien dapat secara mandiri memulai dan menghentikan streaming video pada kamera dasar yang sama. Kamera yang mendasari dimulai saat 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 frame yang dipegang oleh klien mencapai batas yang dikonfigurasi, ia tidak akan menerima frame lagi hingga mengembalikan satu frame. Melewati bingkai ini tidak memengaruhi klien lain, yang terus menerima semua bingkai seperti yang diharapkan.

stopVideoStream();

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

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

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

IEvsDisplay

Hanya satu pemilik layar yang diperbolehkan, 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 tampak belakang dasar. Aplikasi ini diharapkan mulai sangat awal dalam proses boot sistem, dengan video yang sesuai ditampilkan tergantung pada kamera yang tersedia dan status mobil (status gigi dan sein). OEM dapat memodifikasi atau mengganti aplikasi EVS dengan logika dan presentasi khusus kendaraan mereka sendiri.

Gambar 3. Contoh logika aplikasi EVS, dapatkan daftar kamera.


Gambar 4. Contoh logika aplikasi EVS, menerima frame callback.

Karena data gambar disajikan ke aplikasi dalam buffer grafis standar, aplikasi bertanggung jawab untuk memindahkan gambar dari buffer sumber ke buffer keluaran. Meskipun hal ini memperkenalkan biaya penyalinan data, ini juga menawarkan kesempatan bagi aplikasi untuk merender gambar ke dalam buffer tampilan dengan cara apa pun yang diinginkan.

Misalnya, aplikasi dapat memilih untuk memindahkan data piksel itu sendiri, kemungkinan dengan operasi skala atau rotasi sebaris. Aplikasi juga dapat memilih untuk menggunakan gambar sumber sebagai tekstur OpenGL dan merender pemandangan 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 secara top-down).

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 sekelompok pustaka yang tersedia untuk pustaka 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 framework / native / libs / gui secara langsung dengan menggunakan target build tambahan dalam 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 parsel. 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 yang lebih tinggi), node perangkat /dev/binder menjadi eksklusif untuk proses framework dan, oleh karena itu, tidak dapat diakses oleh proses vendor. Sebaliknya, proses vendor harus menggunakan /dev/hwbinder dan harus mengonversi antarmuka AIDL apa pun menjadi HIDL. Bagi mereka yang ingin terus menggunakan antarmuka AIDL antar proses vendor, gunakan domain pengikat, /dev/vndbinder .

Domain IPC Deskripsi
/dev/binder IPC antara proses framework / aplikasi dengan antarmuka AIDL
/dev/hwbinder IPC antara proses kerangka / vendor dengan antarmuka HIDL
IPC antara proses vendor dengan antarmuka HIDL
/dev/vndbinder IPC antara proses vendor / vendor dengan Antarmuka AIDL

Sementara SurfaceFlinger mendefinisikan antarmuka AIDL, proses vendor hanya dapat menggunakan antarmuka HIDL untuk berkomunikasi dengan proses kerangka kerja. Sejumlah pekerjaan yang tidak sepele diperlukan untuk mengubah antarmuka AIDL yang ada menjadi HIDL. Untungnya, Android menyediakan metode untuk memilih driver pengikat untuk libbinder , yang ditautkan dengan 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 melakukan panggilan binder.

Kebijakan SELinux

Jika implementasi perangkat treble penuh, SELinux mencegah proses vendor menggunakan /dev/binder . Misalnya, contoh implementasi 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 dalam system/sepolicy/domain.te untuk perangkat treble penuh.

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. Ini 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;