В Android 14 представлена новая функция удалённого доступа, которая позволяет партнёрам удалённо активировать Android в автомобиле для выполнения определённых задач. Например, для перехода в режим «Гараж» на ночь с целью установки обновлений ПО. Для сквозного рабочего процесса требуется несколько компонентов, не относящихся к Android. Android не определяет и не предоставляет реализацию для компонентов, не относящихся к Android (эта ответственность лежит на вас).
Более подробную информацию смотрите в следующих разделах:
Рабочий процесс . Рабочий процесс между несколькими компонентами в примере архитектуры для регистрации клиентов и выполнения задач.
Напишите клиент для удалённых задач . Используйте удалённый доступ и узнайте, как написать клиент для удалённых задач.
Реализация поставщика . Компоненты поставщика в примере архитектуры для поддержки удаленного доступа.
Сброс настроек до заводских и передача права собственности . Узнайте, как выполнить сброс настроек до заводских и передачу права собственности на автомобиль.
Протестируйте клиент удалённого доступа . Узнайте, как протестировать функцию удалённого доступа.
Архитектура
В следующем тексте предполагается использование следующей архитектуры, которая является гипотетической и может не отражать реальную архитектуру. OEM-производителям следует адаптировать фактическую реализацию к архитектурам своих транспортных средств и серверов.
Рисунок 1. Пример архитектуры.
Пример архитектуры состоит из следующих аппаратных компонентов:
| Аппаратный компонент | Описание |
|---|---|
| Процессор приложений | Процессор, работающий под управлением Android. На этом процессоре Android может работать в виртуальной памяти (ВМ) (а не на реальном оборудовании). |
| Автомобильный процессор | Процессор, отвечающий за управление питанием процессора приложения. |
| Блок управления телематикой (TCU) | Процессор в автомобиле всегда способен получать удалённые сообщения из облака. Предполагается, что TCU всегда включён или находится в режиме пониженного энергопотребления. Используйте удалённые сообщения для пробуждения TCU. |
| Сервер пробуждения | Удаленный сервер, работающий в облаке и отвечающий за связь с TCU в транспортном средстве для выдачи команд пробуждения. |
| Сервер удаленных задач | Сервер удаленных задач работает в облаке, взаимодействует с людьми и управляет удаленными задачами. |
Пример архитектуры состоит из следующих программных компонентов, все из которых работают на Android:
| Компонент программного обеспечения для Android | Описание |
|---|---|
| Автосервис | Служба фреймворка AAOS, предоставляющая API удаленного доступа. |
| Клиент удаленных задач | Класс Service , написанный поставщиком, который выполняет удалённые задачи. Одна система Android может выполнять несколько клиентов удалённых задач. |
| Удаленный доступ HAL | Необходимо реализовать удаленный доступ. Уровень абстракции для связи между AAOS и компонентом, не относящимся к Android, таким как TCU. |
Ниже описаны компоненты программного обеспечения, не относящиеся к Android :
| Компонент программного обеспечения, не относящийся к Android | Описание |
|---|---|
| Клиент пробуждения | Программное обеспечение, работающее на TCU, поддерживает долговременное соединение с сервером пробуждения. Оно также поддерживает соединение с HAL удалённого доступа для удалённого выполнения задач в автосервисе. |
| Реализация сервера пробуждения | Сервер, взаимодействующий с клиентом пробуждения, работающим на TCU. Может отправлять запросы на пробуждение клиенту пробуждения. |
| Реализация сервера удаленных задач | Сервер управления удалёнными задачами. Пользователи взаимодействуют с этим сервером для запуска и мониторинга удалённых задач. |
Рабочий процесс
В этом разделе перечислены шаги примера рабочего процесса.
Пример рабочего процесса
Подробный рабочий процесс может выглядеть следующим образом:
Пользователь паркует транспортное средство в гараже.
Партнер стремится обновлять транспортное средство в ночное время, когда взаимодействие транспортных средств маловероятно.
Облачный сервер партнёра отправляет на автомобиль задачу удалённого обновления системы, а именно, телематического блока управления (TCU).
Блок управления транспортным средством активирует электронный блок управления Android (ЭБУ), а сервис OEM активирует гаражный режим.
Android использует режим Garage для загрузки и установки обновлений через Google Play.
После применения обновления Android отмечает задачу как выполненную и либо завершает соединение, либо достигает заданного тайм-аута.
Подробный рабочий процесс
Для удалённого доступа необходимо выполнить два важных шага. Первый — регистрация клиента, то есть привязка конкретного пользователя к конкретному клиенту удалённой задачи, работающему на конкретном транспортном средстве. Второй — доставка задачи, то есть доставка удалённой задачи для конкретного пользователя конкретному клиенту удалённой задачи, работающему на конкретном транспортном средстве.
Зарегистрировать клиента
Чтобы использовать функцию удаленного доступа, пользователь должен хотя бы один раз открыть клиентское приложение удаленных задач и завершить процесс регистрации клиента ( жирным текстом выделены задачи, реализованные AAOS):
При загрузке Car Service получает информацию об автомобиле из HAL удаленного доступа.
При загрузке Car Service запускает все клиенты удаленных задач на основе фильтра намерений и разрешений.
При запуске клиента удаленной задачи клиент удаленной задачи регистрируется в Автосервисе.
Автосервис уведомляет клиента, выполняющего удалённые задачи, о регистрационной информации, включая идентификатор автомобиля и идентификатор клиента. Идентификатор клиента уникален и присваивается Автосервисом этому клиенту. Он гарантированно будет уникальным среди всех клиентов, выполняющих удалённые задачи, на одном и том же автомобиле.
Пользователь входит в систему сервера удалённых задач через клиент удалённых задач и включает функцию удалённого доступа для данного транспортного средства. Этот шаг обычно включает аутентификацию через сервер удалённых задач.
Клиент удаленных задач загружает информацию о пользователе вместе с идентификатором транспортного средства и идентификатором клиента на сервер удаленных задач и просит его связать пользователя с этим конкретным клиентом и этим конкретным транспортным средством.
При необходимости этот шаг может потребовать от пользователя прохождения дополнительной двухфакторной аутентификации.
Удаленный сервер задач должен подтвердить, что идентификатор транспортного средства, предоставленный в запросе, совпадает с идентификатором транспортного средства отправителя, что можно сделать с помощью аттестации транспортного средства.
Если не выполняется сброс настроек к заводским, регистрация клиента требуется один раз для каждого пользователя и автомобиля. Идентификатор клиента хранится локально в автосервисе и остаётся неизменным для одного и того же клиента.

