HIDL HALs menjamin sistem inti Android (alias system.img atau framework) kompatibel ke belakang. Sementara pengujian Vendor Test Suite (VTS) memastikan bahwa HAL berfungsi seperti yang diharapkan (misalnya pengujian 1.1 HAL dijalankan pada semua implementasi 1.2), pengujian kerangka kerja diperlukan untuk memastikan bahwa ketika HAL (1.0, 1.1, atau 1.2) yang didukung disediakan, kerangka kerja bekerja dengan baik dengan HAL itu.
Untuk detail tentang bahasa definisi antarmuka HAL (HIDL), lihat HIDL , versi HIDL , dan Penghentian HAL HIDL .
Tentang peningkatan HAL
Ada dua jenis peningkatan HAL: mayor dan minor . Sebagian besar sistem hanya menyertakan satu implementasi HAL, tetapi beberapa implementasi didukung. Sebagai contoh:
android.hardware.teleport@1.0 # initial interface android.hardware.teleport@1.1 # minor version upgrade android.hardware.teleport@1.2 # another minor version upgrade ... android.hardware.teleport@2.0 # major version upgrade ...
Partisi sistem biasanya menyertakan daemon kerangka kerja (seperti teleportd ) yang mengelola komunikasi dengan grup implementasi HAL tertentu. Sebagai alternatif, sistem mungkin menyertakan pustaka sistem (seperti android.hardware.configstore-utils ) yang mengimplementasikan perilaku klien yang nyaman. Pada contoh di atas, teleportd harus berfungsi tidak peduli versi HAL apa yang diinstal pada perangkat.
Versi yang dikelola Google
Jika ada peningkatan versi utama (1.0, 2.0, 3.0, dll.), setidaknya satu perangkat yang dikelola Google harus mempertahankan implementasi setiap versi utama hingga versi tersebut tidak digunakan lagi. Jika tidak ada perangkat yang dikelola Google yang dikirimkan dengan versi utama tertentu, Google terus mempertahankan implementasi lama dari versi utama tersebut.
Pemeliharaan semacam itu menambahkan sedikit overhead tambahan karena implementasi lama (mis. 1.2) dapat disimpan dan tidak digunakan secara default ketika implementasi baru (mis. 2.0) dibuat.
Menguji peningkatan versi kecil
Menguji kompatibilitas mundur versi minor dalam kerangka kerja memerlukan cara untuk menghasilkan implementasi versi minor secara otomatis. Mengingat pembatasan seputar versi yang dikelola Google, hidl-gen hanya akan (dan hanya dapat) menghasilkan adaptor yang menggunakan implementasi 1.(x+n) dan menyediakan implementasi 1.x; itu tidak dapat menghasilkan implementasi 1.0 dari implementasi 2.0 (menurut definisi versi utama).
Misalnya, untuk menjalankan pengujian 1.1 pada implementasi 1.2, Anda harus dapat mensimulasikan implementasi 1.1. Antarmuka 1.2 dapat secara otomatis digunakan sebagai implementasi 1.1 dengan sedikit perbedaan perilaku (seperti kerangka kerja yang secara manual memeriksa versi apa atau memanggil castFrom di atasnya).
Ide dasarnya adalah ini:
- Instal antarmuka x.(y+n) di perangkat seluler Android.
- Instal dan aktifkan adaptor xy-target.
- Uji perangkat untuk memverifikasi bahwa itu berfungsi seperti yang diharapkan saat menjalankan versi minor yang lebih lama.
Adaptor ini sepenuhnya menyembunyikan fakta bahwa implementasi sebenarnya didukung oleh antarmuka 1.2 dan hanya menyediakan antarmuka 1.1 (adaptor mengambil antarmuka 1.2 dan membuatnya tampak seperti antarmuka 1.1).
Contoh alur kerja
Dalam contoh ini, perangkat Android menjalankan android.hardware.foo@1.1::IFoo/default . Untuk memastikan klien bekerja dengan baik dengan android.hardware.foo@1.0::IFoo/default :
- Di terminal, jalankan yang berikut:
$ PACKAGE=android.hidl.allocator@1.0-adapter $ INTERFACE=IAllocator $ INSTANCE=ashmem $ THREAD_COUNT=1 # can see current thread use on `lshal -i -e` $ m -j $PACKAGE $ /data/nativetest64/$PACKAGE/$PACKAGE $INTERFACE $INSTANCE $THREAD_COUNT Trying to adapt down android.hidl.allocator@1.0-adapter/default Press any key to disassociate adapter.
- Mulai ulang klien menggunakan
adb shell stop(ataustart) atau cukup matikan prosesnya. - Setelah pengujian selesai, lepaskan adaptor.
- Pulihkan status sistem dengan memulai ulang perangkat ATAU dengan memulai ulang klien.
Target tambahan
hidl-gen secara otomatis menambahkan target build tambahan untuk adaptor untuk setiap antarmuka yang ditentukan dengan hidl_interface dalam sistem build. Untuk paket abc@xy , ada target C++ tambahan abc@xy-adapter .
Adaptor untuk abc@xy mengambil beberapa implementasi sebagai masukan, abc@x.(y+n)::ISomething/instance-name , dan harus mendaftarkan abc@xy::ISomething/instance-name yang juga harus membatalkan pendaftaran y+n implementasi.
Diberikan contoh antarmuka berikut:
// IFoo.hal
package a.b.c@1.0;
interface IFoo {
doFoo(int32_t a) generates (int64_t b);
doSubInterface() generates (IFoo a);
}; Kode yang disediakan oleh abc@1.0-adapter mirip dengan contoh di bawah ini:
// autogenerated code
// in namespace a::b::c::V1_0::IFoo
struct MockFoo {
// takes some subclass of V1_0. May be V1_1, V1_2, etc...
MockFoo(V1_0::IFoo impl) mImpl(impl) {}
Return<int64_t> doFoo(int32_t a) {
return this->mImpl->doFoo(a);
}
Return<V1_0::ICallback> doSubInterface() {
// getMockForBinder returns MockCallback instance
// that corresponds to a particular binder object
// It can't return a new object every time or
// clients using interfacesSame will have
// divergent behavior when using the mock.
auto _hidl_out = this->mImpl->doSubInterface();
return getMockForBinder(_hidl_out);
}
};Nilai data diteruskan tepat ke dalam dan keluar dari kelas tiruan yang dibuat secara otomatis, kecuali untuk sub-antarmuka, yang dikembalikan. Antarmuka ini harus dibungkus dengan objek panggilan balik terbaru yang sesuai.