Android 14 introduce la nuova funzionalità di accesso remoto, che consente ai partner di riattivare da remoto Android in un veicolo per eseguire attività specifiche. Ad esempio, per eseguire la modalità Garage durante la notte per applicare gli aggiornamenti software. Per il flusso di lavoro end-to-end sono necessari più componenti non Android. Android non definisce né fornisce l'implementazione per i componenti non Android (questa responsabilità è tua).
Per saperne di più, consulta le seguenti sezioni:
Flusso di lavoro. Flusso di lavoro tra più componenti nell'architettura di esempio per la registrazione dei clienti e l'invio delle attività.
Scrivi un client di attività remota. Utilizza l'accesso remoto e scopri come scrivere un client di attività remoto.
Implementazione del fornitore. Componenti del fornitore nell'architettura di esempio per supportare l'accesso remoto.
Ripristino dei dati di fabbrica e trasferimento della proprietà. Scopri come gestire il ripristino dei dati di fabbrica e il trasferimento della proprietà del veicolo.
Prova il client di accesso remoto. Scopri come testare la funzionalità di accesso remoto.
Architettura
I contenuti che seguono presuppongono l'utilizzo dell'architettura di esempio riportata di seguito, che è ipotetica e potrebbe non rispecchiare l'architettura effettiva. Gli OEM devono adattare un'implementazione effettiva alle architetture dei veicoli e dei server.
Figura 1. Architettura di esempio.
L'architettura di esempio è costituita dai seguenti componenti hardware:
| Componente hardware | Descrizione |
|---|---|
| App Processor | Processore Android. Android potrebbe essere eseguito su memoria virtuale (VM) (non sull'hardware effettivo) su questo processore. |
| Processore del veicolo | Il processore responsabile del controllo dell'alimentazione per il processore dell'app. |
| Unità di controllo telematica (TCU) | Un processore nel veicolo sempre in grado di ricevere messaggi remoti dal cloud. Si presume che il TCU sia sempre acceso o in modalità a basso consumo. Utilizza i messaggi da remoto per riattivare il TCU. |
| Server di risveglio | Un server remoto in esecuzione nel cloud che è responsabile della comunicazione con la TCU nel veicolo per emettere comandi di risveglio. |
| Server delle attività remote | Il server delle attività remote viene eseguito nel cloud, interagisce con le persone e gestisce le attività remote. |
L'architettura di esempio è costituita da questi componenti di software, tutti eseguiti su Android:
| Componente software su Android | Descrizione |
|---|---|
| Servizio auto | Servizio del framework AAOS che fornisce API di accesso remoto. |
| Client di attività remota | Una classe Service scritta dal fornitore che esegue attività remote. Un sistema Android può eseguire più
client di attività remote. |
| HAL di accesso remoto | Deve essere implementato per l'accesso remoto. Livello di astrazione per la comunicazione tra AAOS e un componente non Android come la TCU. |
Di seguito sono descritti i componenti del software non Android:
| Componente software non Android | Descrizione |
|---|---|
| Client riattivazione | Software in esecuzione su una TCU che mantiene una connessione di lunga durata con il server di wakeup. Mantiene inoltre una connessione con l'HAL di accesso remoto per consegnare le attività da remoto al servizio auto. |
| Implementazione del server di risveglio | Server che comunica con il client di wakeup in esecuzione su una TCU. Può inviare richieste di sveglia al client di sveglia. |
| Implementazione del server delle attività remote | Server che gestisce le attività remote. Gli utenti interagiscono con questo server per eseguire e monitorare attività remote. |
Flusso di lavoro
Questa sezione elenca i passaggi di un flusso di lavoro di esempio.
Flusso di lavoro di esempio
Un flusso di lavoro dettagliato può essere simile al seguente:
L'utente parcheggia il veicolo in garage.
Il partner cerca di aggiornare il veicolo durante la notte, quando le interazioni con il veicolo sono improbabili.
Il server cloud partner invia un'attività remota del sistema di aggiornamento al veicolo. Nello specifico, l'unità di controllo telematica (TCU).
La TCU del veicolo attiva la ECU (Electronic Control Unit) Android e un servizio OEM attiva la modalità Garage.
Android esegue la modalità Garage per scaricare e installare gli aggiornamenti tramite Google Play.
Dopo aver applicato l'aggiornamento, Android contrassegna l'attività come completata e termina la connessione o raggiunge un timeout specificato.
Flusso di lavoro dettagliato
Per l'accesso remoto sono necessari due passaggi importanti. Il primo è registrare il client, ovvero collegare un utente specifico a un client di attività remota specifico in esecuzione su un veicolo specifico. L'altra è consegnare un'attività, ovvero consegnare l'attività remota per un utente specifico al client di attività remota specifico in esecuzione sul veicolo specifico.
Registra un client
Per utilizzare la funzionalità di accesso remoto, un utente deve aprire l'app client delle attività da remoto almeno una volta e completare la procedura di registrazione del client (il testo in grassetto indica le attività implementate da AAOS):
Al riavvio, Car Service riceve le informazioni del veicolo dall'HAL di accesso remoto.
Al riavvio, Car Service avvia tutti i client di attività remote in base a intent-filter e autorizzazione.
All'avvio, il client di attività remoto si registra con il servizio auto.
Il servizio auto avvisa il client dell'attività da remoto delle informazioni di registrazione, inclusi l'ID veicolo e l'ID client. L'ID client è univoco e assegnato da Car Service a questo client. È garantito che sia unico tra tutti i client di attività remota sullo stesso veicolo.
L'utente accede al server delle attività remote tramite il client delle attività remote e attiva la funzionalità di accesso remoto per il veicolo. Questo passaggio solitamente richiede l'autenticazione tramite il server delle attività remoto.
Il client di attività remota carica le informazioni dell'utente, insieme all'ID veicolo e all'ID client, sul server di attività remota e chiede di collegare l'utente con questo client e questo veicolo specifici.
(Facoltativo) Questo passaggio potrebbe richiedere un'ulteriore autenticazione a due fattori da parte dell'utente.
Il server di attività remoto deve verificare che l'ID veicolo fornito nella richiesta corrisponda all'ID veicolo del mittente, il che può essere fatto tramite l'attestazione del veicolo.
A meno che non venga eseguito un ripristino dei dati di fabbrica, la procedura di registrazione del cliente è obbligatoria una volta per utente e per veicolo. L'ID cliente viene archiviato localmente nel servizio auto e rimane invariato per lo stesso cliente.
Figura 2. Registra un client.
Annullare la registrazione di un client
Un utente può scollegare il veicolo dal proprio account dal veicolo o dal server di attività remoto:
Sul veicolo, gli utenti possono aprire l'app client delle attività remote ed inviare una richiesta di scollegamento per scollegare questo veicolo dai suoi account utente collegati in precedenza.
Sul server di attività remoto, gli utenti possono accedere al proprio account e scollegare un veicolo collegato in precedenza da questo account.
Se l'utente scollega il veicolo dal proprio account, il server delle attività remote deve rimuovere la mappatura memorizzata per l'utente specifico.
Pubblicare le attività
Nel cloud:
Un utente utilizza il server delle attività remote per inviare un'attività remota a un veicolo specifico.
Il server di attività remoto mappa l'ID utente all'ID veicolo e all'ID client. Invia i dati della richiesta, l'ID veicolo e l'ID cliente al server di attivazione.
Il server di riattivazione trova il TCU specifico per l'ID veicolo (supponendo che la registrazione del TCU sia già stata eseguita) e invia i dati della richiesta e l'ID client al TCU.
Sul veicolo (il testo in grassetto indica le attività eseguite da AAOS):
Il TCU riceve le attività remote dal server remoto.
Se il processore dell'app (AP) che esegue AAOS è spento, il TCU utilizza il processore del veicolo (VP) per riattivare l'AP.
Il servizio auto riceve attività da TCU.
Il servizio auto distribuisce le attività al client di attività remoto corrispondente.
Il client dell'attività remota riceve ed esegue l'attività.
(Facoltativo) Il client di attività remoto contatta il server di attività per ulteriori dettagli sull'attività e la esegue.
(Facoltativo) Il servizio client delle attività remote segnala il risultato dell'attività al server delle attività.
Il client di attività remota invia una notifica a Car Service al termine dell'attività.
Se necessario, il servizio auto ripristina lo stato di alimentazione del veicolo.
Figura 3. Presentare le attività.
Scrivi un client di attività remota
CarRemoteAccessManager fornisce l'API per le funzionalità di accesso remoto. Per saperne di più, consulta CarRemoteAccessManager.
Un client di attività remota è un servizio Android che esegue attività remote e utilizzaCarRemoteAccessManager. Richiede PERMISSION_USE_REMOTE_ACCESS e
PERMISSION_CONTROL_REMOTE_ACCESS e devi dichiarare un filtro per intent per
RemoteTaskClientService, ad esempio:
<service android:name=".remoteaccess.RemoteTaskClientService"
android:directBootAware="true"
android:exported="true">
<intent-filter>
<action android:name="android.car.remoteaccess.RemoteTaskClientService" />
</intent-filter>
</service>
Un client di attività remoto deve registrarsi al servizio di auto durante la creazione:
public final class RemoteTaskClientService extends Service {
@Override
public void onCreate() {
// mCar = Car.createCar()...
mRemoteAccessManager = (CarRemoteAccessManager)
mcar.getCarManager(Car.CAR_REMOTE_ACCESS_SERVICE);
if (mRemoteAccessManager == null) {
// Remote access feature is not supported.
return;
}
mRemoteAccessManager.setRemoteTaskClient(executor, mRemoteTaskClient);
}
}
Deve sostituire la funzione onBind per restituire un valore nullo.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Il servizio di autolavaggio ne gestisce il ciclo di vita. Il servizio auto si associa a questo servizio durante l'avvio e quando arriva un'attività remota. Il servizio Car Service viene scollegato da questo servizio al termine dell'attività. Per scoprire di più, consulta la sezione Gestire il ciclo di vita di un servizio.
Il client di attività remoto viene eseguito come utente di sistema, pertanto non ha accesso a nessun dato specifico dell'utente.
L'esempio seguente mostra come gestire i callback registrati:
private final class RemoteTaskClient
implements CarRemoteAccessManager.RemoteTaskClientCallback {
@Override
public void onRegistrationUpdated(
RemoteTaskClientRegistrationInfo info) {
// Register to remote task server using info.
}
@Override
public void onRemoteTaskRequested(String taskId,
byte[] data, int remainingTimeSec) {
// Parses the data and execute the task.
// Report task result to remote task server.
mRemoteAccessManager.reportRemoteTaskDone(taskId);
}
@Override
public void onShutdownStarting(CompleteableRemoteTaskFuture future) {
// Stop the executing task.
// Clear the pending task queue.
future.complete();
}
}
Implementazione del fornitore
La funzionalità di accesso remoto è facoltativa e disattivata per impostazione predefinita. Per attivare la funzionalità, aggiungi un RRO come il seguente:
// res/xml/overlays.xml
<?xml version="1.0" encoding="utf-8"?>
<overlay>
<item target="array/config_allowed_optional_car_features" value="@array/config_allowed_optional_car_features" />
</overlay>
// res/values/config.xml
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<string-array translatable="false" name="config_allowed_optional_car_features">
<item>car_remote_access_service</item>
</string-array>
</resources>
// Android.bp
runtime_resource_overlay {
name: "RemoteAccessOverlay",
resource_dirs: ["res"],
manifest: "AndroidManifest.xml",
sdk_version: "current",
product_specific: true
}
In alternativa, utilizza il seguente comando adb su una build userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Requisiti su Android
HAL di accesso remoto
L'HAL (Remote Access Astrazione Layer) è un livello di astrazione implementato dal fornitore per la comunicazione tra AAOS e un'altra ECU (ad esempio, una TCU). È obbligatorio per supportare la funzionalità di accesso remoto. Non è necessario implementarlo se la funzionalità di accesso remoto non è implementata.
L'interfaccia è definita in IRemoteAccess.aidl e include i seguenti metodi:
| Classe | Descrizione |
|---|---|
String getVehicleId() |
Recupera un ID veicolo univoco che può essere riconosciuto dal server di risveglio. |
String getWakeupServiceName() |
Recupera il nome del server di riattivazione remoto. |
String getProcessorId() |
Recupera un ID processore univoco che può essere riconosciuto riattivando il cliente. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Imposta un callback da chiamare quando viene richiesta un'attività remota. |
|
void clearRemoteTaskCallback() |
Cancella un callback dell'attività remota impostato in precedenza. |
void notifyApStateChange(in ApState state)
Rileva se il processore dell'app è pronto a ricevere attività remote. | |
L'interfaccia di callback è definita alle ore
IRemoteTaskCallback.aid.
| Classe | Descrizione |
|---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Un callback che viene chiamato quando viene richiesta un'attività remota. |
|
Consulta l'implementazione di riferimento con un TCU esterno. L'implementazione utilizza uno stream di lettura long-live per ricevere attività remote e supporta il seguente comando debug:
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
Vehicle HAL
Per supportare la funzionalità di accesso remoto, VHAL deve supportare queste proprietà:
| Classe | Descrizione |
|---|---|
SHUTDOWN_REQUEST |
Richiede lo spegnimento dell'unità principale. |
VEHICLE_IN_USE |
|
Per saperne di più, consulta Proprietà di sistema supportate.
Modalità silenziosa
La modalità silenziosa deve essere supportata per la funzionalità di accesso remoto in modo che il veicolo possa avviarsi in modalità silenziosa per eseguire attività remote quando non è presente alcun utente. Con la modalità silenziosa, il dispositivo AAOS si avvia con il display e l'audio disattivati.
La modalità silenziosa è controllata tramite due file sysfs del kernel Linux.
| Classe | Descrizione |
|---|---|
/sys/kernel/silent_boot/pm_silentmode_kernel_state
Rappresenta la modalità silenziosa corrente. |
|
/sys/kernel/silent_boot/pm_silentmode_hw_state
Rappresenta il segnale hardware per impostare una nuova modalità silenziosa. |
|
Il processore del veicolo invia un segnale HW al SoC Android per attivare/disattivare la modalità silenziosa. L'indicatore (0 o 1) viene scritto in
/sys/kernel/silent_boot/pm_silentmode_hw_state. Poi, il framework AAOS aggiorna
/sys/kernel/silent_boot/pm_silentmode_kernel_state di conseguenza, rappresentando
la modalità silenziosa corrente. I moduli AAOS controllano
/sys/kernel/silent_boot/pm_silentmode_kernel_state per sapere se il sistema è in modalità silenziosa o meno.
Quando viene ricevuta un'attività remota e viene avviato AAOS, il processore del veicolo imposta la modalità silenziosa e avvia AAOS in modo che il sistema venga avviato con il display/l'audio disattivati.
Componenti non Android sul veicolo
Processore per veicoli
Il processore del veicolo è un processore del veicolo in grado di controllare l'alimentazione per il processore dell'app che esegue Android. Nell'architettura di esempio, il TCU attiva il processore dell'app inviando un segnale al processore del veicolo.
Componenti non Android a bordo del veicolo
La TCU del veicolo può sempre ricevere messaggi da remoto.
Il client di riattivazione viene eseguito sul TCU per garantire una connessione di lunga durata con il server di riattivazione remoto.
AAOS in esecuzione sull'AP può comunicare con il client di risveglio in esecuzione sulla TCU tramite l'HAL di accesso remoto.
Figura 4. TCU (client di risveglio).
Componenti sul cloud
Server di risveglio
Il server di attivazione comunica con il client di attivazione sul TCU per:
- Mantieni una connessione di lunga durata con la TCU del veicolo.
- Trova una TCU specifica in base a un ID veicolo.
- Segnalare lo stato di un veicolo. ad esempio online o offline, o l'ultima volta online al server di attività remoto.
In un'implementazione effettiva, un server di risveglio può essere unito a un server di attività remoto.
Server delle attività remote
Il server delle attività remote gestisce queste attività.
L'utente interagisce con il server per avviare nuove attività remote e monitorarle.
Utilizza il server di risveglio remoto per riattivare il processore dell'app nei veicoli.
Interagisce con il client di attività remoto in esecuzione sul veicolo.
Memorizza le informazioni di registrazione del cliente. In questo modo, un utente specifico viene associato a un client di attività remota specifico su un veicolo specifico.
In genere, i dati delle attività inviati tramite il server delle attività remoto al server di risveglio, alla TCU del veicolo e infine al client delle attività remoto sono semplicemente un ID attività. Il client delle attività remote utilizza l'ID attività per recuperare le informazioni dettagliate dal server delle attività remote.
Requisiti di privacy e sicurezza
| Attività | Condizione | Requisito |
|---|---|---|
| TCU (client di attivazione) | MUST |
|
| Server di risveglio | MUST |
|
| Client attività remota | MUST |
|
| Server delle attività remote | MUST |
|
Ripristino dei dati di fabbrica e trasferimento di proprietà
Se un utente esegue un ripristino dei dati di fabbrica, l'ID cliente memorizzato in Car Service viene cancellato. Tuttavia, i server (server delle attività remote e server di risveglio remoto) non vengono informati. I server conservano una mappatura dall'ID client ora scaduto al veicolo. Di conseguenza, se l'utente avvia una nuova attività remota per il veicolo, viene utilizzato l'ID cliente scaduto. Il veicolo è riattivato, ma l'attività remota non può essere eseguita poiché il client dell'attività remota ha un ID client diverso che non corrisponde.
Di seguito viene descritta una possibile implementazione per un ripristino dei dati di fabbrica.
Quando un utente esegue un ripristino dei dati di fabbrica, il fornitore gli chiede di accedere al server delle attività remoto e di scollegare il veicolo dal proprio account, se l'utente ha collegato in precedenza il veicolo. Non è garantito che il dispositivo abbia accesso alla rete durante il ripristino dei dati di fabbrica. Pertanto, potrebbe non essere possibile inviare la richiesta di scollegamento al momento del ripristino dei dati di fabbrica dal dispositivo.
Ogni volta che viene trasferita la proprietà di un veicolo, devono essere eseguite alcune operazioni per assicurarsi che il proprietario precedente non possa più inviare attività da remoto al veicolo. Ad esempio, al nuovo proprietario potrebbe essere chiesto di:
Esegui il ripristino dei dati di fabbrica In questo modo, l'ID client viene rigenerato. Dopo questo passaggio, il proprietario precedente può ancora riattivare il veicolo, ma non può più eseguire attività da remoto.
Apri l'app client delle attività remote e segui la procedura di annullamento della registrazione di un client per scollegare il veicolo dall'account del proprietario precedente. Il nuovo proprietario può seguire la procedura di registrazione di un cliente per collegare il veicolo al proprio account e sostituire l'account collegato in precedenza.
Il nuovo proprietario può utilizzare la procedura Registra un cliente per collegare il veicolo al proprio account e sostituire quello collegato in precedenza.
Testa il client dell'attività remota
Forniamo la directory HAL per l'accesso remoto di riferimento
default
per testare i client delle attività remote. Puoi utilizzare il seguente comando debug
per iniettare un'attività remota falsa nell'HAL, che viene inoltrata al tuo
cliente di attività remota se fornisci l'ID client corretto. Puoi ottenere l'ID cliente registrando i dati di registrazione nell'implementazione del client di attività remoto.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]