Google berkomitmen untuk memajukan ekuitas ras untuk komunitas kulit hitam. Lihat bagaimana.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Versi

HIDL mengharuskan setiap antarmuka yang ditulis dalam HIDL diversi. Setelah antarmuka HAL diterbitkan, ia dibekukan dan perubahan lebih lanjut harus dilakukan ke versi baru antarmuka itu. Meskipun antarmuka yang diterbitkan tidak dapat dimodifikasi, namun dapat diperluas oleh antarmuka lain.

Struktur kode HIDL

Kode HIDL diatur dalam tipe, antarmuka, dan paket yang ditentukan pengguna:

  • Jenis yang ditentukan pengguna (UDT) . HIDL menyediakan akses ke serangkaian tipe data primitif yang dapat digunakan untuk menyusun tipe yang lebih kompleks melalui struktur, serikat pekerja, dan enumerasi. UDT dilewatkan ke metode antarmuka, dan dapat didefinisikan pada tingkat paket (umum untuk semua antarmuka) atau secara lokal ke antarmuka.
  • Antarmuka . Sebagai blok bangunan dasar HIDL, antarmuka terdiri dari UDT dan deklarasi metode. Antarmuka juga dapat mewarisi dari antarmuka lain.
  • Paket . Mengatur antarmuka HIDL terkait dan tipe data tempat mereka beroperasi. Paket diidentifikasi dengan nama dan versi dan termasuk yang berikut ini:
    • File definisi tipe data disebut types.hal .
    • Nol atau lebih antarmuka, masing-masing dalam file .hal mereka sendiri.

File tipe definisi data types.hal hanya berisi UDT (semua UDT tingkat paket disimpan dalam satu file). Representasi dalam bahasa target tersedia untuk semua antarmuka dalam paket.

Filosofi versi

Paket HIDL (seperti android.hardware.nfc ), setelah diterbitkan untuk versi tertentu (seperti 1.0 ), tidak dapat diubah; itu tidak bisa diubah. Modifikasi ke antarmuka dalam paket atau perubahan pada UDT-nya hanya dapat terjadi di paket lain .

Di HIDL, versi berlaku di tingkat paket, bukan di tingkat antarmuka, dan semua antarmuka dan UDT dalam paket berbagi versi yang sama. Versi paket mengikuti versi semantik tanpa level patch dan komponen build-metadata. Di dalam paket yang diberikan, versi kecil benjolan menyiratkan versi baru dari paket tersebut kompatibel dengan paket lama dan versi besar benjolan menyiratkan bahwa versi baru paket tidak kompatibel dengan paket lama.

Secara konseptual, sebuah paket dapat berhubungan dengan paket lain dengan salah satu dari beberapa cara berikut:

  • Tidak semuanya .
  • Paket-tingkat ekstensi kompatibel dengan mundur . Ini terjadi untuk uprev versi minor baru (revisi tambahan berikutnya) dari sebuah paket; paket baru memiliki nama dan versi utama yang sama dengan paket lama, tetapi versi minor yang lebih tinggi. Secara fungsional, paket baru adalah superset dari paket lama, artinya:
    • Antarmuka tingkat atas dari paket induk ada dalam paket baru, meskipun antarmuka mungkin memiliki metode baru, UDT antarmuka-lokal baru (ekstensi tingkat antarmuka yang dijelaskan di bawah), dan UDT baru di types.hal .
    • Antarmuka baru juga dapat ditambahkan ke paket baru.
    • Semua tipe data paket induk ada dalam paket baru dan dapat ditangani dengan metode (mungkin diimplementasikan kembali) dari paket lama.
    • Tipe data baru juga dapat ditambahkan untuk digunakan dengan metode baru dari antarmuka yang sudah ada yang diperbaiki, atau oleh antarmuka baru.
  • Ekstensibilitas yang kompatibel dengan antarmuka tingkat . Paket baru juga dapat memperluas paket asli dengan terdiri dari antarmuka yang terpisah secara logis yang hanya menyediakan fungsionalitas tambahan, dan bukan yang intinya. Untuk tujuan ini, berikut ini mungkin diinginkan:
    • Antarmuka dalam paket baru membutuhkan bantuan untuk tipe data dari paket lama.
    • Antarmuka dalam paket baru dapat memperluas antarmuka satu atau lebih paket lama.
  • Perpanjang ke belakang-ketidakcocokan yang asli . Ini adalah versi utama dari paket dan tidak perlu ada korelasi antara keduanya. Sejauh ada, itu dapat diekspresikan dengan kombinasi jenis dari versi yang lebih lama dari paket, dan warisan dari subset dari antarmuka paket lama.

