Android 14 introduce la nuova funzionalità di accesso remoto, che consente ai partner di riattivare Android su un veicolo per eseguire attività specifiche. Ad esempio, per eseguire Modalità garage durante la notte per applicare il software aggiornamenti. Sono necessari più componenti non Android per l'architettura end-to-end nel tuo flusso di lavoro. Android non definisce né fornisce implementazione per dispositivi non Android (questa responsabilità è esclusiva dell'utente).
Per saperne di più, consulta le seguenti sezioni:
Flusso di lavoro. Flusso di lavoro tra più componenti nell'esempio per la registrazione client e l'erogazione delle attività.
Scrivi un client di attività remoto. Usare l'accesso remoto e imparerai a scrivere un client di attività remoto.
Implementazione da parte del fornitore. i componenti del fornitore di esempio per supportare l'accesso remoto.
Ripristino dei dati di fabbrica e trasferimento della proprietà. Scopri come gestire ripristinare i dati di fabbrica e trasferire la proprietà del veicolo.
Testa il client di accesso remoto. Scopri come testare l'accesso remoto funzionalità.
Architettura
Il contenuto seguente presuppone che venga utilizzata la seguente architettura di esempio, è ipotetica e potrebbe non riflettere l'architettura reale. Gli OEM devono adattarsi un'implementazione effettiva nelle architetture dei loro veicoli e server.
Figura 1. Architettura di esempio.
L'architettura di esempio è costituita dai seguenti componenti hardware:
| Componente hardware | Descrizione |
|---|---|
| Processore di app | Processore Android. Android potrebbe essere eseguito sulla memoria virtuale (VM) (non sull'hardware reale) di questo processore. |
| Processore per veicoli | Processore responsabile del controllo dell'alimentazione dell'app di fatturazione. |
| Unità di controllo telematica (TCU) | Il processore nel veicolo è sempre in grado di ricevere messaggi remoti nel cloud. Si presume che la TCU sia sempre accesa o a basso consumo. Utilizza le funzionalità di messaggi remoti per risvegliare la TCU. |
| Server di riattivazione | Un server remoto eseguito nel cloud che è responsabile che comunica con la TCU del veicolo per emettere comandi di riattivazione. |
| Server di attività remoto | Un server di attività remoto viene eseguito nel cloud e interagisce con persone e gestisce le attività da remoto. |
L'architettura di esempio è composta da questi componenti software, tutti che funzionano su Android:
| Componente software su Android | Descrizione |
|---|---|
| Servizio auto | Servizio framework AAOS che fornisce API di accesso remoto. |
| Client attività remota | Un modello scritto dal fornitore
Service
che esegue attività remote. Un sistema Android può eseguire
client di attività remote. |
| Accesso remoto all'HAL | Deve essere implementata per l'accesso remoto. Livello di astrazione per la comunicazione tra AAOS e un sistema non Android come la TCU. |
I componenti software non Android sono descritti di seguito:
| Componente software non Android | Descrizione |
|---|---|
| Client riattivazione | Software in esecuzione su una TCU che mantiene una connessione di lunga durata con server di wakeup. Mantiene inoltre una connessione con Remote Access HAL per consegnare attività da remoto al servizio auto. |
| Implementazione del server di riattivazione | Server che comunica con il client di wakeup in esecuzione su una TCU. Lattina di inviare richieste di wakeup al client di wakeup. |
| Implementazione di server di attività remoti | Server che gestisce le attività remote. Gli utenti interagiscono con questo server per risolvere i problemi e monitorare le attività da remoto. |
Flusso di lavoro
Questa sezione elenca i passaggi in 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 un garage.
Il partner cerca di aggiornare il veicolo durante la notte in caso di interazioni con quest'ultimo improbabile.
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 centralina elettronica (ECU) Android e un servizio OEM attiva la modalità Garage.
Android esegue la modalità Garage per scaricare e installare aggiornamenti tramite Google Play.
Dopo aver applicato l'aggiornamento, Android contrassegna l'attività come completata e termina la connessione o raggiunge un determinato timeout.
Flusso di lavoro dettagliato
Sono necessari due passaggi importanti per l'accesso remoto. Il primo è registrare il client, il che significa collegare un utente specifico a un di un'attività in esecuzione su un veicolo specifico. L'altra è consegnare un'attività, che è assegnare a un utente specifico l'attività remota in esecuzione sul veicolo specifico.
Registra un client
Per utilizzare la funzionalità di accesso remoto, un utente deve aprire il client delle attività da remoto almeno una volta e completa la procedura di registrazione del cliente (testo in grassetto) indica le attività implementate dall'AAOS):
All'avvio, Servizio auto riceve le informazioni sul veicolo dall'accesso remoto HAL.
All'avvio, Car Service avvia tutti i client delle attività remote in base filtro per intent e autorizzazione.
All'avvio del client dell'attività remota, quest'ultimo si registra con il servizio auto.
Servizio auto avvisa il client dell'attività remota della registrazione informazioni, tra cui l'ID veicolo e l'ID client. L'ID client è univoco e assegnato da Car Service a questo client. L'unicità è garantita tra tutti i clienti che svolgono attività da remoto sullo stesso veicolo.
L'utente accede al server delle attività remoto tramite il client delle attività remoto e attiva la funzionalità di accesso remoto per questo veicolo. In genere questo passaggio prevede l'autenticazione tramite server di attività remoto.
Il client dell'attività remota carica le informazioni dell'utente insieme all'ID veicolo e l'ID client al server delle attività remoto, chiedendogli di collegare l'utente a per il cliente e per il veicolo.
Facoltativamente, questo passaggio potrebbe comportare un'ulteriore autenticazione a due fattori da parte dell'utente.
Il server delle attività remoto deve verificare che l'ID veicolo fornito la richiesta corrisponde all'ID veicolo del mittente, che può essere fatto attestazione del veicolo.
A meno che non venga eseguito un ripristino dei dati di fabbrica, è richiesta la procedura di registrazione del cliente una volta per utente per veicolo. L'ID client viene memorizzato localmente nel Servizio auto e rimane lo stesso per lo stesso cliente.
Figura 2. Registrare 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 e risolvere il problema una richiesta di scollegamento per scollegare questo veicolo dall'utente collegato in precedenza .
Sul server di attività remoto, gli utenti possono accedere al proprio account e scollegarli un veicolo collegato in precedenza da questo account.
Se l'utente scollega il veicolo dal proprio account, il server delle attività remoto deve la mappatura archiviata per l'utente specifico.
Pubblicare le attività
Nel cloud:
Un utente utilizza il server delle attività remoto per inviare un'attività remota a una specifica veicolo.
Il server delle attività remoto mappa l'ID utente all'ID veicolo e all'ID client. it invia i dati dell'attività, l'ID veicolo e l'ID client al server di riattivazione.
Il server di wakeup trova la TCU specifica per l'ID veicolo (supponendo che il parametro La registrazione della TCU è già stata completata) e invia i dati dell'attività e l'ID client a alla TCU.
Sul veicolo (il testo in grassetto indica le attività eseguite dall'AAOS):
La TCU riceve attività remote dal server remoto.
Se il processore di app (AP) con AAOS è spento, la TCU utilizza processore del veicolo (VP) per riattivare l'AP.
Il servizio auto riceve attività da TCU.
Car Service distribuisce le attività al corrispondente client delle attività remote.
Il client dell'attività remota riceve ed esegue l'attività.
(Facoltativo) Il client delle attività remoto contatta il server delle attività per maggiori dettagli ed esegue l'attività.
(Facoltativo) Il servizio client delle attività remote segnala i risultati dell'attività al server delle attività.
Il client dell'attività remota avvisa il servizio auto quando l'attività è stata completata.
Se necessario, il servizio auto ripristina lo stato di alimentazione del veicolo.
Figura 3. Presentare le attività.
Scrivi un client di attività remoto
CarRemoteAccessManager fornisce l'API per le funzionalità di accesso remoto. Per ulteriori informazioni
vedi altro
CarRemoteAccessManager.
Un client di attività da remoto è un servizio Android che esegue attività da remoto e utilizza
CarRemoteAccessManager. Questa operazione richiede PERMISSION_USE_REMOTE_ACCESS e
PERMISSION_CONTROL_REMOTE_ACCESS e deve dichiarare un filtro per intent per
RemoteTaskClientService come:
<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à remota deve registrarsi al servizio 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;
}
Car Service gestisce il proprio ciclo di vita. Il servizio auto si collega a questo servizio durante all'avvio e all'arrivo di un'attività remota. Servizio auto si slega a questo servizio quando l'attività risulta completata. Per saperne di più, vedi Gestione del ciclo di vita di un servizio.
Il client dell'attività remota viene eseguito come utente del sistema, quindi non può accedere a dati specifici 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 da parte del fornitore
La funzionalità di accesso remoto è facoltativa e disattivata per impostazione predefinita. Per attivare il 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 per Android
Accesso remoto all'HAL
L'HAL (Remote Access Hardware Astrazione Layer) è un modello di astrazione per la comunicazione tra AAOS e un'altra ECU (ad esempio, TCU). È obbligatorio per supportare la funzionalità di accesso remoto. Non richiede se la funzionalità di accesso remoto non è implementata.
L'interfaccia è definita IRemoteAccess.aidl e include i seguenti metodi:
| Classe | Descrizione |
|---|---|
String getVehicleId() |
Riceve un ID veicolo univoco che può essere riconosciuto dalla funzionalità di sveglia server web. |
String getWakeupServiceName() |
Restituisce il nome del server di wakeup remoto. |
String getProcessorId() |
Ottiene un ID processore univoco che può essere riconosciuto riattivando il di alto profilo. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Imposta un callback da chiamare quando viene richiesta un'attività remota. |
|
void clearRemoteTaskCallback() |
Cancella il callback di un'attività remota impostato in precedenza. |
void notifyApStateChange(in ApState state)
Rileva se il processore dell'app è pronto a ricevere attività da remoto. | |
L'interfaccia di callback è definita
IRemoteTaskCallback.aid.
| Classe | Descrizione |
|---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Un callback che viene chiamato quando viene richiesta un'attività remota. |
|
Consulta le
implementazione del riferimento
con una TCU esterna. L'implementazione usa un live streaming di lettura molto lungo
ricevono attività remote e supporta il seguente comando debug:
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
HAL per veicoli
Per supportare la funzionalità di accesso remoto, VHAL deve supportare le seguenti proprietà:
| Classe | Descrizione |
|---|---|
SHUTDOWN_REQUEST |
Richiedono l'arresto dell'unità principale. |
VEHICLE_IN_USE |
|
Per saperne di più, vedi Proprietà di sistema supportate.
Modalità silenziosa
La modalità silenziosa deve essere supportata per la funzionalità di accesso remoto in modo che il veicolo possono avviarsi in modalità silenziosa per eseguire attività remote in assenza di utenti. Con modalità silenziosa, il dispositivo AAOS si avvia con display e 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
. Il segnale (0 o 1) viene scritto
/sys/kernel/silent_boot/pm_silentmode_hw_state. Successivamente, il framework AAOS viene aggiornato
/sys/kernel/silent_boot/pm_silentmode_kernel_state di conseguenza
rappresenta la modalità silenziosa attuale. Controlli dei moduli AAOS
/sys/kernel/silent_boot/pm_silentmode_kernel_state per sapere se il sistema
sia in modalità Silenzioso o meno.
Quando viene ricevuta un'attività remota e si avvia AAOS, il processore del veicolo si imposta modalità silenziosa e avvio di AAOS in modo che il sistema si avvii con display/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 di app con Android. Nell'architettura di esempio, TCU riattiva il processore dell'app inviando un segnale al veicolo di fatturazione.
Componenti non Android sul veicolo
La TCU del veicolo può sempre ricevere messaggi da remoto.
Il client di riattivazione viene eseguito sulla TCU per garantire una connessione di lunga durata server di wakeup remoto.
AAOS in esecuzione sull'AP può comunicare con il client di riattivazione in esecuzione TCU tramite l'HAL di accesso remoto.
Figura 4. TCU (client di riattivazione).
Componenti on-cloud
Server di riattivazione
Il server di wakeup comunica con il client di wakeup sulla TCU per:
- Mantenere un collegamento 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 oppure online al server delle attività remoto.
In un'implementazione effettiva, un server di wakeup può essere unito a un server delle attività.
Server di attività remoto
Il server delle attività remoto gestisce queste attività remote.
L'utente interagisce con il server per avviare nuove attività da remoto e monitorare per svolgere attività da remoto.
Utilizza il server di riattivazione remoto per riattivare il processore dell'app in dei veicoli.
Interagisce con il client dell'attività remota in esecuzione sul veicolo.
Memorizza le informazioni di registrazione del cliente. Questa operazione associa un utente specifico a uno specifico client di attività da remoto su un veicolo specifico.
In genere i dati delle attività che vengono inviati tramite il server delle attività remoto alla riattivazione server, alla TCU del veicolo e infine al client dell'attività remota è semplicemente un ID attività. Il client dell'attività remota utilizza l'ID attività per recuperare i dettagli le informazioni dal server di attività remoto.
Requisiti di privacy e sicurezza
| Attività | Condizione | Requisito |
|---|---|---|
| TCU (client di riattivazione) | DEVE |
|
| Server di riattivazione | DEVE |
|
| Client attività remota | DEVE |
|
| Server di attività remoto | DEVE |
|
Ripristino dei dati di fabbrica e trasferimento della proprietà
Se un utente esegue un ripristino dei dati di fabbrica, l'ID client memorizzato nel Servizio auto viene cancellato. Tuttavia, i server (server di attività remoto e server di wakeup remoto) vengono non informato. I server conservano una mappatura dall'ID client ora scaduto a del veicolo. Di conseguenza, se l'utente avvia una nuova attività remota per il veicolo, utilizza l'ID client scaduto. Il veicolo è riattivato, ma il compito da remoto 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. il server delle attività remoto e scollega il veicolo dal proprio account, se l'utente ha collegato in precedenza il veicolo. Non è garantito che il dispositivo abbia la rete all'accesso durante il ripristino dei dati di fabbrica. Di conseguenza, l'invio della richiesta di scollegamento al momento del ripristino dei dati di fabbrica dal dispositivo.
Ogni volta che la proprietà di un veicolo viene trasferita, è necessario eseguire alcune operazioni eseguite per garantire 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 verrà generato di nuovo. Dopo il giorno questo passaggio, il proprietario precedente può comunque riattivare il veicolo, ma non può eseguire attività da remoto.
Apri l'app client delle attività remote e segui le Procedura di annullamento della registrazione di un cliente per scollegare il veicolo dall'account del proprietario precedente. Il nuovo proprietario può seguire la registrazione per collegare il veicolo al proprio account e sostituire collegato in precedenza.
Il nuovo proprietario può utilizzare la procedura di registrazione di un cliente per collegare il veicolo al suo account e sostituire quello collegato in precedenza.
Testa il client dell'attività remota
Forniamo l'HAL per l'accesso remoto di riferimento
default
per testare i client delle attività remote. Puoi utilizzare le seguenti debug
per inserire una falsa attività remota nell'HAL, che viene inoltrata al tuo
client di attività remota, se fornisci l'ID client corretto. Puoi far arrivare il cliente
ID registrando le informazioni di registrazione nel client dell'attività remota
implementazione.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]