Membuat antarmuka HAL

Anda harus menggunakan HIDL untuk menjelaskan semua flag build yang digunakan untuk secara kondisional mengompilasi kerangka kerja. Flag build yang relevan harus dikelompokkan dan disertakan dalam file .hal tunggal. Menggunakan HIDL untuk menentukan item konfigurasi mencakup manfaat berikut:

  • Berversi (untuk menambahkan item konfigurasi baru, vendor/OEM harus secara eksplisit memperluas HAL)
  • Terdokumentasi dengan baik
  • Kontrol akses menggunakan SELinux
  • Pemeriksaan kesehatan untuk item konfigurasi melalui Pengujian Vendor Suite (pemeriksaan rentang, pemeriksaan inter-dependensi antar-item, dll.)
  • API yang dibuat secara otomatis di C++ dan Java

Mengidentifikasi flag build yang digunakan oleh framework

Mulai dengan mengidentifikasi konfigurasi build yang digunakan untuk mengompilasi secara kondisional , lalu tinggalkan konfigurasi yang sudah tidak digunakan untuk memperkecil set. Misalnya, kumpulan tanda build berikut diidentifikasi untuk surfaceflinger:

  • TARGET_USES_HWC2
  • TARGET_BOARD_PLATFORM
  • TARGET_DISABLE_TRIPLE_BUFFERING
  • TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
  • NUM_FRAMEBUFFER_SURFACE_BUFFERS
  • TARGET_RUNNING_WITHOUT_SYNC_FRAMEWORK
  • VSYNC_EVENT_PHASE_OFFSET_NS
  • SF_VSYNC_EVENT_PHASE_OFFSET_NS
  • PRESENT_TIME_OFFSET_FROM_VSYNC_NS
  • MAX_VIRTUAL_DISPLAY_DIMENSION

Membuat antarmuka HAL

Konfigurasi build untuk subsistem diakses melalui antarmuka HAL, sementara antarmuka untuk memberikan nilai konfigurasi dikelompokkan dalam paket HAL android.hardware.configstore (saat ini menggunakan versi 1.0). Misalnya, untuk membuat file antarmuka HAL untuk surfaceflinger, di hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal: 

package android.hardware.configstore@1.0;

interface ISurfaceFlingerConfigs {
    // TO-BE-FILLED-BELOW
};

Setelah membuat file .hal, jalankan hardware/interfaces/update-makefiles.sh untuk menambahkan .hal ke Android.bp dan Android.mk.

Menambahkan fungsi untuk tanda build

Untuk setiap flag build, tambahkan fungsi baru ke antarmuka. Misalnya, di hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal: 

interface ISurfaceFlingerConfigs {
    disableTripleBuffering() generates(OptionalBool ret);
    forceHwcForVirtualDisplays() generates(OptionalBool ret);
    enum NumBuffers: uint8_t {
        USE_DEFAULT = 0,
        TWO = 2,
        THREE = 3,
    };
    numFramebufferSurfaceBuffers() generates(NumBuffers ret);
    runWithoutSyncFramework() generates(OptionalBool ret);
    vsyncEventPhaseOffsetNs generates (OptionalUInt64 ret);
    presentTimeOffsetFromSyncNs generates (OptionalUInt64 ret);
    maxVirtualDisplayDimension() generates(OptionalInt32 ret);
};

Saat menambahkan fungsi:

  • Sampaikan nama dengan ringkas. Menghindari konversi variabel makefile nama menjadi nama fungsi dan perlu diingat bahwa TARGET_ dan Awalan BOARD_ tidak lagi diperlukan.
  • Menambahkan komentar. Bantu developer memahami tujuan item konfigurasi, cara mengubah perilaku framework, nilai yang valid, dan tidak akurat atau tidak sesuai.

Jenis nilai yang ditampilkan fungsi dapat Optional[Bool|String|Int32|UInt32|Int64|UInt64]. Jenis ditentukan di types.hal pada direktori yang sama dan gabungkan nilai primitif dengan isian yang menunjukkan apakah nilai ditentukan oleh HAL; jika tidak, setelan default nilai default yang digunakan.

struct OptionalString {
    bool specified;
    string value;
};

Jika perlu, tentukan enum yang paling mewakili jenis dan menggunakan enum tersebut sebagai jenis nilai yang ditampilkan. Pada contoh di atas, enum NumBuffers ditentukan untuk membatasi jumlah masing-masing. Saat menentukan jenis data khusus tersebut, tambahkan bidang atau nilai enum (untuk contoh, USE_DEFAULT) untuk menunjukkan jika nilai tidak ditentukan oleh HAL.

Tidak wajib flag build tunggal menjadi fungsi tunggal di HIDL. Pemilik modul juga dapat menggabungkan flag build yang terkait erat ke dalam sebuah struct dan memiliki fungsi yang mengembalikan struktur itu (melakukannya dapat mengurangi jumlah panggilan fungsi).

Misalnya, opsi untuk menggabungkan dua flag build ke dalam satu struct dalam hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal adalah:

 interface ISurfaceFlingerConfigs {
    // other functions here
    struct SyncConfigs {
        OptionalInt64 vsyncEventPhaseoffsetNs;
        OptionalInt64 presentTimeoffsetFromSyncNs;
    };
    getSyncConfigs() generates (SyncConfigs ret);
    // other functions here
};

Alternatif untuk fungsi HAL tunggal

Sebagai alternatif penggunaan fungsi HAL tunggal untuk semua penanda build, HAL antarmuka ini juga menyediakan fungsi sederhana seperti getBoolean(string key) dan getInteger(string key). Sebenarnya Pasangan key=value disimpan dalam file terpisah dan layanan HAL memberikan nilai dengan membaca/menguraikan file-file tersebut.

Meskipun pendekatan ini mudah didefinisikan, tetapi tidak menyertakan manfaatnya disediakan oleh HIDL (pembuatan versi yang ditegakkan, kemudahan dokumentasi, kontrol akses) dan oleh karena itu tidak direkomendasikan.

Satu dan beberapa antarmuka

Desain antarmuka HAL untuk item konfigurasi menyajikan dua pilihan:

  • Satu antarmuka yang mencakup semua item konfigurasi
  • Beberapa antarmuka, yang masing-masing mencakup sekumpulan konfigurasi terkait item

Satu antarmuka lebih mudah tetapi bisa menjadi tidak bisa dikelola karena lebih item konfigurasi ditambahkan ke satu file. Selain itu, kontrol akses tidak halus, jadi proses yang diberikan akses ke antarmuka dapat membaca semua item konfigurasi (akses ke sebagian item konfigurasi tidak dapat diberikan). Atau, jika akses tidak diberikan, item konfigurasi tidak dapat dibaca.

Karena masalah ini, Android menggunakan beberapa antarmuka dengan satu HAL antarmuka untuk sekelompok item konfigurasi yang terkait. Misalnya, ISurfaceflingerConfigs untuk terkait surfaceflinger item konfigurasi, dan IBluetoothConfigs untuk terkait Bluetooth item konfigurasi.