Setiap antarmuka yang didefinisikan dalam paket HIDL memiliki kelas C++ otomatisnya sendiri di dalam namespace paketnya. Klien dan server menangani antarmuka dengan cara yang berbeda:
- Server mengimplementasikan antarmuka.
- Klien memanggil metode pada antarmuka.
Antarmuka dapat didaftarkan berdasarkan nama oleh server atau diteruskan sebagai parameter ke metode yang ditentukan HIDL. Misalnya, kode kerangka kerja dapat melayani antarmuka untuk menerima pesan asinkron dari HAL dan meneruskan antarmuka itu langsung ke HAL tanpa mendaftarkannya.
Implementasi server
Server yang mengimplementasikan antarmuka IFoo harus menyertakan file header IFoo yang dibuat secara otomatis:
#include <android/hardware/samples/1.0/IFoo.h>
Header secara otomatis diekspor oleh pustaka bersama antarmuka IFoo untuk ditautkan. Contoh IFoo.hal :
// IFoo.hal
interface IFoo {
someMethod() generates (vec<uint32_t>);
...
}
Contoh kerangka untuk implementasi server dari antarmuka IFoo:
// From the IFoo.h header
using android::hardware::samples::V1_0::IFoo;
class FooImpl : public IFoo {
Return<void> someMethod(foo my_foo, someMethod_cb _cb) {
vec<uint32_t> return_data;
// Compute return_data
_cb(return_data);
return Void();
}
...
};
Untuk membuat implementasi antarmuka server tersedia untuk klien, Anda dapat:
- Daftarkan implementasi antarmuka dengan
hwservicemanager(lihat detail di bawah),
ATAU - Lewati implementasi antarmuka sebagai argumen metode antarmuka (untuk detail, lihat Asynchronous callback ).
Saat mendaftarkan implementasi antarmuka, proses hwservicemanager melacak antarmuka HIDL terdaftar yang berjalan pada perangkat berdasarkan nama dan versi. Server dapat mendaftarkan implementasi antarmuka HIDL berdasarkan nama dan klien dapat meminta implementasi layanan berdasarkan nama dan versi. Proses ini melayani antarmuka HIDL android.hidl.manager@1.0::IServiceManager .
Setiap file header antarmuka HIDL yang dibuat secara otomatis (seperti IFoo.h ) memiliki metode registerAsService() yang dapat digunakan untuk mendaftarkan implementasi antarmuka dengan hwservicemanager . Satu-satunya argumen yang diperlukan adalah nama implementasi antarmuka karena klien akan menggunakan nama ini untuk mengambil antarmuka dari hwservicemanager nanti:
::android::sp<IFoo> myFoo = new FooImpl();
::android::sp<IFoo> mySecondFoo = new FooAnotherImpl();
status_t status = myFoo->registerAsService();
status_t anotherStatus = mySecondFoo->registerAsService("another_foo");
hwservicemanager memperlakukan kombinasi [package@version::interface, instance_name] sebagai unik untuk mengaktifkan antarmuka yang berbeda (atau versi berbeda dari antarmuka yang sama) untuk mendaftar dengan nama instance yang identik tanpa konflik. Jika Anda memanggil registerAsService() dengan versi paket, antarmuka, dan nama instance yang sama persis, hwservicemanager menjatuhkan referensinya ke layanan terdaftar sebelumnya dan menggunakan yang baru.
Implementasi klien
Seperti halnya server, klien harus #include setiap antarmuka yang dirujuknya:
#include <android/hardware/samples/1.0/IFoo.h>
Klien dapat memperoleh antarmuka dengan dua cara:
- Melalui
I<InterfaceName>::getService(melaluihwservicemanager) - Melalui metode antarmuka
Setiap file header antarmuka yang dibuat secara otomatis memiliki metode getService statis yang dapat digunakan untuk mengambil instance layanan dari hwservicemanager :
// getService will return nullptr if the service can't be found
sp<IFoo> myFoo = IFoo::getService();
sp<IFoo> myAlternateFoo = IFoo::getService("another_foo");
Sekarang klien memiliki antarmuka IFoo , dan dapat memanggil metode seolah-olah itu adalah implementasi kelas lokal. Pada kenyataannya implementasi dapat berjalan pada proses yang sama, proses yang berbeda, atau bahkan pada perangkat lain (dengan HAL remoting). Karena klien memanggil getService pada objek IFoo yang disertakan dari versi 1.0 paket, hwservicemanager mengembalikan implementasi server hanya jika implementasi tersebut kompatibel dengan 1.0 klien. Dalam praktiknya, ini berarti hanya implementasi server dengan versi 1.n (versi x.(y+1) dari antarmuka yang harus diperluas (diwarisi dari) xy ).
Selain itu, metode castFrom disediakan untuk melakukan cast di antara antarmuka yang berbeda. Metode ini bekerja dengan membuat panggilan IPC ke antarmuka jarak jauh untuk memastikan tipe dasarnya sama dengan tipe yang diminta. Jika jenis yang diminta tidak tersedia, maka nullptr dikembalikan.
sp<V1_0::IFoo> foo1_0 = V1_0::IFoo::getService(); sp<V1_1::IFoo> foo1_1 = V1_1::IFoo::castFrom(foo1_0);
Panggilan balik asinkron
Banyak implementasi HAL yang ada berbicara dengan perangkat keras asinkron, yang berarti mereka memerlukan cara asinkron untuk memberi tahu klien tentang peristiwa baru yang telah terjadi. Antarmuka HIDL dapat digunakan sebagai panggilan balik asinkron karena fungsi antarmuka HIDL dapat mengambil objek antarmuka HIDL sebagai parameter.
Contoh file antarmuka IFooCallback.hal :
package android.hardware.samples@1.0;
interface IFooCallback {
sendEvent(uint32_t event_id);
sendData(vec<uint8_t> data);
}
Contoh metode baru di IFoo yang menggunakan parameter IFooCallback :
package android.hardware.samples@1.0;
interface IFoo {
struct Foo {
int64_t someValue;
handle myHandle;
};
someMethod(Foo foo) generates (int32_t ret);
anotherMethod() generates (vec<uint32_t>);
registerCallback(IFooCallback callback);
};
Klien yang menggunakan antarmuka IFoo adalah server antarmuka IFooCallback ; ini menyediakan implementasi IFooCallback :
class FooCallback : public IFooCallback {
Return<void> sendEvent(uint32_t event_id) {
// process the event from the HAL
}
Return<void> sendData(const hidl_vec<uint8_t>& data) {
// process data from the HAL
}
};
Itu juga dapat dengan mudah meneruskannya ke instance antarmuka IFoo yang ada:
sp<IFooCallback> myFooCallback = new FooCallback(); myFoo.registerCallback(myFooCallback);
Server yang mengimplementasikan IFoo menerima ini sebagai objek sp<IFooCallback> . Itu dapat menyimpan panggilan balik, dan memanggil kembali ke klien kapan pun ia ingin menggunakan antarmuka ini.
Penerima kematian
Karena implementasi layanan dapat berjalan dalam proses yang berbeda, dapat terjadi bahwa proses yang mengimplementasikan antarmuka mati sementara klien tetap hidup. Setiap panggilan pada objek antarmuka yang dihosting dalam proses yang telah mati akan gagal dengan kesalahan transportasi ( isOK() akan mengembalikan false). Satu-satunya cara untuk memulihkan dari kegagalan tersebut adalah dengan meminta instance baru dari layanan dengan memanggil I<InterfaceName>::getService() . Ini hanya berfungsi jika proses yang mogok telah dimulai ulang dan mendaftarkan ulang layanannya dengan servicemanager (yang umumnya berlaku untuk implementasi HAL).
Alih-alih menangani ini secara reaktif, klien antarmuka juga dapat mendaftarkan penerima kematian untuk mendapatkan pemberitahuan saat layanan mati. Untuk mendaftar pemberitahuan tersebut pada antarmuka IFoo yang diambil, klien dapat melakukan hal berikut:
foo->linkToDeath(recipient, 1481 /* cookie */);
Parameter recipient harus merupakan implementasi dari antarmuka android::hardware::hidl_death_recipient yang disediakan oleh HIDL, yang berisi satu metode serviceDied() yang akan dipanggil dari utas di threadpool RPC saat proses yang menghosting antarmuka mati:
class MyDeathRecipient : public android::hardware::hidl_death_recipient {
virtual void serviceDied(uint64_t cookie, const android::wp<::android::hidl::base::V1_0::IBase>& who) {
// Deal with the fact that the service died
}
}
Parameter cookie berisi cookie yang diteruskan dengan linkToDeath() , sedangkan parameter who berisi pointer lemah ke objek yang mewakili layanan di klien. Dengan contoh panggilan yang diberikan di atas, cookie sama dengan 1481, dan who sama dengan foo .
Anda juga dapat membatalkan pendaftaran penerima kematian setelah mendaftarkannya:
foo->unlinkToDeath(recipient);