Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Logische Architektur

AAOS SDV bietet eine dienstorientierte und datenzentrierte Architektur. Nutzer interagieren über die Middleware-Clientbibliothek mit dem System. Dabei werden sie von der Vehicle Services Interface Definition Language (VSIDL) unterstützt. Dadurch werden Infrastrukturdetails auf niedriger Ebene verborgen, sodass sich Entwickler auf die Kommunikation und Bereitstellungseinheiten auf hoher Ebene konzentrieren können.

Kommunikationsmodelle

Die logische Kommunikation in SDV wird durch Themen und Channels definiert.

Themen

Themen werden für die datenzentrierte Kommunikation (Publish/Subscribe) verwendet. Anstatt bestimmte Publisher zu finden, interagieren Nutzer mit Nachrichten, die zu bestimmten Themen veröffentlicht wurden.

Kennung:Ein Thema wird durch einen eindeutigen String identifiziert.
Datentyp:Nachrichten, die für ein Thema veröffentlicht werden, werden mit Protobuf definiert.
Entkopplung:Abonnenten interessieren sich für den Nachrichtentyp und den Namen des Themas, nicht für die Identität oder den Standort des Publishers. Mehrere Publisher können Nachrichten zum selben Thema veröffentlichen, was eine m:n-Kommunikation ermöglicht.

Kanäle

Channels werden für die Kommunikation auf Grundlage von Remoteprozeduraufrufen (RPCs) verwendet. Nutzer rufen Dienstmethoden auf einem bestimmten Channel auf, ohne wissen zu müssen, welcher Server die Anfrage verarbeitet.

Kennung:Ein Channel wird durch einen eindeutigen Namen identifiziert, z. B. main-control.
Diensttyp:RPC-Dienste werden durch ihren vollständig qualifizierten Protobuf-Dienstnamen identifiziert.
Abstraktion:Die Middleware findet die passende Serverinstanz für einen bestimmten Dienst und Channel.

Bereitstellung und Lebenszyklus

Die Entitäten in diesem Abschnitt definieren, wie Software in der SDV-Umgebung verpackt, autorisiert und instanziiert wird.

Servicepaket

Ein Dienstpaket ist eine Gruppe von zugehöriger Geschäftslogik, die zwei primäre Rollen erfüllt:

Bereitstellungseinheit:Service-Bundles werden als Teil eines SDV-Pakets bereitgestellt. Dabei handelt es sich um eine APEX-Datei und die kleinste Einheit der Software, die aktualisiert werden kann.
- Jedes Dienstbündel wird zur Laufzeit eindeutig einem einzelnen Linux-Prozess auf einer SDV-VM zugeordnet und wird als Dienstbündelinstanz bezeichnet.
- Auf Dienstbündel wird im SDV-Paketmanifest verwiesen, das Metadaten wie Name und Autorisierungsrichtlinien enthält.
Autorisierungseinheit:Berechtigungen werden für das gesamte Dienstpaket gewährt. Ein Service-Bundle ist autorisiert für:
- Bestimmte Themen veröffentlichen oder abonnieren (für einen bestimmten Nachrichtentyp).
- Bestimmte Channels für einen bestimmten Diensttyp bereitstellen oder aufrufen.

Dienstpaketinstanz

Eine Dienstbündelinstanz ist eine zur Laufzeit geladene Instanz eines Dienstbündels.

Jede Dienstpaketinstanz wird einzeln vom SDV Lifecycle Manager (LCM) verfolgt und identifiziert.
Das Starten von Service-Bundle-Instanzen wird vom SDV-Orchestrator ausgelöst und vom SDV-LCM gestartet und verfolgt.

SDV-Paket

Ein SDV-Paket ist die kleinste Einheit der Software-Aktualisierbarkeit und:

Eine Android Pony EXpress (APEX)-Datei.
Enthält ein oder mehrere Dienstpakete.
Wird alles auf einmal aktualisiert. Das bedeutet, dass alle Servicepakete in einem SDV-Paket gleichzeitig aktualisiert werden.

Der gesamte Code in einem SDV-Paket stammt aus derselben vertrauenswürdigen Quelle (demselben Softwareanbieter).

Verschiedene Versionen desselben SDV-Pakets können in verschiedenen SDV-VMs vorhanden sein.

Details zur Implementierung

In den folgenden Abschnitten werden Implementierungsdetails der SDV-Transportschicht beschrieben.

Hintergrund: Serviceeinheiten

Entwickler interagieren zwar hauptsächlich mit Themen und Channels, Serviceeinheiten bleiben jedoch der zugrunde liegende Mechanismus für die Registrierung und Erkennung im SDV-Kommunikationsstack.

Eine Serviceeinheit stellt einen einzelnen Endpunkt dar, z. B. einen RPC-Server oder einen Publisher. Die Middleware-Clientbibliothek (mw::clientlib) übernimmt die Registrierung und Erkennung dieser Serviceeinheiten im Hintergrund.