Penataan antarmuka

Untuk antarmuka yang terstruktur dengan baik, menambahkan jenis fungsionalitas baru yang bukan bagian dari desain asli harus memerlukan modifikasi pada antarmuka HIDL. Sebaliknya, jika Anda dapat atau berharap untuk membuat perubahan di kedua sisi antarmuka yang memperkenalkan fungsi baru tanpa mengubah antarmuka itu sendiri, maka antarmuka tidak terstruktur.

Treble mendukung vendor yang dikompilasi secara terpisah dan komponen sistem di mana vendor.img pada perangkat dan system.img dapat dikompilasi secara terpisah. Semua interaksi antara vendor.img dan system.img harus didefinisikan secara eksplisit dan menyeluruh sehingga mereka dapat terus bekerja selama bertahun-tahun. Ini termasuk banyak permukaan API, tetapi permukaan utama adalah mekanisme IPC yang digunakan HIDL untuk komunikasi antar proses pada batas system.img / vendor.img .

Persyaratan

Semua data yang melewati HIDL harus ditentukan secara eksplisit. Untuk memastikan implementasi dan klien dapat terus bekerja sama meskipun dikompilasi secara terpisah atau dikembangkan secara independen, data harus mematuhi persyaratan berikut:

  • Dapat dijelaskan dalam HIDL secara langsung (menggunakan struct enums, dll.) Dengan nama dan makna semantik.
  • Dapat dijelaskan oleh standar publik seperti ISO / IEC 7816.
  • Dapat dijelaskan oleh standar perangkat keras atau tata letak fisik perangkat keras.
  • Dapat berupa data buram (seperti kunci publik, id, dll.) Jika perlu.

Jika data buram digunakan, itu harus dibaca hanya oleh satu sisi antarmuka HIDL. Misalnya, jika vendor.img kode memberikan komponen pada system.img pesan string atau vec<uint8_t> data, data yang tidak dapat diurai oleh system.img itu sendiri; itu hanya dapat diteruskan kembali ke vendor.img untuk ditafsirkan. Saat meneruskan nilai dari vendor.img ke kode vendor pada system.img atau ke perangkat lain, format data dan bagaimana penafsirannya harus dijelaskan dengan tepat dan masih merupakan bagian dari antarmuka .

Pedoman

Anda harus dapat menulis implementasi atau klien dari HAL hanya menggunakan file .hal (yaitu Anda tidak perlu melihat sumber Android atau standar publik). Kami menyarankan untuk menentukan perilaku yang diperlukan secara tepat. Pernyataan seperti "suatu implementasi dapat melakukan A atau B" mendorong implementasi untuk menjadi terkait dengan klien yang mereka kembangkan.

Tata letak kode HIDL

HIDL termasuk paket inti dan vendor.

Antarmuka inti HIDL adalah yang ditentukan oleh Google. Paket-paket mereka milik mulai dengan android.hardware. dan dinamai oleh subsistem, berpotensi dengan tingkat penamaan bersarang. Misalnya, paket NFC bernama android.hardware.nfc dan paket kamera adalah android.hardware.camera . Secara umum, paket inti memiliki nama android.hardware. [ name1 ]. [ name2 ] .... Paket HIDL memiliki versi selain namanya. Misalnya, paket android.hardware.camera mungkin ada di versi 3.4 ; ini penting, karena versi paket mempengaruhi penempatannya di pohon sumber.

