Integrità del sistema Android

Android 9 include android.hardware.health HAL 2.0, un upgrade della versione principale di health@1.0 HAL. Questo nuovo HAL presenta i seguenti vantaggi:

  • Separazione più chiara tra il framework e il codice del fornitore.
  • Ritira il daemon healthd non necessario.
  • Maggiore libertà di personalizzazione dei fornitori nei report sulle informazioni sanitarie.
  • Più informazioni sull'integrità del dispositivo oltre alla batteria.

Android 11 include android.hardware.health HAL 2.1, un upgrade della versione secondaria da health@2.0 HAL. Questo nuovo HAL presenta i seguenti vantaggi:

  • Più facile da implementare
  • Conformità migliore con le API HAL 2.0 esistenti
  • Migliore separazione degli acuti nel codice di ricarica in modalità off
  • Supporto migliore del framework per indicare l'integrità della batteria del dispositivo

Android 13 include android.hardware.health AIDL HAL, una conversione da health@2.1 HAL. Questo nuovo HAL presenta i seguenti vantaggi:

  • Rimuovi le API relative ai caricabatterie inutilizzate
  • Rimuovi StorageAttribute inutilizzati e campi correlati
  • Supporta la ricarica con la base.

Requisiti

Dispositivi con Android 9 e Android 10

I dispositivi lanciati con Android 9 devono fornire l'HAL 2.x (e non l'HAL 1.0) o l'HAL AIDL. I dispositivi che non vengono lanciati con Android 9, ma che prevedono di aggiornare l'immagine del fornitore alla versione 3 della matrice di compatibilità del framework di destinazione (rilasciata in Android 9), devono rimuovere le implementazioni HAL 1.0 esistenti e fornire l'HAL 2.x o l'HAL AIDL.

AOSP include più librerie di supporto progettate per aiutarti a implementare l'HAL 2.0 e la transizione dalla vecchia HAL 1.0.

Dispositivi con Android 11 e Android 12

I dispositivi lanciati con Android 11 devono fornire l'HAL 2.1 (e non devono fornire l'HAL 1.0 o 2.0) o l'HAL AIDL. I dispositivi non avviati con Android 11, ma che prevedono di aggiornare l'immagine del fornitore alla versione 5 della matrice di compatibilità del framework di destinazione (rilasciata in Android 11), devono rimuovere le implementazioni HAL 2.0 esistenti e fornire l'HAL 2.1 o l'HAL AIDL. Per i dispositivi che non vengono lanciati con Android 11 e che non prevedono di aggiornare l'immagine del fornitore, è consigliabile fornire anche l'HAL 2.1.

AOSP include diverse librerie helper progettate per aiutarti a implementare l'HAL 2.1 e la transizione dal precedente HAL 1.0.

Dispositivi con Android 13 o versioni successive

I dispositivi lanciati con Android 13 devono fornire l'HAL AIDL (e non devono fornire l'HAL HIDL). I dispositivi che non vengono lanciati con Android 13, ma che prevedono di aggiornare l'immagine del fornitore alla versione 7 della matrice di compatibilità del framework di destinazione (rilasciata in Android 13), devono rimuovere le implementazioni HAL HIDL esistenti e fornire l'HAL AIDL. Consigliamo anche di fornire AIDL HAL sui dispositivi che non vengono lanciati con Android 13 e non prevedono di aggiornare l'immagine del fornitore.

I dispositivi non devono fornire l'HAL HIDL 1.0.

AOSP include più librerie di supporto progettate per aiutarti a implementare l'HAL AIDL e la transizione dalle vecchie HAL HIDL.

Terminologia

  • health@1.0: abbreviazione di android.hardware.health@1.0. Si riferisce alla versione 1.0 dell'HAL HIDL per la salute rilasciata in Android 8.0.
  • health@2.0: abbreviazione di android.hardware.health@2.0. Si riferisce alla versione 2.0 di Health HIDL HAL rilasciata in Android 9.
  • health@2.1: abbreviazione di android.hardware.health@2.1. Si riferisce alla versione 2.1 di Health HIDL HAL rilasciata in Android 11.
  • HAL AIDL per la salute: abbreviazione di android.hardware.health.
    • La versione 1 viene rilasciata in Android 13.
  • charger: eseguibile in esecuzione in modalità di ricarica non attiva che mostra l'animazione di ricarica del telefono.
  • Recovery: eseguibile in esecuzione in modalità di ripristino che deve recuperare le informazioni sulla batteria.
  • healthd: daemon legacy in esecuzione su Android che recupera informazioni relative alla salute e le fornisce al framework.
  • storaged: demone in esecuzione in Android che recupera le informazioni sullo spazio di archiviazione e le fornisce al framework.