Рисунок 2. Регистрация клиента.
Отменить регистрацию клиента
Пользователь может отвязать транспортное средство от своей учетной записи либо с транспортного средства, либо с удаленного сервера задач:
На транспортном средстве пользователи могут открыть клиентское приложение удаленных задач и отправить запрос на отмену связи, чтобы отсоединить данное транспортное средство от ранее связанных с ним учетных записей пользователей.
На сервере удаленных задач пользователи могут войти в свою учетную запись и отсоединить ранее привязанное к ней транспортное средство.
Если пользователь отвязывает транспортное средство от своей учетной записи, сервер удаленных задач должен удалить сохраненное сопоставление для конкретного пользователя.
Выполнять задачи
В облаке:
Пользователь использует сервер удаленных задач для отправки удаленной задачи определенному транспортному средству.
Сервер удалённых задач сопоставляет идентификатор пользователя с идентификатором транспортного средства и идентификатором клиента. Он отправляет данные о задаче, идентификатор транспортного средства и идентификатор клиента на сервер пробуждения.
Сервер пробуждения находит конкретный TCU для идентификатора транспортного средства (при условии, что регистрация TCU уже завершена) и отправляет данные задачи и идентификатор клиента в TCU.
На транспортном средстве ( жирным шрифтом выделены задачи, выполняемые AAOS):
TCU получает удаленные задачи с удаленного сервера.
Если процессор приложений (AP), на котором работает AAOS, выключен, TCU использует процессор транспортного средства (VP) для активации AP.
Автосервис получает задания от ТЦУ.
Автосервис распределяет задачи между соответствующими удаленными клиентами.
Удаленный клиент задачи получает и выполняет задачу.
( Необязательно ) Удаленный клиент задачи связывается с сервером задачи для получения более подробной информации о задаче и выполняет ее.
( Необязательно ) Удаленная служба клиента задач передает результаты задачи на сервер задач.
Клиент удаленной задачи уведомляет автосервис о завершении задачи.
При необходимости автосервис восстанавливает работоспособность электропитания автомобиля.