Semua paket inti ditempatkan di bawah hardware/interfaces/ dalam sistem build. Paket android.hardware. [ name1 ]. [ name2 ] ... pada versi $m.$n berada di bawah hardware/interfaces/name1/name2/ ... /$m.$n/ ; paket android.hardware.camera versi 3.4 ada di direktori hardware/interfaces/camera/3.4/. Pemetaan kode keras ada di antara awalan paket android.hardware. dan jalur hardware/interfaces/ .

Paket non-inti (vendor) adalah yang diproduksi oleh vendor SoC atau ODM. Awalan untuk paket non-inti adalah vendor.$(VENDOR).hardware. di mana $(VENDOR) mengacu pada vendor SoC atau OEM / ODM. Ini memetakan ke vendor/$(VENDOR)/interfaces jalur vendor/$(VENDOR)/interfaces di pohon (pemetaan ini juga merupakan kode-keras).

Nama jenis yang ditentukan pengguna yang sepenuhnya memenuhi syarat

Di HIDL, setiap UDT memiliki nama yang sepenuhnya memenuhi syarat yang terdiri dari nama UDT, nama paket tempat UDT didefinisikan, dan versi paket. Nama yang sepenuhnya memenuhi syarat digunakan hanya ketika instance dari tipe tersebut dideklarasikan dan bukan di mana tipe itu sendiri didefinisikan. Sebagai contoh, anggap paket android.hardware.nfc, versi 1.0 mendefinisikan sebuah struct bernama NfcData . Di situs deklarasi (apakah dalam types.hal atau dalam deklarasi antarmuka), deklarasi hanya menyatakan:

struct NfcData {
    vec<uint8_t> data;
};

Saat mendeklarasikan instance dari tipe ini (apakah dalam struktur data atau sebagai parameter metode), gunakan nama tipe yang sepenuhnya memenuhi syarat:

android.hardware.nfc@1.0::NfcData

Sintaks umum adalah PACKAGE @ VERSION :: UDT , di mana:

  • PACKAGE adalah nama dot-terpisah dari paket HIDL (misalnya, android.hardware.nfc ).
  • VERSION adalah format major.minor-versi terpisah dari paket (mis., 1.0 ).
  • UDT adalah nama dot-terpisah dari UDT HIDL. Karena HIDL mendukung UDT bersarang dan antarmuka HIDL dapat berisi UDT (sejenis deklarasi bersarang), titik digunakan untuk mengakses nama.

Misalnya, jika deklarasi bersarang berikut ini didefinisikan dalam file tipe umum dalam paket android.hardware.example versi 1.0 :

// types.hal
package android.hardware.example@1.0;
struct Foo {
    struct Bar {
        // …
    };
    Bar cheers;
};

Nama yang sepenuhnya memenuhi syarat untuk Bar adalah android.hardware.example@1.0::Foo.Bar . Jika, selain berada di paket di atas, deklarasi bersarang berada dalam antarmuka yang disebut IQuux :

// IQuux.hal
package android.hardware.example@1.0;
interface IQuux {
    struct Foo {
        struct Bar {
            // …
        };
        Bar cheers;
    };
    doSomething(Foo f) generates (Foo.Bar fb);
};

Nama yang sepenuhnya memenuhi syarat untuk Bar adalah android.hardware.example@1.0::IQuux.Foo.Bar .

Dalam kedua kasus, Bar dapat disebut sebagai Bar hanya dalam lingkup deklarasi Foo . Pada tingkat paket atau antarmuka, Anda harus merujuk ke Bar via Foo : Foo.Bar , seperti dalam deklarasi metode doSomething atas. Atau, Anda dapat mendeklarasikan metode ini lebih jelas sebagai:

// IQuux.hal
doSomething(android.hardware.example@1.0::IQuux.Foo f) generates (android.hardware.example@1.0::IQuux.Foo.Bar fb);

Nilai enumerasi yang sepenuhnya memenuhi syarat

Jika UDT adalah tipe enum, maka setiap nilai dari tipe enum memiliki nama yang sepenuhnya memenuhi syarat yang dimulai dengan nama yang sepenuhnya memenuhi syarat dari tipe enum, diikuti oleh titik dua, kemudian diikuti dengan nama nilai enum. Misalnya, anggap paket android.hardware.nfc, versi 1.0 mendefinisikan tipe enum NfcStatus :

