Oberflächenmethoden und Fehler

In diesem Abschnitt werden Methoden und Fehler der Benutzeroberfläche beschrieben.

Ungültige Methoden

Methoden, die keine Ergebnisse zurückgeben, werden in Java-Methoden übersetzt, die void zurückgeben. Die HIDL-Deklaration beispielsweise:

doThisWith(float param);

... wird zu:

void doThisWith(float param);

Methoden für einzelne Ergebnisse

Methoden, die ein einzelnes Ergebnis zurückgeben, werden in ihre Java-Anwendungen übersetzt. und Äquivalente auch ein einzelnes Ergebnis zurückgeben. Hier ein Beispiel:

doQuiteABit(int32_t a, int64_t b,
            float c, double d) generates (double something);

... wird zu:

double doQuiteABit(int a, long b, float c, double d);

Methoden mit mehreren Ergebnissen

Für jede Methode, die mehr als ein Ergebnis zurückgibt, ist eine Callback-Klasse: das alle Ergebnisse in seiner onValues-Methode bereitstellt. Dieser Callback fungiert als zusätzlicher Parameter für die Methode. Beispiel: Der Parameter Folgendes:

oneProducesTwoThings(SomeEnum x) generates (double a, double b);

... wird zu:

public interface oneProducesTwoThingsCallback {
    public void onValues(double a, double b);
}
void oneProducesTwoThings(byte x, oneProducesTwoThingsCallback cb);

Ein Aufrufer von oneProducesTwoThings() würde normalerweise eine anonyme innere Klasse oder Lambda, um den Callback lokal zu implementieren:

someInstanceOfFoo.oneProducesTwoThings(
         5 /* x */,
         new IFoo.oneProducesTwoThingsCallback() {
          @Override
          void onValues(double a, double b) {
             // do something interesting with a and b.
             ...
          }});

oder:

someInstanceOfFoo.oneProducesTwoThings(5 /* x */,
    (a, b) -> a > 3.0 ? f(a, b) : g(a, b)));

Sie können auch eine Klasse definieren, die als Callback verwendet werden soll.

class MyCallback implements oneProducesTwoThingsCallback {
  public void onValues(double a, double b) {
    // do something interesting with a and b.
  }
}

...und übergeben eine Instanz von MyCallback als dritten Parameter an oneProducesTwoThings().

Transportfehler und Empfänger von Todesfällen

Da Dienstimplementierungen in einigen Fällen in einem anderen Prozess ausgeführt werden können, kann der Kunde am Leben bleiben, auch wenn der Prozess zur Implementierung einer Schnittstelle abbricht. Aufrufe an Interface-Objekten, die in einem inaktiven Prozess gehostet werden, schlagen mit einem Transport fehl error (eine Laufzeitausnahme, die von der aufgerufenen Methode ausgelöst wird). Genesung nach einer solchen Fehler durch Anfordern einer neuen Instanz des Dienstes durch Aufrufen von I<InterfaceName>.getService() Diese Methode funktioniert jedoch wenn der abgestürzte Prozess neu gestartet und seine Dienste neu registriert hat mit dem Servicemanager. Dies gilt im Allgemeinen für HAL-Implementierungen.

Clients einer Schnittstelle können auch Todesempfänger registrieren, um eine wenn ein Dienst ausfällt. Transportfehler können weiterhin auftreten, wenn ein Aufruf wenn der Server stirbt. Um sich für solche Benachrichtigungen auf einem abgerufenen IFoo-Schnittstelle kann ein Client Folgendes tun:

foo.linkToDeath(recipient, 1481 /* cookie */);

Der recipient-Parameter muss eine Implementierung der Schnittstelle HwBinder.DeathRecipient von HIDL bereitgestellt. Die Benutzeroberfläche enthält eine einzelne Methode serviceDied(), die aufgerufen wird, wenn der der Hosting-Prozess der Schnittstelle abbricht.

final class DeathRecipient implements HwBinder.DeathRecipient {
    @Override
    public void serviceDied(long cookie) {
        // Deal with service going away
    }
}

Der Parameter cookie enthält das Cookie, das mit übergeben wurde: den Aufruf von linkToDeath(). Es ist auch möglich, einen Todesfall von der Empfänger nach der Registrierung mit:

foo.unlinkToDeath(recipient);