Sensori Multi-HAL

Sensors Multi-HAL è un framework che consente ai sensori HAL di funzionare insieme ad altri sensori HAL. Sensors Multi-HAL carica dinamicamente i sub-HAL dei sensori archiviati come librerie dinamiche nella partizione del fornitore e fornisce loro un oggetto di callback in grado di gestire la pubblicazione di eventi e l'acquisizione e il rilascio del wakelock. Un sub-HAL dei sensori è un HAL dei sensori integrato in un oggetto condiviso sulla partizione del fornitore e utilizzato dal framework multi-HAL. Questi sub-HAL non dipendono l'uno dall'altro o dal codice multi-HAL che contiene la funzione principale per il processo.

Sensori multi-HAL 2.1, disponibile su dispositivi con Android 11 o superiore, è un'iterazione di sensori multi-HAL 2.0 che supporta il caricamento sotto-HAL che possono esporre l' angolo di cerniera tipo di sensore. Per supportare questo tipo di sensore, sotto-HAL devono utilizzare le API sub-HAL definiti nella nell'intestazione 2.1 SubHal .

Differenza tra Sensori Multi-HAL 2 e Sensori HAL 2

Sensori Multi-HAL 2, disponibile su dispositivi con Android 10 o superiore, introduce diverse astrazioni in cima sensori HAL 2 per rendere più facile l'interazione con le API HAL. Sensori multi-HAL 2 introduce il HalProxy classe per gestire implementa l'interfaccia sensori HAL 2 e il V2_1/SubHal (o V2_0/SubHal ) interfaccia per consentire HalProxy di interagire con sub-HAL.

ISensorsSubHal interfaccia è diversa dalla 2.1/ISensors.hal (o 2.0/ISensors.hal ) Interfaccia nei seguenti modi:

  • Il metodo di inizializzazione passa un IHalProxyCallback classe anziché due FMQs e ISensorsCallback .
  • I sub-HAL devono implementare una funzione di debug per fornire informazioni di debug nelle segnalazioni di bug.
  • I sub-HAL devono implementare una funzione di nome in modo che il sub-HAL caricato possa essere distinto dagli altri sub-HAL.

La differenza principale tra Sensors Multi-HAL 2 e Sensors HAL 2 risiede nelle funzioni di inizializzazione. Invece di fornire FMQs, IHalProxyCallback interfaccia fornisce due metodi, un metodo ad eventi successivi sensore al quadro sensori e un metodo per creare blocchi veglia. Sotto il cofano, il Sensors Multi-HAL gestisce tutte le interazioni con gli FMQ per garantire la consegna tempestiva degli eventi dei sensori per tutti i sub-HAL. Si consiglia di sub-HAL usa il createScopedWakelock metodo per delegare l'onere di timeout serrature scia ai sensori multi-HAL e di centralizzare utilizzo serratura scia ad un blocco comune veglia per tutta sensori multi-HAL, che minimizza bloccaggio e sbloccaggio chiamate.

Sensori Multi-HAL 2 ha anche alcune funzioni di sicurezza integrate. Gestisce situazioni in cui il sensore FMQ è pieno o in cui il framework del sensore Android si riavvia e lo stato del sensore deve essere ripristinato. Inoltre, quando gli eventi sono imputati a HalProxy classe, ma il quadro sensore è in grado di accettare immediatamente le manifestazioni, i sensori multi-HAL può spostare gli eventi in un thread in background per consentire il lavoro di continuare in tutte le sotto-HAL durante l'attesa per gli eventi da postare.

Codice sorgente e implementazione di riferimento