enum NfcStatus {
    STATUS_OK,
    STATUS_FAILED
};

Saat merujuk ke STATUS_OK , nama yang sepenuhnya memenuhi syarat adalah:

android.hardware.nfc@1.0::NfcStatus:STATUS_OK

Sintaks umum adalah PACKAGE @ VERSION :: UDT : VALUE , di mana:

  • PACKAGE @ VERSION :: UDT adalah nama yang sepenuhnya sama persis untuk tipe enum.
  • VALUE adalah nama nilainya.

Aturan inferensi otomatis

Nama UDT yang sepenuhnya memenuhi syarat tidak perlu ditentukan. Nama UDT dapat dengan aman menghilangkan yang berikut:

  • Paket, misalnya @1.0::IFoo.Type
  • Baik paket dan versi, mis. IFoo.Type

HIDL berupaya melengkapi nama menggunakan aturan gangguan otomatis (angka aturan yang lebih rendah berarti prioritas yang lebih tinggi).

Aturan 1

Jika tidak ada paket dan versi yang disediakan, pencarian nama lokal akan dicoba. Contoh:

interface Nfc {
    typedef string NfcErrorMessage;
    send(NfcData d) generates (@1.0::NfcStatus s, NfcErrorMessage m);
};

NfcErrorMessage dilihat secara lokal, dan typedef di atasnya ditemukan. NfcData juga dicari secara lokal, tetapi karena tidak didefinisikan secara lokal, aturan 2 dan 3 digunakan. @1.0::NfcStatus menyediakan versi, jadi aturan 1 tidak berlaku.

Aturan 2

Jika aturan 1 gagal dan komponen dari nama yang sepenuhnya memenuhi syarat tidak ada (paket, versi, atau paket dan versi), komponen akan diisi secara otomatis dengan informasi dari paket saat ini. Kompiler HIDL kemudian mencari dalam file saat ini (dan semua impor) untuk menemukan nama yang sepenuhnya memenuhi syarat autofilled. Dengan menggunakan contoh di atas, anggap deklarasi ExtendedNfcData dibuat dalam paket yang sama ( android.hardware.nfc ) pada versi yang sama ( 1.0 ) seperti NfcData , sebagai berikut:

struct ExtendedNfcData {
    NfcData base;
    // … additional members
};

Kompiler HIDL mengisi nama paket dan nama versi dari paket saat ini untuk menghasilkan nama UDT yang sepenuhnya memenuhi syarat android.hardware.nfc@1.0::NfcData . Karena nama ada dalam paket saat ini (dengan asumsi itu diimpor dengan benar), itu digunakan untuk deklarasi.

Nama dalam paket saat ini hanya diimpor jika salah satu dari berikut ini benar:

  • Itu diimpor secara eksplisit dengan pernyataan import .
  • Ini didefinisikan dalam types.hal dalam paket saat ini

Proses yang sama diikuti jika NfcData hanya memenuhi syarat dengan nomor versi:

struct ExtendedNfcData {
    // autofill the current package name (android.hardware.nfc)
    @1.0::NfcData base;
    // … additional members
};

Aturan 3

Jika aturan 2 gagal menghasilkan kecocokan (UDT tidak didefinisikan dalam paket saat ini), kompiler HIDL memindai kecocokan dalam semua paket yang diimpor. Dengan menggunakan contoh di atas, anggap ExtendedNfcData dideklarasikan dalam versi 1.1 dari paket android.hardware.nfc , 1.1 mengimpor 1.0 sebagaimana mestinya (lihat Ekstensi Tingkat-Paket ), dan definisi hanya menentukan nama UDT:

struct ExtendedNfcData {
    NfcData base;
    // … additional members
};

Compiler mencari setiap UDT bernama NfcData dan menemukannya di android.hardware.nfc di versi 1.0 , menghasilkan UDT yang sepenuhnya memenuhi syarat android.hardware.nfc@1.0::NfcData . Jika lebih dari satu kecocokan ditemukan untuk UDT yang memenuhi syarat sebagian, kompiler HIDL melempar kesalahan.