Рисунок 3. Выполнение задач.
Написать клиент для удаленных задач
CarRemoteAccessManager предоставляет API для функций удалённого доступа. Подробнее см. в разделе CarRemoteAccessManager . Клиент удалённых задач — это служба Android, которая выполняет удалённые задачи и использует CarRemoteAccessManager . Для этого требуются PERMISSION_USE_REMOTE_ACCESS и PERMISSION_CONTROL_REMOTE_ACCESS , а также необходимо объявить фильтр намерений для RemoteTaskClientService , например:
<service android:name=".remoteaccess.RemoteTaskClientService"
android:directBootAware="true"
android:exported="true">
<intent-filter>
<action android:name="android.car.remoteaccess.RemoteTaskClientService" />
</intent-filter>
</service>
Клиент удаленной задачи должен зарегистрироваться в Car Service во время создания:
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);
}
}
Он должен переопределить функцию onBind, чтобы она возвращала значение null.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Car Service управляет своим жизненным циклом. Car Service привязывается к этому сервису при запуске и при поступлении удалённой задачи. Car Service отвязывается от этого сервиса после завершения задачи. Подробнее см. в разделе Управление жизненным циклом сервиса .
Клиент удаленной задачи запускается как системный пользователь, поэтому у него нет доступа к каким-либо данным, специфичным для пользователя.
В следующем примере показано, как обрабатывать зарегистрированные обратные вызовы:
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();
}
}
Реализация поставщика
Функция удалённого доступа необязательна и по умолчанию отключена. Чтобы включить её, добавьте объект RRO, например:
// 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
}
Или используйте следующую команду adb в сборке userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Требования к Android
Удаленный доступ HAL
Уровень абстракции оборудования для удалённого доступа (HAL) — это уровень абстракции, реализованный производителем для взаимодействия между AAOS и другим ЭБУ (например, TCU). Он обязателен для поддержки функции удалённого доступа. Его реализация не требуется, если функция удалённого доступа не реализована.
Интерфейс определен в IRemoteAccess.aidl и включает следующие методы:
| Сорт | Описание |
|---|---|
String getVehicleId() | Получает уникальный идентификатор транспортного средства, который может быть распознан сервером пробуждения. |
String getWakeupServiceName() | Получает имя удаленного сервера пробуждения. |
String getProcessorId() | Получает уникальный идентификатор процессора, который может быть распознан при пробуждении клиента. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)Устанавливает обратный вызов, который будет вызван при запросе удаленной задачи. | |
void clearRemoteTaskCallback() | Очищает ранее установленный обратный вызов удаленной задачи. |
void notifyApStateChange(in ApState state)Определяет, готов ли процессор приложений к приему удаленных задач. | |
Интерфейс обратного вызова определен в IRemoteTaskCallback.aid .
| Сорт | Описание |
|---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)Обратный вызов, который выполняется при запросе удаленной задачи. |
См. эталонную реализацию с внешним TCU. Реализация использует долгоживущий поток чтения для получения удалённых задач и поддерживает следующую команду debug :
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
Автомобиль HAL
Для поддержки функции удаленного доступа VHAL должен поддерживать следующие свойства:
| Сорт | Описание |
|---|---|
SHUTDOWN_REQUEST | Запрос на выключение головного устройства. |
VEHICLE_IN_USE |
|
Более подробную информацию см. в разделе Поддерживаемые системные свойства .
Беззвучный режим
Для функции удалённого доступа должна поддерживаться бесшумный режим, чтобы автомобиль мог загружаться в бесшумном режиме для выполнения удалённых задач в отсутствие пользователя. В бесшумном режиме устройство AAOS загружается с отключённым дисплеем и звуком.
Тихий режим управляется с помощью двух файлов sysfs ядра Linux.
| Сорт | Описание |
|---|---|
/sys/kernel/silent_boot/pm_silentmode_kernel_stateПредставляет текущий беззвучный режим. | |
/sys/kernel/silent_boot/pm_silentmode_hw_stateПредставляет собой аппаратный сигнал для установки нового бесшумного режима. |
Процессор автомобиля отправляет аппаратный сигнал на SoC Android для включения/выключения режима Silent. Сигнал (0 или 1) записывается в /sys/kernel/silent_boot/pm_silentmode_hw_state . Затем фреймворк AAOS обновляет /sys/kernel/silent_boot/pm_silentmode_kernel_state , который представляет текущий режим Silent. Модули AAOS проверяют /sys/kernel/silent_boot/pm_silentmode_kernel_state чтобы определить, находится ли система в режиме Silent.
При получении удаленной задачи и загрузке AAOS процессор транспортного средства устанавливает бесшумный режим и запускает AAOS, чтобы система загружалась с выключенным дисплеем/звуком.
Компоненты, не относящиеся к Android, для бортового компьютера
Автомобильный процессор
Процессор транспортного средства — это процессор в транспортном средстве, который может управлять питанием процессора приложений под управлением Android. В архитектуре, представленной в примере, TCU активирует процессор приложений, отправляя сигнал процессору транспортного средства.
Компоненты, не относящиеся к Android, для бортового компьютера
Блок управления транспортным средством всегда может принимать удаленные сообщения.
Клиент пробуждения работает на TCU, обеспечивая долговременное соединение с удаленным сервером пробуждения.
AAOS, работающий на точке доступа, может взаимодействовать с клиентом пробуждения, работающим на TCU, через удаленный доступ HAL.