Salute in Android 8.x

In Android 8.x, il componente relativo alla salute funziona come descritto nel seguente diagramma:

Salute in Android 8.x

Figura 1. Salute in Android 8.x.

In questo diagramma:

  • Il framework utilizza una (1) chiamata binder e una (1) chiamata hwbinder per comunicare con l'hardware.
  • healthd si collega in modo statico a libhealthd_android, libbatterymonitor e libbatteryservice.
  • health@1.0-impl si collega in modo statico a libhealthd.BOARD.

Ogni scheda può personalizzare un libhealthd.BOARD diverso; viene stabilito in fase di compilazione quale caricabatterie, health@1.0-impl e link di recupero da usare.

Per le altre modalità:

Ricarica in modalità off e modalità di ripristino in Android 8.x

Figura 2. Salute in Android 8.x, ricarica in modalità off e modalità di ripristino.

  • Il caricabatterie si collega in modo statico a libhealthd.BOARD, libhealthd_charger e libbatterymonitor.
  • Il recupero si collega in modo statico a libhealthd.BOARD e libbatterymonitor.

Salute in Android 9

In Android 9, il componente relativo alla salute funziona come descritto nel seguente diagramma: Salute in Android 9

Figura 3. Salute in Android 9.

Il framework tenta di recuperare il servizio health@2.0 da hwservicemanager. In caso di errore, chiama health@1.0 (in Android 8.x). Il percorso del codice precedente viene mantenuto in modo che l'immagine di sistema Android 9 sia compatibile con l'immagine del fornitore Android 8.x. Il framework non recupera le informazioni da entrambi gli HAL perché sul dispositivo può esistere una sola versione del servizio (1.0 o 2.0).

Per altre modalità:

Ricarica e recupero in modalità off in Android 9

Figura 4. Integrità in Android 9, ricarica in modalità off e modalità di ripristino.

Salute in Android 11

In Android 11, il componente per la salute funziona come descritto nel seguente diagramma:

[system]
    | getService()
    V
[health@2.1-service]
        | getService(stub=true)
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

Se l'implementazione di Health 2.1 non esiste, il sistema torna al percorso del codice precedente come descritto nelle sezioni precedenti

Per altre modalità:

[       charger          ]
    | getService()      |  (legacy code path)
    V                   +-------------------------------------------------+
[health@2.1-service]                                                      |
        | getService(stub=true)                                           |
        V                                                                 |
[      health@2.0-impl-2.1-<device>.so      ]                             |
        |                                  | (device-dependent linkage)   |
        V                                  V                              |
+---------Helper libs for impl--------+   [libhealthd.device]             |
| [libhealthloop (uevent, wakealarm)] |                                   |
| [libhealth2impl (IHealth impl)    ] | <---------------------------------+
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

[recovery]
        | getService() w/o hwservicemanager
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

Consulta il seguente diagramma semplificato per le diverse modalità:

Infrastruttura HAL 2.1 per la salute

Figura 5. Infrastruttura HAL 2.1 per l'integrità.

Salute in Android 13

In Android 13 viene introdotto l'HAL AIDL per la salute. Il componente di salute funziona come descritto nel seguente diagramma:

Infrastruttura HAL AIDL per la salute

Figura 6. Infrastruttura HAL AIDL per la salute.

Interfaccia HIDL HAL 2.0

L'HAL health@2.0 fornisce al framework le stesse funzionalità del vecchio daemon healthd. Fornisce inoltre API simili a quelle fornite in precedenza da healthd come servizio di binder (ad es. IBatteryPropertiesRegistrar).

L'interfaccia principale, IHealth , fornisce le seguenti funzioni:

  • registerCallback, per sostituire IBatteryPropertiesRegistrar.registerListener
  • unregisterCallback, in sostituzione di IBatteryPropertiesRegistrar.unregisterListener
  • update, in sostituzione di IBatteryPropertiesRegistrar.scheduleUpdate
  • I valori IBatteryPropertiesRegistrar.getProperties sono sostituiti dai seguenti:
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

Inoltre, IHealth fornisce le seguenti nuove API per storaged per recuperare informazioni relative allo spazio di archiviazione specifiche del fornitore:

  • getStorageInfo
  • getDiskStats