Contoh

Menggunakan aturan 2, tipe impor yang didefinisikan dalam paket saat ini lebih disukai daripada tipe yang diimpor dari paket lain:

// hardware/interfaces/foo/1.0/types.hal
package android.hardware.foo@1.0;
struct S {};

// hardware/interfaces/foo/1.0/IFooCallback.hal
package android.hardware.foo@1.0;
interface IFooCallback {};

// hardware/interfaces/bar/1.0/types.hal
package android.hardware.bar@1.0;
typedef string S;

// hardware/interfaces/bar/1.0/IFooCallback.hal
package android.hardware.bar@1.0;
interface IFooCallback {};

// hardware/interfaces/bar/1.0/IBar.hal
package android.hardware.bar@1.0;
import android.hardware.foo@1.0;
interface IBar {
    baz1(S s); // android.hardware.bar@1.0::S
    baz2(IFooCallback s); // android.hardware.foo@1.0::IFooCallback
};
  • S diinterpolasi sebagai android.hardware.bar@1.0::S , dan ditemukan di bar/1.0/types.hal (karena types.hal diimpor secara otomatis).
  • IFooCallback diinterpolasi sebagai android.hardware.bar@1.0::IFooCallback menggunakan aturan 2, tetapi tidak dapat ditemukan karena bar/1.0/IFooCallback.hal tidak diimpor secara otomatis (seperti types.hal adalah). Dengan demikian, aturan 3 menyelesaikannya ke android.hardware.foo@1.0::IFooCallback sebagai gantinya, yang diimpor melalui import android.hardware.foo@1.0; ).

types.hal

Setiap paket HIDL berisi file types.hal berisi UDT yang dibagi di antara semua antarmuka yang berpartisipasi dalam paket itu. Jenis HIDL selalu bersifat publik; terlepas dari apakah UDT dideklarasikan dalam types.hal atau dalam deklarasi antarmuka, tipe ini dapat diakses di luar ruang lingkup di mana mereka didefinisikan. types.hal tidak dimaksudkan untuk menggambarkan API publik dari suatu paket, melainkan untuk meng-host UDT yang digunakan oleh semua antarmuka dalam paket. Karena sifat HIDL, semua UDT adalah bagian dari antarmuka.

types.hal terdiri dari UDT dan pernyataan import . Karena types.hal tersedia untuk setiap antarmuka paket (ini adalah impor implisit), pernyataan import ini adalah tingkat paket menurut definisi. UDT dalam types.hal juga dapat menggabungkan UDT dan antarmuka yang diimpor.

Misalnya, untuk IFoo.hal :

package android.hardware.foo@1.0;
// whole package import
import android.hardware.bar@1.0;
// types only import
import android.hardware.baz@1.0::types;
// partial imports
import android.hardware.qux@1.0::IQux.Quux;
// partial imports
import android.hardware.quuz@1.0::Quuz;

Yang berikut ini diimpor:

  • android.hidl.base@1.0::IBase (tersirat)
  • android.hardware.foo@1.0::types (tersirat)
  • Semua yang ada di android.hardware.bar@1.0 (termasuk semua antarmuka dan types.hal )
  • types.hal dari android.hardware.baz@1.0::types (antarmuka di android.hardware.baz@1.0 tidak diimpor)
  • IQux.hal dan types.hal dari android.hardware.qux@1.0
  • Quuz dari android.hardware.quuz@1.0 (dengan asumsi Quuz didefinisikan dalam types.hal , seluruh file types.hal diuraikan, tetapi tipe selain Quuz tidak diimpor).

Versi tingkat antarmuka

Setiap antarmuka dalam suatu paket berada di file-nya sendiri. Paket milik antarmuka dinyatakan di bagian atas antarmuka menggunakan pernyataan package . Setelah deklarasi paket, nol atau lebih impor tingkat antarmuka (sebagian atau seluruh paket) dapat didaftar. Sebagai contoh:

package android.hardware.nfc@1.0;