Tutto il codice sensori multi-HAL è disponibile in hardware/interfaces/sensors/common/default/2.X/multihal/ . Ecco alcuni suggerimenti per alcune risorse.

  • HalProxy.h : Il HalProxy oggetto viene istanziata da sensori multi-HAL e maniglie il passaggio dei dati dal sotto-HAL al quadro sensore.
  • HalProxy.cpp : L'attuazione di HalProxy contiene tutta la logica necessaria per comunicazioni multiplex tra i sub-HAL e il quadro sensore.
  • SubHal.h : ISensorsSubHal interfaccia definisce l'interfaccia che sotto-HAL devono seguire per essere compatibili con HalProxy . I sub-HAL implementa il metodo di inizializzazione in modo che l' HalProxyCallback oggetto può essere utilizzato per postEvents e createScopedWakelock .

    Per Multi-HAL 2.0 implementazioni, utilizzare la versione 2.0 di SubHal.h .

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/ : Questi test unitari verifica la HalProxy attuazione.

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ : Questo esempio sub-HAL sensori usi attuazione falsi per generare dati falsi. Utile per testare l'interazione di più sub-HAL su un dispositivo.

Implementazione

Questa sezione descrive come implementare Sensors Multi-HAL nelle seguenti situazioni:

Implementazione di sensori Multi-HAL 2.1

Per implementare Sensors Multi-HAL 2.1 su un nuovo dispositivo, seguire questi passaggi:

  1. Implementare ISensorsSubHal interfaccia come descritto in SubHal.h .
  2. Implementare il sensorsHalGetSubHal_2_1 metodo SubHal.h .
  3. Aggiungi un cc_library_shared bersaglio per costruire la nuova implementato sub-HAL. Quando si aggiunge l'obiettivo:

    1. Assicurati che il target venga trasferito da qualche parte nella partizione del fornitore del dispositivo.
    2. Nel file di configurazione situato a /vendor/etc/sensors/hals.conf , aggiungere il percorso della libreria in una nuova riga. Se necessario, creare il hals.conf file.

    Per un esempio Android.bp voce per costruire una libreria di sub-HAL, vedi hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp .

  4. Rimuovere tutti i android.hardware.sensors voci dal manifest.xml file, che contiene l'elenco di HAL supportati sul dispositivo.

  5. Rimuovere tutti i android.hardware.sensors servizio e service.rc file dal device.mk di file e aggiungere android.hardware.sensors@2.1-service.multihal e android.hardware.sensors@2.1-service.multihal.rc a PRODUCT_PACKAGES .

Sul caricamento del sistema, HalProxy inizia, cerca la nuova implementato sub-HAL, e l'inizializza chiamando sensorsHalGetSubHal_2_1 .

Porting da sensori Multi-HAL 2.0 a Multi-HAL 2.1

Alla porta da Multi-HAL 2.0 Multi-HAL 2.1, implementare l' SubHal interfaccia e ricompilare il sub-HAL.

Queste sono le differenze tra i 2.0 e 2.1 SubHal interfacce:

  • IHalProxyCallback utilizza i tipi creati nella versione 2.1 del ISensors.hal specifcation.
  • initialize() funzione passa una nuova IHalProxyCallback anziché quella del 2,0 SubHal interfaccia
  • Sub-HAL devono implementare getSensorsList_2_1 e injectSensorData_2_1 invece di getSensorsList e injectSensorData come questi metodi utilizzano i nuovi tipi di aggiunte nella versione 2.1 del ISensors.hal specifiche.
  • Sub-HAL devono esporre sensorsHalGetSubHal_2_1 piuttosto che sensorsHalGetSubHal per il Multi-HAL di trattarli come versione 2.1 sub-HAL.

Porting da sensori HAL 2.0

Quando l'aggiornamento a Sensori Multi-HAL 2.0 da sensori HAL 2,0 , garantire l'attuazione HAL soddisfi i seguenti requisiti.

Inizializzazione dell'HAL

Sensori HAL 2.0 ha una funzione di inizializzazione che consente al servizio di sensori di superare FMQ e un callback dinamico del sensore. Nei sensori multi-HAL 2.0, initialize() funzione passa una singola callback che deve essere utilizzato per eventi postali sensori, ottenere serrature scia, e notifica di connessione del sensore dinamico e sconnessioni.