Рисунок 4. TCU (клиент пробуждения).
Облачные компоненты
Сервер пробуждения
Сервер пробуждения взаимодействует с клиентом пробуждения на TCU для:
- Поддерживайте долговременную связь с TCU транспортного средства.
- Найдите конкретный TCU по идентификационному номеру транспортного средства.
- Сообщите о состоянии транспортного средства. Например, онлайн или офлайн, или время последнего подключения к сети на удалённом сервере задач.
В реальной реализации сервер пробуждения может быть объединен с удаленным сервером задач.
Сервер удаленных задач
Сервер удаленных задач управляет этими удаленными задачами.
Пользователь взаимодействует с сервером для запуска новых удаленных задач и мониторинга удаленных задач.
Использует удаленный сервер пробуждения для пробуждения процессора приложений в транспортных средствах.
Взаимодействует с клиентом удаленных задач, работающим на транспортном средстве.
Сохраняет информацию о регистрации клиента. Это позволяет связать конкретного пользователя с конкретным клиентом удалённой задачи на конкретном транспортном средстве.
Обычно данные задачи , отправляемые через сервер удалённых задач на сервер пробуждения, в TCU транспортного средства и, в конечном итоге, клиенту удалённых задач, представляют собой просто идентификатор задачи. Клиент удалённых задач использует этот идентификатор для получения подробной информации с сервера удалённых задач.
Требования конфиденциальности и безопасности
| Задача | Состояние | Требование |
|---|---|---|
| TCU (клиент пробуждения) | ДОЛЖЕН |
|
| Сервер пробуждения | ДОЛЖЕН |
|
| Клиент удаленных задач | ДОЛЖЕН |
|
| Сервер удаленных задач | ДОЛЖЕН |
|
Сброс настроек к заводским и передача права собственности
Если пользователь выполняет сброс настроек к заводским, идентификатор клиента, хранящийся в Car Service, стирается. Однако серверы (сервер удалённых задач и сервер удалённого пробуждения) не уведомляются об этом. Серверы сохраняют привязку истёкшего идентификатора клиента к автомобилю. В результате, если пользователь запускает новую удалённую задачу для автомобиля, она использует истёкший идентификатор клиента. Автомобиль пробуждается, но удалённая задача не может быть выполнена, поскольку у клиента удалённой задачи другой идентификатор клиента, который не совпадает.
Ниже описан один из возможных вариантов сброса настроек к заводским.
При выполнении сброса настроек к заводским, поставщик предлагает пользователю войти на сервер удалённых задач и отсоединить автомобиль от своей учётной записи, если пользователь ранее уже привязывал автомобиль. Доступ к сети во время сброса настроек к заводским не гарантируется. Поэтому отправка запроса на отсоединение устройства во время сброса настроек к заводским может быть нецелесообразной.
При передаче права собственности на транспортное средство необходимо выполнить ряд действий, чтобы исключить возможность удалённого управления транспортным средством предыдущим владельцем. Например, новому владельцу может быть предложено:
Выполните сброс настроек к заводским. Это обеспечит восстановление идентификатора клиента. После этого предыдущий владелец по-прежнему сможет активировать автомобиль, но больше не сможет выполнять удалённые задачи.
Откройте клиентское приложение для удалённых задач и следуйте инструкциям по отмене регистрации клиента , чтобы отвязать автомобиль от учётной записи предыдущего владельца. Новый владелец может выполнить инструкции по регистрации клиента, чтобы привязать автомобиль к своей учётной записи и заменить ранее привязанную учётную запись.
Новый владелец может воспользоваться процессом регистрации клиента , чтобы привязать транспортное средство к своей учетной записи и заменить ранее привязанную учетную запись.
Тестирование клиента удаленных задач
Мы предоставляем эталонный каталог HAL для удалённого доступа default для тестирования клиентов удалённых задач. Вы можете использовать следующую команду debug для внедрения фиктивной удалённой задачи в HAL, которая будет перенаправлена вашему клиенту удалённых задач, если вы укажете правильный идентификатор клиента. Идентификатор клиента можно получить, зарегистрировав регистрационную информацию в реализации клиента удалённых задач.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]