Codebeispiele für den Kern

Mit den Codebeispielen für SDV-Core-Dienste in /system/software_defined_vehicle/samples können Sie mit der Entwicklung Ihrer Dienste beginnen. Jedes Beispiel enthält eine README-Datei, in der der Anwendungsfall beschrieben wird.

Beispielverzeichnis – Übersicht

In der folgenden Tabelle sind die Referenzbeispielverzeichnisse in system/software_defined_vehicle/samples und die entsprechenden Dokumentationsleitfäden aufgeführt:

Beispielverzeichnis Beschreibung Dokumentationsleitfaden
system/software_defined_vehicle/samples/quickstart Beispiel für ein End-to-End-Rust-Dienst-Bundle, das die VSIDL-Veröffentlichung, das Abo und den RPC zwischen Manager- und Monitor-Bundles veranschaulicht. Schnellstart: SDV-Dienst-Bundles erstellen und ausführen
system/software_defined_vehicle/samples/vsidl Referenzieren Sie VSIDL-Katalog, Protobuf-Definitionen und Implementierungsmuster für Dienst-Bundles. Geschäftslogik implementieren
system/software_defined_vehicle/samples/concal Clientbeispiel zum Lesen und Aktualisieren von Fahrzeugkonfigurations- und Kalibrierungsparametern. Konfiguration und Kalibrierung
system/software_defined_vehicle/samples/health Beispiele für Dienst-Bundles mit Zustandsüberwachung und Dienstqualitätsüberwachung (QoS). Statusüberwachung
system/software_defined_vehicle/samples/oem_partition_update_client Beispieldienst, der die sdv_oem_updater-Crate verwendet, um /oem_ab-Partitionsupdates auszulösen und rückgängig zu machen. OEM-AB-Partitionsupdates
system/software_defined_vehicle/samples/sdv_gateway Native und Java-IVI-Beispiel-Apps (NativeSdvGatewayTestApp und SdvCarMonitorTestApp), die über das SDV-Gateway mit SDV Core-Diensten kommunizieren. SDV-Gateway auf IVI verwenden
system/software_defined_vehicle/samples/telemetry On-Device-Telemetriedatenquelle und Simulatorbeispiele. Datenquellen

Logging API verwenden

Weitere Informationen zu den bereitgestellten Anleitungen finden Sie hier:

Einfaches Logbeispiel

logging.cpp stellt das Schreiben in die Puffer main, system und radio dar. Eine kurze Beschreibung der verfügbaren Logpuffer finden Sie unter Alternative Logpuffer ansehen.

  • So führen Sie das Beispiel ohne die bedingten Logs wie ALOGI_IF aus:

    logging_sdv_sample

  • So führen Sie das Beispiel aus und geben die bedingten Logs wie ALOGI_IF aus:

    LOGIF=1 logging_sdv_sample

Beispiel für strukturiertes Logging

Beispieldatei: structured_logging.cpp

  • So führen Sie das Beispiel aus, das Logs in den Logpuffer events schreibt:

    structured_logging_sdv_sample

Die Logpuffer event, security und stats enthalten strukturierte Daten anstelle von Freitext.

Strukturierte Daten werden mit der Ereignislisten-API protokolliert, die immer mit der Priorität INFO und der numerischen Tag-ID protokolliert wird.

Eine .logtags-Datei kann mit einem logtags-Attribut in Android.bp. definiert werden. Wenn sie angegeben ist, wird sie von logcat verwendet, um den Tag-Namen aus der numerischen Tag-ID abzuleiten. Der Tag-Name kann dann zum Filtern strukturierter Logs verwendet werden. Weitere Informationen und eine Beschreibung des Dateiformats finden Sie im Kommentar in der Datei logcat event.logtags.

Während des Build-Prozesses werden alle logtags-Dateien zusammengeführt und in der Datei /system/etc/event-log-tags im Android-System-Image abgelegt.

Beispiel für das Filtern von Zeitprotokollen kompilieren

Beispieldatei: compile_time_log_filtering.cpp

Dieses Beispiel enthält Makros, die Sie anpassen können, um einige Logs aus der ausführbaren Datei zu entfernen. Weitere Informationen finden Sie im Quellcode.

Beispiel für Logfilterung: log_filtering.cpp

  • So führen Sie das Beispiel aus und legen die Mindestpriorität für das Logging auf WARN fest:

    LOGLEVEL=WARN log_filtering_sdv_sample

Die Logfilterung wird von Systemeigenschaften beeinflusst. Für alle Logs mit :

  • log.tag.<tag>
  • persist.log.tag.<tag>

Für alle Logs im System:

  • log.tag
  • persist.log.tag

Um die ausgewählte Logebene auszuwählen, die der Reihe nach geprüft wird, kann jeder Wert auf V, D, I, W oder E gesetzt werden.

Die effektive Logebene ist die Ebene, die für die erste Systemeigenschaft mit einem Wert festgelegt ist. Sie kann niedriger oder höher als die Logebene sein, die von der App mit einem __android_log_set_minimum_priority-Aufruf festgelegt wird. Wenn keine der Properties festgelegt ist, gilt die mit __android_log_set_minimum_priority konfigurierte Ebene.

Weitere Informationen finden Sie in der Übersicht über das Logging-System.

  • Führen Sie das Beispiel aus und legen Sie das Standard-Log-Tag auf example_tag fest:

    LOGTAG=example_tag log_filtering_sdv_sample

Das Beispiel enthält auch eine auskommentierte LOG_TAG-Makrodefinition, mit der Sie das Log-Tag für alle Logeinträge festlegen können. Das so festgelegte Tag überschreibt das zur Laufzeit mit __android_log_set_default_tag festgelegte Tag.

Wenn das Makro LOG_TAG nicht definiert ist und die App __android_log_set_default_tag nicht aufruft, ist das Standard-Tag das Ergebnis von getprogname(). Beispiel: der Name der ausführbaren Datei.