Pubblicazione degli eventi del sensore nell'implementazione Multi-HAL

Invece di inviare eventi sensore attraverso il FMQ, il sub-HAL deve scrivere eventi sensore al IHalProxyCallback quando gli eventi del sensore sono disponibili.

Eventi WAKE_UP

In Sensors HAL 2.0, l'HAL può gestire il wakelock per la sua implementazione. Nei sensori multi-HAL 2.0, i sub-HAL consentono l'implementazione multi-HAL per gestire serrature veglia e possono richiedere una serratura scia da acquisire invocando createScopedWakelock . Un bloccato blocco scia ambito deve essere acquisito e passato al postEvents quando si postano sveglia eventi alla realizzazione Multi-HAL.

Sensori dinamici

Sensori multi-HAL 2.0 richiede che onDynamicSensorsConnected e onDynamicSensorsDisconnected in IHalProxyCallback sono chiamati ogniqualvolta dinamico collegamenti dei sensori cambiamento. Questi callback sono disponibili come parte del IHalProxyCallback puntatore che viene fornito attraverso initialize() funzione.

Porting da sensori HAL 1.0

Quando l'aggiornamento a sensori multi-HAL 2,0 di sensori HAL 1.0 , assicura la realizzazione HAL soddisfi i seguenti requisiti.

Inizializzazione dell'HAL

initialize() funzione deve essere supportata per stabilire la richiamata tra il sub-HAL e l'implementazione multi-HAL.

Esposizione dei sensori disponibili

Nei sensori multi-HAL 2.0, il getSensorsList() funzione deve restituire lo stesso valore durante un singolo dispositivo di avvio, anche attraverso sensori Hal riavviato. Ciò consente al framework di tentare di ristabilire le connessioni del sensore se il server di sistema si riavvia. Il valore restituito da getSensorsList() può cambiare dopo il dispositivo esegue un riavvio.

Pubblicazione degli eventi del sensore nell'implementazione Multi-HAL

Nei sensori HAL 2.0, invece di attendere poll() da chiamare, il sub-HAL deve eventi sensore proattivamente scrittura per IHalProxyCallback quando sono disponibili eventi sensore.

Eventi WAKE_UP

In Sensors HAL 1.0, l'HAL può gestire il wakelock per la sua implementazione. Nei sensori multi-HAL 2.0, i sub-HAL permette l'implementazione multi-HAL per gestire serrature veglia e può richiedere una serratura scia da acquisire invocando createScopedWakelock . Un bloccato blocco scia ambito deve essere acquisito e passato al postEvents quando si postano sveglia eventi alla realizzazione Multi-HAL.

Sensori dinamici

Nei sensori HAL 1.0, sensori dinamici vengono restituiti attraverso il poll() funzione. Sensori multi-HAL 2.0 richiede che onDynamicSensorsConnected e onDynamicSensorsDisconnected in IHalProxyCallback sono chiamati ogniqualvolta dinamico collegamenti dei sensori cambiamento. Questi callback sono disponibili come parte del IHalProxyCallback puntatore che viene fornito attraverso initialize() funzione.

Porting da sensori Multi-HAL 1.0

Per port un'implementazione esistente da sensori multi-HAL 1.0 seguente procedura.

  1. Assicurarsi che la configurazione sensori HAL è situato in /vendor/etc/sensors/hals.conf. Questo potrebbe comportare lo spostamento del file che si trova a /system/etc/sensors/hals.conf .
  2. Rimuovere eventuali riferimenti a hardware/hardware.h e hardware/sensors.h in quanto questi non sono supportati per HAL 2.0.
  3. Port sotto-HAL come descritto nel porting da sensori Hal 1.0 .
  4. Set Sensori Multi-HAL 2.0 come l'HAL designato seguendo i passaggi 3 e 4 nella implementazione di sensori Mutli-HAL 2.0 sezione.