Di HIDL, antarmuka dapat mewarisi dari antarmuka lain menggunakan kata kunci extends . Agar antarmuka dapat memperluas antarmuka lain, antarmuka harus memiliki akses melalui pernyataan import . Nama antarmuka yang diperluas (antarmuka dasar) mengikuti aturan untuk kualifikasi tipe-nama yang dijelaskan di atas. Antarmuka hanya dapat mewarisi dari satu antarmuka; HIDL tidak mendukung multiple inheritance.

Contoh-contoh versi uprev di bawah ini menggunakan paket berikut:

// types.hal
package android.hardware.example@1.0
struct Foo {
    struct Bar {
        vec<uint32_t> val;
    };
};

// IQuux.hal
package android.hardware.example@1.0
interface IQuux {
    fromFooToBar(Foo f) generates (Foo.Bar b);
}

Aturan Uprev

Untuk mendefinisikan paket package@major.minor , A atau semua B harus benar:

Aturan A "Adalah versi awal minor": Semua versi minor sebelumnya, package@major.0 , package@major.1 , ..., package@major.(minor-1) tidak boleh didefinisikan.
ATAU
Aturan B

Semua hal berikut ini benar:

  1. "Versi minor sebelumnya valid": package@major.(minor-1) harus didefinisikan dan mengikuti aturan yang sama A (tidak ada package@major.0 melalui package@major.(minor-2) didefinisikan) atau aturan B (jika uprev dari @major.(minor-2) );

    DAN

  2. "Mewarisi setidaknya satu antarmuka dengan nama yang sama": Ada antarmuka package@major.minor::IFoo yang memperluas package@major.(minor-1)::IFoo (jika paket sebelumnya memiliki antarmuka);

    DAN

  3. "Tidak ada antarmuka bawaan dengan nama yang berbeda": Tidak boleh ada package@major.minor::IBar yang memperluas package@major.(minor-1)::IBaz , di mana IBar dan IBaz adalah dua nama yang berbeda. Jika ada antarmuka dengan nama yang sama, package@major.minor::IBar harus memperluas package@major.(minor-k)::IBar sedemikian rupa sehingga tidak ada IBar dengan k yang lebih kecil.

Karena aturan A:

  • Paket ini dapat dimulai dengan nomor versi minor apa saja (misalnya, android.hardware.biometrics.fingerprint dimulai pada @2.1 .)
  • Persyaratan " android.hardware.foo@1.0 tidak didefinisikan" berarti hardware/interfaces/foo/1.0 direktori hardware/interfaces/foo/1.0 bahkan tidak boleh ada.

Namun, aturan A tidak memengaruhi paket dengan nama paket yang sama tetapi versi utama yang berbeda (misalnya, android.hardware.camera.device memiliki @1.0 dan @3.2 ditentukan; @3.2 tidak perlu berinteraksi dengan @1.0 .) Oleh karena itu, @3.2::IExtFoo dapat memperluas @1.0::IFoo .

Asalkan nama paket berbeda, package@major.minor::IBar dapat diperluas dari antarmuka dengan nama yang berbeda (misalnya, android.hardware.bar@1.0::IBar dapat memperluas android.hardware.baz@2.2::IBaz ). Jika sebuah antarmuka tidak secara eksplisit mendeklarasikan tipe super dengan kata kunci extend , itu akan memperluas android.hidl.base@1.0::IBase (kecuali IBase itu sendiri).

B.2 dan B.3 harus diikuti secara bersamaan. Misalnya, bahkan jika android.hardware.foo@1.1::IFoo memperluas android.hardware.foo@1.0::IFoo untuk melewati aturan B.2, jika android.hardware.foo@1.1::IExtBar memperluas android.hardware.foo@1.0::IBar , ini masih belum uprev yang valid.

Menambah antarmuka

Untuk meningkatkan android.hardware.example@1.0 (didefinisikan di atas) ke @1.1 :

// types.hal
package android.hardware.example@1.1;
import android.hardware.example@1.0;

// IQuux.hal
package android.hardware.example@1.1
interface IQuux extends @1.0::IQuux {
    fromBarToFoo(Foo.Bar b) generates (Foo f);
}