Un nuovo struct, @2.0::HealthInfo, viene restituito tramite i callback e getHealthInfo. Questa struct contiene tutte le informazioni sullo stato del dispositivo disponibili tramite l'HAL health@2.0, tra cui:

  • Informazioni sulla ricarica (ca/USB/wireless, corrente, tensione, ecc.)
  • Informazioni sulla batteria (presenza, livello della batteria, corrente, tensione, carica, tecnologia e così via)
  • Informazioni sullo spazio di archiviazione (informazioni sul dispositivo di archiviazione, statistiche del disco)

Per informazioni sull'implementazione del servizio Health 2.0, consulta Implementazione dell'integrità 2.0.

Interfaccia HAL HIDL 2.1

L'HAL health@2.1 supporta la ricarica in modalità off e fornisce maggiori informazioni sulla batteria.

L'interfaccia principale, IHealth, offre le seguenti funzioni aggiuntive

  • getHealthConfig: per recuperare la configurazione di questo HAL
  • getHealthInfo_2_1: upgrade di una versione secondaria a getHealthInfo
  • shouldKeepScreenOn: per determinare se lo schermo deve rimanere acceso in modalità caricabatterie

Inoltre, l'implementazione di @2.1::IHealth è obbligatoria per supportare @2.1::IHealthInfoCallback per le sue funzioni registerCallback e unregisterCallback ereditate. La nuova interfaccia di callback restituisce al cliente informazioni sullo stato di salute utilizzando la funzione healthInfoChanged_2_1 anziché la funzione healthInfoChanged ereditata.

Un nuovo struct, @2.1::HealthInfo, viene restituito tramite i callback e getHealthInfo_2_1. Questo struct contiene ulteriori informazioni sullo stato del dispositivo disponibili tramite health@2.0 HAL, tra cui:

  • Livello di capacità della batteria
  • Tempo di ricarica della batteria fino al 100% (in secondi)
  • Capacità di progetto della batteria a ricarica completa (in μAh)

Consulta il seguente diagramma UML per le classi utili all'implementazione dell'HAL per la salute:

Diagramma UML HAL per l&#39;integrità 2.1

Figura 7. Diagramma UML di Health HAL 2.1.

Per informazioni sull'implementazione del servizio Health 2.1, consulta Implementazione dell'integrità 2.1.

Interfaccia HAL AIDL versione 1

Modifiche all'API

L'HAL AIDL versione 1 supporta API simili a quelle dell'HAL HIDL 2.1. Rispetto all'interfaccia HIDL 2.1, nell'API sono stati modificati i seguenti elementi:

  • Le API relative al caricabatterie introdotte in HIDL HAL 2.1 non vengono trasferite all'HAL AIDL. Poiché la funzionalità di ricarica in modalità off è presente solo nella partizione/vendor, le API nell'interfaccia del fornitore non sono necessarie. Per implementare correttamente la ricarica in modalità off, consulta la sezione caricabatterie di seguito.
  • Il tipo StorageAttribute e i campi correlati vengono rimossi perché non vengono utilizzati.
  • chargerDockOnline viene aggiunto a HealthInfo per supportare la ricarica con la base.

Implementazione

Vedi il seguente diagramma UML per le classi utili per l'implementazione dell'HAL dell'integrità:

Diagramma UML HAL AIDL per la salute

Figura 8. Diagramma UML di Health AIDL HAL.

Per informazioni sull'implementazione del servizio Health AIDL, consulta Implementazione di Health AIDL HAL.

Ripristino

Android 13 supporta il binder in recovery. L'installazione del servizio AIDL per la salute nel recupero consente di eseguirlo in modalità di recupero.

Per informazioni sull'installazione del servizio AIDL per la salute nel recupero, consulta quanto segue:

Caricabatterie

La funzionalità di ricarica in modalità off viene spostata da /system a /vendor. Per i dispositivi lanciati con Android 13, se supportano la ricarica in modalità off, il file binario del servizio HAL deve supportare la modalità caricabatterie. Per farlo, consulta la sezione sull'implementazione del caricabatterie.

Proprietà del sistema di ricarica

Le proprietà ro.charger.* non sono più leggibili dal file binario charger in /vendor. Se sul tuo dispositivo sono impostate una o più proprietà di sistema ro.charger.*, consulta le proprietà di sistema per il caricabatterie.