Convalida

Esecuzione di VTS

Quando hai uno o più sub-HAL integrato ai sensori multi-Hal 2.1, utilizzare il Venditore Test Suite (VTS) per garantire la vostra implementazioni sub-HAL soddisfano tutti i requisiti stabiliti dall'interfaccia sensori HAL.

Per eseguire solo i test VTS dei sensori quando VTS è configurato su una macchina host, eseguire i seguenti comandi:

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_0Target && \
  vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_1Target

Esecuzione di unit test

I test unitari HalProxy_test.cpp prova HalProxy utilizzando falsi sub-HAL cui si crea un'istanza nella prova di unità e non vengono caricate dinamicamente. Quando si crea un nuovo sub-HAL, questi test dovrebbero servire da guida su come aggiungere unit test che verificano che il nuovo sub-HAL sia implementato correttamente.

Per eseguire i test, eseguire i seguenti comandi:

cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest

Test con i falsi sub-HAL

I falsi sub-Hals sono implementazioni fittizie del ISensorsSubHal interfaccia. I sub-HAL espongono diversi elenchi di sensori. Quando i sensori sono attivati, essi periodicamente posta eventi sensore generati automaticamente a HalProxy basato su intervalli specificati in una data richiesta sensore.

I falsi sub-HAL possono essere utilizzati per testare come funziona il codice Multi-HAL completo con altri sub-HAL caricati nel sistema e per sottolineare vari aspetti del codice Sensors Multi-HAL.

Due finti sub-HAL sono disponibili presso hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ .

Per creare e inviare i falsi sub-HAL a un dispositivo, eseguire i seguenti passaggi:

  1. Esegui i seguenti comandi per creare e inviare i tre diversi sub-HAL falsi al dispositivo:

    $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
    mma
    adb push \
      $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so \
      /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
    adb push \
      $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so \
      /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
    adb push \
      $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so \
      /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
    
  2. Aggiornare il sensori HAL config al /vendor/etc/sensors/hals.conf con i percorsi per le finte sotto-HAL.

    /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
    /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
    /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
    
  3. Riavvia HalProxy e caricare i nuovi sub-HAL elencate nel config.

    adb shell stop
    adb shell start
    

Debug

Gli sviluppatori possono eseguire il debug del quadro utilizzando il lshal comando. Per richiedere l'output di debug di Sensors HAL, eseguire il seguente comando:

adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default

Informazioni sullo stato attuale di HalProxy ei sottogruppi HAL è quindi inviato al terminale. Di seguito viene mostrato un esempio di output di comando per le HalProxy oggetto e falsi sub-HAL.

Internal values:
  Threads are running: true
  Wakelock timeout start time: 200 ms ago
  Wakelock timeout reset time: 73208 ms ago
  Wakelock ref count: 0
  # of events on pending write queue: 0
  # of non-dynamic sensors across all subhals: 8
  # of dynamic sensors across all subhals: 0
SubHals (2):
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2

Se il numero specificato per il # of events on pending write queue è un gran numero (1000 o più), questo significa che ci sono molti eventi in attesa di essere scritto al quadro sensori. Ciò indica che il servizio del sensore è in stallo o si è arrestato in modo anomalo e non sta elaborando gli eventi del sensore o che un grande batch di eventi del sensore è stato recentemente pubblicato da un sub-HAL.

Se il conteggio di blocco scia ref è maggiore di 0 , ciò significa HalProxy ha acquisito una serratura scia. Questo dovrebbe essere solo maggiore di 0 se uno ScopedWakelock intenzionalmente in attesa o se gli eventi di attivazione sono stati inviati HalProxy e non sono stati elaborati dal quadro sensore.

Il descrittore di file passato al metodo di debug di HalProxy viene passato a ogni sub-HAL modo che gli sviluppatori devono implementare il metodo di debug come parte del ISensorsSubHal interfaccia.