Hashing dell'interfaccia

Questo documento descrive l'hashing dell'interfaccia HIDL, un meccanismo per prevenire modifiche accidentali dell'interfaccia e garantire che le modifiche dell'interfaccia siano accuratamente controllate. Questo meccanismo è necessario perché le interfacce HIDL hanno una versione, il che significa che dopo il rilascio di un'interfaccia non deve essere modificata se non in modo da preservare l'Application Binary Interface (ABI) (ad esempio una correzione di commenti).

Disposizione

Ogni directory root del pacchetto (ad esempio la mappatura android.hardware su hardware/interfaces o la mappatura vendor.foo su vendor/foo/hardware/interfaces ) deve contenere un file current.txt che elenca tutti i file di interfaccia HIDL rilasciati.

# current.txt files support comments starting with a ‘#' character
# this file, for instance, would be vendor/foo/hardware/interfaces/current.txt

# Each line has a SHA-256 hash followed by the name of an interface.
# They have been shortened in this doc for brevity but they are
# 64 characters in length in an actual current.txt file.
d4ed2f0e...995f9ec4 vendor.awesome.foo@1.0::IFoo # comments can also go here

# types.hal files are also noted in current.txt files
c84da9f5...f8ea2648 vendor.awesome.foo@1.0::types

# Multiple hashes can be in the file for the same interface. This can be used
# to note how ABI sustaining changes were made to the interface.
# For instance, here is another hash for IFoo:

# Fixes type where "FooCallback" was misspelled in comment on "FooStruct"
822998d7...74d63b8c vendor.awesome.foo@1.0::IFoo

Nota: per tenere traccia di quali hash provengono da dove, Google separa i file HIDL current.txt in diverse sezioni: la prima sezione è rilasciata in Android O ; la sezione successiva verrà rilasciata in Android O MR1 . Ti consigliamo vivamente di utilizzare un layout simile nel tuo file current.txt .

Hashing con hidl-gen

Puoi aggiungere un hash a un file current.txt manualmente o utilizzando hidl-gen . Il seguente frammento di codice fornisce esempi di comandi che puoi utilizzare con hidl-gen per gestire un file current.txt (gli hash sono stati abbreviati):

hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::types
9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::INfc
07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0
9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types
07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc
f2fe5442...72655de6 vendor.awesome.nfc@1.0::INfcClientCallback
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0 >> vendor/awesome/hardware/interfaces/current.txt

Avviso: non sostituire un hash per un'interfaccia rilasciata in precedenza. Quando si modifica tale interfaccia, aggiungere un nuovo hash alla fine del file current.txt . Per i dettagli, fare riferimento alla stabilità ABI .

Ogni libreria di definizioni di interfaccia generata da hidl-gen include hash, che possono essere recuperati chiamando IBase::getHashChain . Quando hidl-gen compila un'interfaccia, controlla il file current.txt nella directory root del pacchetto HAL per vedere se l'HAL è stato modificato:

  • Se non viene trovato alcun hash per l'HAL, l'interfaccia viene considerata non rilasciata (in sviluppo) e si procede alla compilazione.
  • Se vengono trovati gli hash, vengono confrontati con l'interfaccia corrente:
    • Se l'interfaccia corrisponde all'hash, la compilazione procede.
    • Se l'interfaccia non corrisponde a un hash, la compilazione viene interrotta poiché ciò significa che viene modificata un'interfaccia rilasciata in precedenza.
      • Per una modifica che preservi l'ABI (vedi Stabilità ABI ), il file current.txt deve essere modificato prima che la compilazione possa procedere.
      • Tutte le altre modifiche dovrebbero essere apportate in un aggiornamento della versione minore o maggiore dell'interfaccia.

Stabilità dell'ABI

Un'Application Binary Interface (ABI) include i collegamenti binari/convenzioni di chiamata/ecc. Se l'ABI/API cambia, l'interfaccia non funziona più con un system.img generico compilato con interfacce ufficiali.

Assicurarsi che le interfacce abbiano una versione e che l'ABI sia stabile è fondamentale per diversi motivi:

  • Garantisce che la tua implementazione possa superare la Vendor Test Suite (VTS), che ti mette sulla buona strada per poter eseguire OTA solo framework.
  • In qualità di OEM, ti consente di fornire un Board Support Package (BSP) semplice da utilizzare e conforme.
  • Ti aiuta a tenere traccia di quali interfacce possono essere rilasciate. Considera current.txt una mappa di una directory di interfacce che ti consente di vedere la cronologia e lo stato di tutte le interfacce fornite nella radice del pacchetto.

Quando aggiungi un nuovo hash per un'interfaccia che ha già una voce in current.txt , assicurati di aggiungere solo gli hash che rappresentano le interfacce che mantengono la stabilità ABI. Esamina i seguenti tipi di modifiche:

Modifiche consentite
  • Modifica di un commento (a meno che ciò non modifichi il significato di un metodo).
  • Modifica del nome di un parametro.
  • Modifica del nome di un parametro di ritorno.
  • Modifica delle annotazioni.
Modifiche non consentite
  • Riordinare argomenti, metodi, ecc...
  • Rinominare un'interfaccia o spostarla in un nuovo pacchetto.
  • Rinominare un pacchetto.
  • Aggiunta di un metodo/campo struttura/ecc... ovunque nell'interfaccia.
  • Tutto ciò che potrebbe rompere una vtable C++.
  • eccetera..