Android 9 include android.hardware.health
HAL 2.0, un aggiornamento della versione principale da health@1.0 HAL. Questo nuovo HAL presenta i seguenti vantaggi:
- Separazione più netta tra framework e codice del fornitore.
- Depreca il demone
healthd
non necessario. - Maggiori gradi di libertà per la personalizzazione del fornitore nei report delle informazioni sullo stato.
- Più informazioni sullo stato del dispositivo oltre alla semplice batteria.
Android 11 include android.hardware.health
HAL 2.1, un aggiornamento di versione minore da health@2.0 HAL. Questo nuovo HAL presenta i seguenti vantaggi:
- Più facile da implementare
- Migliore conformità con le API HAL 2.0 esistenti
- Migliore separazione degli alti nel codice di ricarica in modalità off
- Miglior supporto per il framework per indicare lo stato 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 al caricatore inutilizzate
- Rimuovere
StorageAttribute
inutilizzato e campi correlati - Supporta la ricarica del dock.
Requisiti
Dispositivi con Android 9 e Android 10
I dispositivi avviati con Android 9 devono fornire l'HAL 2.x (e non l'HAL 1.0) o l'HAL AIDL. I dispositivi che non si avviano con Android 9 ma intendono aggiornare l'immagine del fornitore a Target Framework Compatibility Matrix versione 3 (rilasciata in Android 9) devono rimuovere le implementazioni HAL 1.0 esistenti e fornire HAL 2.x o HAL AIDL.
AOSP include più librerie di supporto progettate per aiutarti a implementare l'HAL 2.0 e la transizione dal vecchio HAL 1.0.
Dispositivi con Android 11 e Android 12
I dispositivi avviati con Android 11 devono fornire l'HAL 2.1 (e non l'HAL 1.0 o 2.0) o l'HAL AIDL. I dispositivi che non si avviano con Android 11 ma intendono aggiornare l'immagine del fornitore alla matrice di compatibilità Target Framework versione 5 (rilasciata in Android 11) devono rimuovere le implementazioni HAL 2.0 esistenti e fornire HAL 2.1 o HAL AIDL. Si consiglia inoltre di fornire l'HAL 2.1 per i dispositivi che non si avviano con Android 11 e non prevedono di aggiornare l'immagine del fornitore.
AOSP include più librerie di supporto progettate per aiutarti a implementare l'HAL 2.1 e la transizione dal vecchio HAL 1.0.
Dispositivi con Android 13 e versioni successive
I dispositivi che si avviano con Android 13 devono fornire AIDL HAL (e non devono fornire HIDL HAL). I dispositivi che non si avviano con Android 13 ma intendono aggiornare l'immagine del fornitore alla matrice di compatibilità Target Framework versione 7 (rilasciata in Android 13) devono rimuovere le implementazioni HAL HIDL esistenti e fornire HAL AIDL. Si consiglia inoltre ai dispositivi che non si avviano con Android 13 e non prevedono di aggiornare l'immagine del fornitore di fornire AIDL HAL.
I dispositivi non devono fornire l'HAL HIDL 1.0.
AOSP include più librerie di supporto progettate per aiutarti a implementare AIDL HAL e la transizione dai vecchi HIDL HAL.
Terminologia
- health@1.0 : abbreviazione di
android.hardware.health@1.0
. Si riferisce alla salute HIDL HAL versione 1.0 rilasciata in Android 8.0. - health@2.0 : abbreviazione di
android.hardware.health@2.0
. Si riferisce alla salute HIDL HAL versione 2.0 rilasciata in Android 9. - health@2.1 : abbreviazione di
android.hardware.health@2.1
. Si riferisce alla salute HIDL HAL versione 2.1 rilasciata in Android 11. - salute AIDL HAL : abbreviazione di
android.hardware.health
.- La versione 1 viene rilasciata in Android 13.
- caricatore : eseguibile in esecuzione in modalità di ricarica off che mostra l'animazione di ricarica del telefono.
- recovery : eseguibile in esecuzione in modalità di ripristino che deve recuperare le informazioni sulla batteria.
- healthd : demone legacy in esecuzione in Android che recupera le informazioni relative alla salute e le fornisce al framework.
- storaged : demone in esecuzione in Android che recupera le informazioni di archiviazione e le fornisce al framework.
Salute in Android 8.x
In Android 8.x, il componente di salute funziona come dettagliato nel diagramma seguente:
Figura 1 . Salute in Android 8.x
In questo diagramma:
- Una (1) chiamata binder e una (1) chiamata hwbinder vengono utilizzate dal framework per comunicare con l'hardware.
-
healthd
collega staticamente alibhealthd_android
,libbatterymonitor
elibbatteryservice
. - health@1.0-impl si collega staticamente a
libhealthd. BOARD
.
Ogni scheda può personalizzare una libhealthd. BOARD
; viene determinato in fase di compilazione a quale collegamento caricatore, health@1.0-impl e ripristino.
Per altre modalità:
Figura 2. Stato in Android 8.x, modalità di ricarica e ripristino in modalità off
- caricatore si collega staticamente a
libhealthd. BOARD
,libhealthd_charger
elibbatterymonitor
. - recovery si collega staticamente a
libhealthd. BOARD
elibbatterymonitor
.
Salute in Android 9
In Android 9, il componente di salute funziona come dettagliato nel diagramma seguente:
Figura 3 . Salute in Android 9
Il framework tenta di recuperare il servizio health@2.0 da hwservicemanager
. Se fallisce, chiama health@1.0 (in Android 8.x). Il percorso del codice legacy viene mantenuto in modo che l'immagine del sistema Android 9 sia compatibile con l'immagine del fornitore Android 8.x. Il framework non recupera le informazioni da entrambi gli HAL perché nel dispositivo può esistere solo una versione del servizio (1.0 o 2.0).
Per altre modalità:
Figura 4. Stato in Android 9, modalità di ricarica e ripristino in modalità off
Salute in Android 11
In Android 11, il componente di salute funziona come dettagliato nel diagramma seguente:
[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 dell'integrità 2.1 non esiste, il sistema torna al percorso del codice legacy 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) ] |
+-------------------------------------+
Vedere il seguente diagramma semplificato per le diverse modalità:
Figura 5. Infrastruttura HAL 2.1 per la salute
Salute in Android 13
In Android 13 viene introdotta la salute AIDL HAL. Il componente salute funziona come dettagliato nel diagramma seguente:
Figura 6. Infrastruttura HAL AIDL sanitaria
HIDL HAL interfaccia 2.0
Health@2.0 HAL fornisce al framework le stesse funzionalità del vecchio demone healthd. Fornisce inoltre API simili a quelle precedentemente fornite da healthd come servizio raccoglitore (ad esempio IBatteryPropertiesRegistrar ).
L'interfaccia principale, IHealth , fornisce le seguenti funzioni:
-
registerCallback
, per sostituireIBatteryPropertiesRegistrar.registerListener
-
unregisterCallback
, per sostituireIBatteryPropertiesRegistrar.unregisterListener
-
update
, per sostituireIBatteryPropertiesRegistrar.scheduleUpdate
-
IBatteryPropertiesRegistrar.getProperties
sono sostituiti dai seguenti:-
getChargeCounter
-
getCurrentNow
-
getCurrentAverage
-
getCapacity
-
getEnergyCounter
-
getChargeStatus
-
getHealthInfo
-
Inoltre, IHealth
fornisce le seguenti nuove API per storaged
per recuperare le informazioni relative allo storage specifiche del fornitore:
-
getStorageInfo
-
getDiskStats
Una nuova struttura, @2.0::HealthInfo
, viene restituita tramite callback e getHealthInfo
. Questa struttura contiene tutte le informazioni sullo stato del dispositivo disponibili tramite health@2.0 HAL, tra cui:
- Informazioni sulla carica (AC/USB/wireless, corrente, tensione, ecc.)
- Informazioni sulla batteria (presenza, livello della batteria, corrente, voltaggio, carica, tecnologia, ecc.)
- Informazioni di archiviazione (informazioni sul dispositivo di archiviazione, statistiche del disco)
Per informazioni sull'implementazione del servizio di integrità 2.0, vedere Implementazione di integrità 2.0 .
HIDL HAL interfaccia 2.1
Health@2.1 HAL supporta la ricarica in modalità off e fornisce maggiori informazioni sulla batteria.
L'interfaccia principale, IHealth , fornisce le seguenti funzioni aggiuntive
-
getHealthConfig
: per recuperare la configurazione di questo HAL -
getHealthInfo_2_1
: aggiornamento di una versione minore agetHealthInfo
-
shouldKeepScreenOn
: per determinare se lo schermo deve essere mantenuto acceso in modalità caricatore
Inoltre, l'implementazione di @2.1::IHealth
è necessaria per supportare @2.1::IHealthInfoCallback
per le funzioni registerCallback
e unregisterCallback
ereditate. La nuova interfaccia di callback restituisce le informazioni sull'integrità dell'integrità al client utilizzando la relativa funzione healthInfoChanged_2_1
anziché la funzione healthInfoChanged
ereditata.
Una nuova struttura, @2.1::HealthInfo
, viene restituita tramite callback e getHealthInfo_2_1
. Questa struttura contiene ulteriori informazioni sullo stato del dispositivo disponibili tramite health@2.0 HAL, tra cui:
- Livello di capacità della batteria
- Tempo di carica della batteria al massimo ora (in secondi)
- Capacità di progettazione della carica completa della batteria (in μAh)
Vedere il seguente diagramma UML per le classi utili all'implementazione HAL dell'integrità:
Figura 7. Diagramma UML Health HAL 2.1
Per informazioni sull'implementazione del servizio Health 2.1, vedere Implementazione Health 2.1 .
Interfaccia AIDL HAL versione 1
Modifiche alle API
L'HAL AIDL versione 1 supporta API simili all'HAL HIDL 2.1. Rispetto all'interfaccia HIDL 2.1, nell'API vengono modificati:
- Le API relative al caricatore introdotte in HIDL HAL 2.1 non vengono trasferite su AIDL HAL. Poiché la funzionalità dell'addebito 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, vedere il caricabatterie di seguito. - Digitare
StorageAttribute
e i campi correlati vengono rimossi perché inutilizzati. -
chargerDockOnline
viene aggiunto aHealthInfo
per supportare la ricarica del dock.
Implementazione
Vedere il seguente diagramma UML per le classi utili all'implementazione HAL dell'integrità:
Figura 8. Diagramma UML di salute AIDL HAL
Per informazioni sull'implementazione del servizio AIDL per l'integrità, vedere Implementazione dell'HAL AIDL per l'integrità .
Recupero
Android 13 supporta il raccoglitore in recovery. L'installazione del servizio Health AIDL per il ripristino consente l'esecuzione in modalità di ripristino.
Per informazioni sull'installazione del servizio AIDL dell'integrità per il ripristino, vedere quanto segue:
Caricabatterie
La funzionalità di addebito in modalità off viene spostata da /system
a /vendor
. Per i dispositivi avviati con Android 13, se supportano la ricarica in modalità off, il binario del servizio HAL deve supportare la modalità caricatore. Per fare ciò, fare riferimento all'implementazione del caricatore .
Proprietà del sistema di ricarica
Le proprietà ro.charger.*
non sono più leggibili dal binario del charger
in /vendor
. Se il dispositivo ha una delle proprietà di sistema ro.charger.*
impostate, fare riferimento alle proprietà di sistema per il caricatore .