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 su cui è in esecuzione 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 che viene eseguito nel cloud ed è responsabile della comunicazione con la TCU nel veicolo per emettere comandi di risveglio. |
| Server delle attività remote | Il server di attività remoto 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 il TCU. |
Di seguito sono descritti i componenti del software non Android:
| Componente software non Android | Descrizione |
|---|---|
| Client di risveglio | Software in esecuzione sul TCU che mantiene una connessione a lungo termine con il server di attivazione. Mantiene inoltre una connessione con l'HAL di accesso remoto per inviare attività remote al servizio auto. |
| Implementazione del server di risveglio | Server che comunica con il client di risveglio in esecuzione sulla TCU. Può inviare richieste di sveglia al client di sveglia. |
| Implementazione del server di attività remota | 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 del partner invia al veicolo un'attività di aggiornamento del sistema remoto. Nello specifico, l'unità di controllo telematico (TCU).
La TCU del veicolo riattiva l'unità di controllo elettronico (ECU) 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 task remoto 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 al servizio auto.
Il servizio auto invia una notifica al client dell'attività remota sulle informazioni di registrazione, inclusi l'ID veicolo e l'ID client. L'ID cliente è univoco e assegnato da Car Service a questo cliente. È 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 a questo client e a questo veicolo specifici.
(Facoltativo) Questo passaggio potrebbe richiedere un'ulteriore autenticazione a due fattori da parte dell'utente.
Il server delle attività remote deve autenticare 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 di attività remota e inviare una richiesta di scollegamento per scollegare il veicolo dagli account utente collegati in precedenza.
Sul server di attività remoto, gli utenti possono accedere al proprio account e scollegare un veicolo precedentemente collegato 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 risveglio.
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 le attività dal 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 delle attività da remoto contatta il server delle 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 Car Service ripristina lo stato di alimentazione del veicolo.
Figura 3. Completare le attività.
Scrivi un client di attività remoto
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. Questo richiede PERMISSION_USE_REMOTE_ACCESS e
PERMISSION_CONTROL_REMOTE_ACCESS e deve dichiarare un filtro 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 Car 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 null.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Il servizio di autolavaggio ne gestisce il ciclo di vita. Il servizio Car Service si lega a questo servizio durante l'avvio e quando arriva un'attività remota. Il servizio di assistenza stradale 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 (Hardware Abstraction Layer) per l'accesso remoto è 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 client. |
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 in IRemoteTaskCallback.aid.
| Classe | Descrizione |
|---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Un callback che viene chiamato quando viene richiesta un'attività remota. |
|
Consulta la
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 di 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 l'indicatore 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 a bordo del veicolo
Processore del veicolo
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 riattiva 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 ultima volta online sul server delle 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 relativi alla privacy e alla sicurezza
| Attività | Condizione | Requisito |
|---|---|---|
| TCU (client di attivazione) | MUST |
|
| Server di risveglio | MUST |
|
| Client di 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 mantengono 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 viene riattivato, ma l'attività remota non può essere eseguita perché 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à remote e di scollegare il veicolo dal suo account, se lo ha precedentemente collegato. Non è garantito che il dispositivo abbia accesso alla rete durante il ripristino dei dati di fabbrica. Pertanto, l'invio della richiesta di scollegamento al momento del ripristino dei dati di fabbrica dal dispositivo potrebbe non essere fattibile.
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 di attività remota 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 l'account collegato in precedenza.
Testa il client di attività remota
Forniamo la directory HAL di accesso remoto di riferimento
default
per testare i client di attività da remoto. 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 delle attività remote.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]