Ini adalah import tingkat paket versi 1.0 dari android.hardware.example dalam types.hal . Meskipun tidak ada UDT baru yang ditambahkan dalam versi 1.1 paket, referensi ke UDT dalam versi 1.0 masih diperlukan, karenanya impor tingkat paket di types.hal . (Efek yang sama dapat dicapai dengan impor tingkat antarmuka di IQuux.hal .)

Dalam extends @1.0::IQuux dalam deklarasi IQuux , kami menentukan versi IQuux yang sedang diwarisi (disambiguasi diperlukan karena IQuux digunakan untuk mendeklarasikan antarmuka dan mewarisi dari antarmuka). Karena deklarasi hanyalah nama yang mewarisi semua paket dan atribut versi di situs deklarasi, disambiguasi harus atas nama antarmuka dasar; kami bisa menggunakan UDT yang sepenuhnya memenuhi syarat juga, tetapi itu akan menjadi berlebihan.

Antarmuka baru IQuux tidak mendeklarasikan ulang metode fromFooToBar() yang diwarisi dari @1.0::IQuux ; itu hanya mencantumkan metode baru yang ditambahkan fromBarToFoo() . Di HIDL, metode yang diwariskan tidak dapat dideklarasikan lagi di antarmuka anak, sehingga antarmuka IQuux tidak dapat mendeklarasikan metode fromFooToBar() secara eksplisit.

Konvensi Uprev

Terkadang nama antarmuka harus mengganti nama antarmuka yang diperluas. Kami merekomendasikan bahwa ekstensi enum, struct, dan serikat memiliki nama yang sama seperti apa yang mereka kembangkan kecuali mereka cukup berbeda untuk menjamin nama baru. Contoh:

// in parent hal file
enum Brightness : uint32_t { NONE, WHITE };

// in child hal file extending the existing set with additional similar values
enum Brightness : @1.0::Brightness { AUTOMATIC };

// extending the existing set with values that require a new, more descriptive name:
enum Color : @1.0::Brightness { HW_GREEN, RAINBOW };

Jika suatu metode dapat memiliki nama semantik baru (misalnya fooWithLocation ) maka itu lebih disukai. Kalau tidak, itu harus dinamai sama dengan apa yang diperluas. Misalnya, metode foo_1_1 di @1.1::IFoo dapat mengganti fungsionalitas metode foo di @1.0::IFoo jika tidak ada nama alternatif yang lebih baik.

Versi tingkat paket

Versi HIDL terjadi di tingkat paket; setelah suatu paket diterbitkan, ia tidak dapat diubah (set antarmuka dan UDT tidak dapat diubah). Paket dapat berhubungan satu sama lain dalam beberapa cara, yang semuanya dapat diekspresikan melalui kombinasi warisan tingkat antarmuka dan pembangunan UDT dengan komposisi.

Namun, satu jenis hubungan didefinisikan secara ketat dan harus ditegakkan: pewarisan kompatibel tingkat-paket . Dalam skenario ini, paket induk adalah paket yang diwarisi dari dan paket anak adalah paket yang memperpanjang induknya. Aturan pewarisan yang kompatibel dengan tingkat paket adalah sebagai berikut:

  1. Semua antarmuka tingkat atas dari paket induk diwarisi dari oleh antarmuka dalam paket anak.
  2. Antarmuka baru juga dapat ditambahkan paket baru (tidak ada batasan tentang hubungan ke antarmuka lain dalam paket lain).
  3. Tipe data baru juga dapat ditambahkan untuk digunakan dengan metode baru dari antarmuka yang sudah ada yang diperbaiki, atau oleh antarmuka baru.

Aturan-aturan ini dapat diimplementasikan menggunakan pewarisan level antarmuka HIDL dan komposisi UDT, tetapi membutuhkan pengetahuan meta-level untuk mengetahui hubungan ini merupakan ekstensi paket yang kompatibel dengan mundur. Pengetahuan ini disimpulkan sebagai berikut:

Jika sebuah paket memenuhi persyaratan ini, hidl-gen memberlakukan aturan kompatibilitas mundur.