Freigegebenes Android-System-Image

Auf dieser Seite werden verschiedene Mechanismen vorgestellt, mit denen OEMs von Android-Geräten ein eigenes freigegebenes System-Image (SSI) für alle Produktlinien haben können. Außerdem wird ein Verfahren vorgeschlagen, mit dem ein SSI eines OEM auf einem von AOSP erstellten generischen System-Image (GSI) basiert.

Hintergrund

Mit Project Treble wurde das monolithische Android in zwei Teile aufgeteilt: den hardwarespezifischen Teil (die Anbieterimplementierung) und den generischen Betriebssystemteil (das Android-Betriebssystem-Framework). Die Software für beide wird in einer separaten Partition installiert: die Anbieterpartition für die hardwarespezifische Software und die Systempartition für die generische Betriebssystemsoftware. Eine versionierte Schnittstelle, die als Anbieterschnittstelle (VINTF) bezeichnet wird, wird für die beiden Partitionen definiert und erzwungen. Mit diesem Partitionssystem können Sie die Systempartition ändern, ohne die Partition des Anbieters zu ändern, und umgekehrt.

Ziel

Der in AOSP veröffentlichte Framework-Code entspricht der Treble-Architektur und ist abwärtskompatibel mit älteren Implementierungen von Anbietern. Ein generisches System-Image, das aus AOSP-Quellen von Android 10 erstellt wurde, kann beispielsweise auf jedem Treble-kompatiblen Gerät mit Android 8 oder höher ausgeführt werden. Die Android-Version, die auf Verbrauchergeräten installiert ist, wird von SoC-Anbietern und OEMs geändert. (Siehe Lebensdauer eines Android-Release.) Diese Änderungen und Erweiterungen am Framework wurden nicht für die Aufrechterhaltung der Abwärtskompatibilität entwickelt. Dies führte zu einer erhöhten Komplexität und höheren Kosten bei einem Betriebssystemupgrade. Gerätespezifische Änderungen und Anpassungen erhöhen die Kosten und Komplexität des Upgrades auf eine neue Android-Betriebssystemversion.

Vor Android 11 gab es keine klare Architektur, die es Partnern ermöglichte, modulare Erweiterungen für das Android-Betriebssystem zu entwickeln. In diesem Dokument werden die Schritte beschrieben, die SoC-Anbieter und OEMs ausführen können, um eine SSI zu erstellen. Das bedeutet, dass ein Image aus den Android-Betriebssystem-Framework-Quellen erstellt wird, um es auf mehreren Geräten wiederverwenden zu können, die Abwärtskompatibilität mit Anbieterimplementierungen aufrechtzuerhalten und die Komplexität und Kosten von Android-Betriebssystem-Upgrades erheblich zu senken. Die einzelnen Schritte zum Erstellen einer SSI finden Sie im Abschnitt Vorgeschlagene Schritte für GSI-basierte SSIs. Sie müssen nicht alle vier Schritte ausführen. Welche Schritte Sie auswählen (z. B. nur Schritt 1), hängt von Ihrer Implementierung ab.

SSI – Übersicht

Bei der SSI werden produktspezifische Softwarekomponenten und OEM-Erweiterungen in einer neuen /product-Partition platziert. Die Komponenten in der /product-Partition verwenden eine klar definierte, stabile Schnittstelle, um mit Komponenten in der /system-Partition zu interagieren. OEMs können entweder eine SSI erstellen oder eine kleine Anzahl von SSIs für die Verwendung für mehrere Geräte-SKUs verwenden. Wenn eine neue Version des Android-Betriebssystems veröffentlicht wird, müssen OEMs ihre SSIs nur einmal auf die neueste Android-Version aktualisieren. Sie können die SSIs wiederverwenden, um mehrere Geräte ohne Aktualisieren der /product-Partition zu aktualisieren.

OEMs und SoC-Anbieter erstellen SSIs, die alle benutzerdefinierten Funktionen und Änderungen enthalten, die ein OEM benötigt. Die auf dieser Seite beschriebenen Mechanismen und Best Practices sollen OEMs dabei helfen, die folgenden wichtigen Ziele zu erreichen:

• Die SSI kann für mehrere Geräte-SKUs wiederverwendet werden.
• Aktualisieren Sie das Android-System mit den modularen Erweiterungen, um Betriebssystem-Upgrades zu vereinfachen.

Die Grundidee, produktspezifische Komponenten in der Produktpartition zu trennen, ähnelt der Treble-Idee, SoC-spezifische Komponenten in der Anbieterpartition zu trennen. Eine Produktschnittstelle (ähnlich wie VINTF) ermöglicht die Kommunikation zwischen SSI und der Produktpartition. Hinweis: Im Zusammenhang mit SSI bezeichnet der Begriff „Komponenten“ alle Ressourcen, Binärdateien, Texte, Bibliotheken usw., die in Images installiert werden, die im Grunde zu Partitionen werden.

Partitionen um SSI

Abbildung 1 zeigt Partitionen um SSI herum und die versionierten Schnittstellen über die Partitionen und Richtlinien auf den Schnittstellen. In diesem Abschnitt werden die einzelnen Partitionen und Schnittstellen ausführlich erläutert.

Abbildung 1: Partitionen und Schnittstellen für SSI

Images und Partitionen

In den Informationen in diesem Abschnitt wird zwischen den Begriffen Image und Partition unterschieden.

• Ein Image ist eine Software, die unabhängig aktualisiert werden kann.
• Eine Partition ist ein physischer Speicherort, der unabhängig aktualisiert werden kann.

Die Abschnitte in Abbildung 1 sind so definiert:

• SSI:Das SSI ist das Image, das für einen OEM üblich ist und auf mehreren Geräten vorhanden sein kann. Es enthält keine hardware- oder produktspezifischen Komponenten. Alles in einer bestimmten SSI wird definitionsgemäß für alle Geräte freigegeben, die diese SSI verwenden. Das SSI besteht entweder aus einem einzelnen /system-Image oder aus einer /system- und einer /system_ext-Partition, wie in Abbildung 1 dargestellt.

  • Die Partition /system enthält AOSP-basierte Komponenten, während /system_ext, wenn implementiert, Erweiterungen und Komponenten von OEMs und SoC-Anbietern enthält, die eng mit AOSP-Komponenten verknüpft sind. Eine OEM-Java-Framework-Bibliothek, die benutzerdefinierte APIs für die eigenen Apps des OEMs bereitstellt, passt beispielsweise besser in die Partition /system_ext als in die Partition /system. Die Inhalte sowohl der /system- als auch der /system_ext-Partition werden aus von OEMs geänderten Android-Quellen erstellt.

  • Die Partition /system_ext ist optional, wird aber für benutzerdefinierte Funktionen und Erweiterungen empfohlen, die eng mit AOSP-basierten Komponenten verknüpft sind. Anhand dieser Unterscheidung können Sie die erforderlichen Änderungen ermitteln, um solche Komponenten im Laufe der Zeit von der Partition /system_ext in die Partition /product zu verschieben.

• Produkt: Eine Sammlung von produkt- oder gerätespezifischen Komponenten, die OEM-Anpassungen und ‑Erweiterungen des Android-Betriebssystems darstellen. Legen Sie SoC-spezifische Komponenten in die /vendor-Partition. SoC-Anbieter können die /product-Partition auch für geeignete Komponenten wie SoC-unabhängige Komponenten verwenden. Wenn ein SoC-Anbieter seinen OEM-Kunden beispielsweise eine SoC-unabhängige Komponente zur Verfügung stellt, die optional mit dem Produkt geliefert werden kann, kann der SoC-Anbieter diese Komponente in das Produktbild einfügen. Der Standort einer Komponente wird nicht durch ihre Eigentümerschaft, sondern durch ihren Zweck bestimmt.

• Anbieter: Eine Sammlung von SoC-spezifischen Komponenten.

• ODM: Eine Sammlung von trägerspezifischen Komponenten, die nicht vom SoC bereitgestellt werden. Normalerweise ist der SoC-Anbieter Inhaber des Anbieter-Images, während der Gerätehersteller Inhaber des ODM-Images ist. Wenn es keine separate /odm-Partition gibt, werden sowohl die SoC-Anbieter- als auch die ODM-Images in der /vendor-Partition zusammengeführt.

Übergänge zwischen Bildern

Für Anbieter- und Produktbilder gibt es zwei Hauptoberflächen für SSI:

• Vendor Interface (VINTF): VINTF ist die Schnittstelle zu den Komponenten, die sich in den Anbieter- und ODM-Images befinden. Komponenten in den Produkt- und System-Images können nur über diese Schnittstelle mit den Anbieter- und ODM-Images interagieren. Ein Anbieter-Image darf beispielsweise nicht von einem privaten Teil des System-Images abhängen und umgekehrt. Dies wurde ursprünglich in Project Treble definiert, bei dem die Images in System- und Anbieterpartitionen unterteilt werden. Die Benutzeroberfläche wird mit den folgenden Mechanismen beschrieben:

  • HIDL (Passthrough HAL ist nur für system- und system_ext-Module verfügbar)
  • Stable AIDL
  • Konfigurationen
    • Systemeigenschaften API
    • Config file schema API
  • VNDK
  • Android SDK APIs
  • Java SDK-Bibliothek

• Produktoberflächen: Die Produktoberfläche ist die Schnittstelle zwischen SSI und dem Produktbild. Durch die Definition einer stabilen Schnittstelle werden die Produktkomponenten von den Systemkomponenten in einer SSI getrennt. Die Produktoberfläche erfordert dieselben stabilen Oberflächen wie VINTF. Für Geräte, die mit Android 11 (und höher) auf den Markt kommen, werden jedoch nur die VNDK- und Android SDK APIs erzwungen.

SSI unter Android 11 aktivieren

In diesem Abschnitt wird erläutert, wie Sie die neuen Funktionen zur Unterstützung von SSI in Android 11 verwenden.

Die Partition „/system_ext“

Die Partition /system_ext wurde in Android 11 als optionale Partition eingeführt. (Dies ist der Ort für nicht AOSP-Komponenten, die eng mit den AOSP-definierten Komponenten in der /system-Partition gekoppelt sind.) Die /system_ext-Partition wird als OEM-spezifische Erweiterung der /system-Partition angesehen, ohne dass eine Schnittstelle für die beiden Partitionen definiert ist. Komponenten in der Partition /system_ext können private API-Aufrufe an die Partition /system senden und Komponenten in der Partition /system können private API-Aufrufe an die Partition /system_ext senden.

Da die beiden Partitionen eng miteinander verbunden sind, werden beide Partitionen zusammen aktualisiert, wenn eine neue Android-Version veröffentlicht wird. Eine /system_ext-Partition, die für die vorherige Android-Version erstellt wurde, muss nicht mit der /system-Partition in der nächsten Android-Version kompatibel sein.

Wenn Sie ein Modul auf der Partition /system_ext installieren möchten, fügen Sie der Datei Android.bp system_ext_specific: true hinzu. Bei Geräten ohne /system_ext-Partition installieren Sie solche Module im Unterverzeichnis ./system_ext der Partition /system.

Verlauf

Hier finden Sie einige Informationen zur /system_ext-Partition. Ziel des Designs war es, alle OEM-spezifischen Komponenten, unabhängig davon, ob sie häufig vorkommen, in der Partition /product zu platzieren. Es war jedoch nicht möglich, alle gleichzeitig zu verschieben, insbesondere da einige Komponenten eng mit der /system-Partition gekoppelt waren. Wenn Sie eine eng verbundene Komponente in die /product-Partition verschieben möchten, muss die Produktoberfläche erweitert werden. Das erforderte oft eine umfangreiche Refaktorisierung der Komponente selbst, was viel Zeit und Mühe kostete. Die Partition /system_ext wurde ursprünglich als temporärer Speicherort für Komponenten eingerichtet, die noch nicht in die Partition /product verschoben werden können. Ziel der SSI war es, die /system_ext-Partition letztendlich zu entfernen.

Die /system_ext-Partition ist jedoch nützlich, um die /system-Partition möglichst nah an AOSP zu halten. Bei der SSI-Methode liegt der größte Aufwand für die Umstellung auf die Komponenten in den Partitionen /system und /system_ext. Wenn das System-Image aus Quellen erstellt wird, die denen in AOSP möglichst ähnlich sind, können Sie sich beim Upgrade auf das system_ext-Image konzentrieren.

Komponenten aus den Partitionen „/system“ und „/system_ext“ in die Partition „/product“ verschieben

In Android 9 wurde die /product-Partition eingeführt, die mit der /system-Partition gekoppelt ist. Die Module in der /product-Partition nutzen die Systemressourcen ohne Einschränkungen und umgekehrt. Damit SSI unter Android 10 möglich ist, werden die Produktkomponenten in die Partitionen /system_ext und /product unterteilt. Die /system_ext-Partition muss nicht den Einschränkungen bei der Verwendung von Systemkomponenten unterliegen, die für die /system_ext-Partition in Android 9 galten./product Ab Android 10 muss die /product-Partition von der /system-Partition getrennt werden und stabile Schnittstellen aus den /system- und /system_ext-Partitionen verwenden.

Der primäre Zweck der Partition /system_ext besteht darin, Systemfunktionen zu erweitern, anstatt gebündelte Produktmodule zu installieren, wie im Abschnitt /system_ext partition beschrieben. Entfernen Sie dazu die produktspezifischen Module aus dem Bündel und verschieben Sie sie in die Partition /product. Wenn die produktspezifischen Module nicht mehr im Lieferumfang enthalten sind, ist /system_ext für alle Geräte verfügbar. Weitere Informationen finden Sie unter Partition „/system_ext“ gemeinsam nutzen.

Wenn Sie die /product-Partition von den Systemkomponenten entkoppeln möchten, muss die /product-Partition dieselbe Erzwingungsrichtlinie wie die /vendor-Partition haben, die bereits mit Project Treble entkoppelt wurde.

Ab Android 11 werden native und Java-Schnittstellen für die /product-Partition wie unten beschrieben erzwungen. Weitere Informationen finden Sie unter Produktpartitionsoberflächen erzwingen.

• Native Oberflächen: Die nativen Module in der /product-Partition müssen von den anderen Partitionen getrennt werden. Die einzigen zulässigen Abhängigkeiten von den Produktmodulen sind einige VNDK-Bibliotheken (einschließlich LLNDK) aus der /system-Partition. JNI-Bibliotheken, von denen die Produkt-Apps abhängen, müssen NDK-Bibliotheken sein.
• Java-Schnittstellen:Die Java-(App-)Module in der Partition /product können keine ausgeblendeten APIs verwenden, da sie instabil sind. Diese Module dürfen nur öffentliche APIs und System-APIs aus der Partition /system sowie Java SDK-Bibliotheken in der Partition /system oder /system_ext verwenden. Sie können Java SDK-Bibliotheken für benutzerdefinierte APIs definieren.

Empfohlene Schritte für GSI-basierte SSI

Abbildung 2: Vorgeschlagene Partitionen für GSI-basierte SSI

Ein generisches System-Image (GSI) ist das System-Image, das direkt aus AOSP erstellt wird. Es wird für die Treble-Compliance-Tests (z. B. CTS-on-GSI) und als Referenzplattform verwendet, mit der App-Entwickler die Kompatibilität ihrer Apps testen können, wenn sie kein echtes Gerät mit der erforderlichen Android-Version haben.

OEMs können auch GSI verwenden, um ihre SSI zu erstellen. Wie unter Images und Partitionen erläutert, besteht das SSI aus dem System-Image für die von AOSP definierten Komponenten und dem system_ext-Image für die vom OEM definierten Komponenten. Wenn GSI als system-Image verwendet wird, kann sich der OEM beim Upgrade auf das system_ext-Image konzentrieren.

Dieser Abschnitt enthält eine Anleitung für OEMs, die ihre Anpassungen in die Partitionen /system_ext und /product modularisieren und dabei ein AOSP- oder Near-AOSP-System-Image verwenden möchten. Wenn OEMs das System-Image aus AOSP-Quellen erstellen, können sie das von ihnen erstellte System-Image durch das von AOSP bereitgestellte GSI ersetzen. OEMs müssen jedoch nicht den letzten Schritt (die Verwendung von GSI in der aktuellen Form) auf einmal erreichen.

Schritt 1: generic_system.mk für das System-Image des OEMs (OEM GSI) erben

Durch das Übernehmen von generic_system.mk (das in Android 11 mainline_system.mk hieß und in AOSP in generic_system.mk umbenannt wurde) enthält das System-Image (OEM GSI) alle Dateien, die auch die AOSP GSI hat. Diese Dateien können von OEMs geändert werden, sodass die OEM-GSI neben den AOSP-GSI-Dateien auch die proprietären Dateien des OEMs enthalten kann. OEMs dürfen die Datei generic_system.mk jedoch nicht selbst ändern.

Abbildung 3: generic_system.mk für das Systemimage des OEMs übernehmen

Schritt 2: Die OEM-GSI muss dieselbe Liste von Dateien wie die AOSP-GSI haben.

Die OEM-GSI darf in dieser Phase keine zusätzlichen Dateien enthalten. Die proprietären Dateien des OEMs müssen in die Partitionen system_ext oder product verschoben werden.

Abbildung 4: Hinzugefügte Dateien aus der OEM-GSI verschieben

Schritt 3: Eine Zulassungsliste definieren, um die geänderten Dateien im OEM-GSI zu begrenzen

OEMs können die geänderten Dateien mit dem Tool compare_images prüfen und die AOSP-GSI mit der OEM-GSI vergleichen. Holen Sie sich die AOSP-GSI aus dem AOSP-Startziel generic_system_*.

Wenn Sie das Tool compare_images regelmäßig mit dem Parameter allowlist ausführen, können Sie die Unterschiede außerhalb der zulässigen Liste im Blick behalten. Dadurch sind keine zusätzlichen Änderungen an der OEM-GSI erforderlich.

Abbildung 5: Eine Zulassungsliste definieren, um die Liste der geänderten Dateien in der OEM-GSI zu reduzieren

Schritt 4: Die OEM-GSI muss dieselben Binärdateien wie die AOSP-GSI haben

Durch die Bereinigung der Zulassungsliste können OEMs die AOSP-GSI als System-Image für ihre eigenen Produkte verwenden. Um die Zulassungsliste zu bereinigen, können OEMs entweder ihre Änderungen in der OEM-GSI zurückziehen oder ihre Änderungen an AOSP senden, damit die AOSP-GSI ihre Änderungen enthält.

Abbildung 6 Die OEM-GSI muss dieselben Binärdateien wie die AOSP-GSI haben

SSI für OEMs definieren

Partition „/system“ bei der Buildzeit schützen

Um produktspezifische Änderungen an der /system-Partition zu vermeiden und die OEM-GSI zu definieren, können OEMs ein Makefile-Makro namens require-artifacts-in-path verwenden, um die Deklaration von Systemmodulen nach dem Aufruf des Makros zu verhindern. Weitere Informationen finden Sie im Beispiel Makefile erstellen und Prüfung des Pfads zu Artefakten aktivieren.

OEMs können eine Liste definieren, damit produktspezifische Module vorübergehend in der Partition /system installiert werden können. Die Liste muss jedoch leer sein, damit die OEM-GSI für alle Produkte des OEMs gilt. Dieser Prozess dient zum Definieren der OEM-GSI und kann unabhängig von den Schritten für die AOSP-GSI erfolgen.

Produktoberflächen erzwingen

Um sicherzustellen, dass die /product-Partition nicht gebündelt ist, können OEMs dafür sorgen, dass ihre Geräte die Produktschnittstellen erzwingen, indem sie PRODUCT_PRODUCT_VNDK_VERSION:= current für native Module und PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true für Java-Module festlegen. Diese Variablen werden automatisch festgelegt, wenn die PRODUCT_SHIPPING_API_LEVEL des Geräts größer oder gleich 30 ist. Weitere Informationen finden Sie unter Produktpartitionsoberflächen erzwingen.

Partition „/system_ext“ gemeinsam nutzen

Die /system_ext-Partition kann sich von Gerät zu Gerät unterscheiden, da sie gerätespezifische, im System enthaltene Module enthalten kann. Da die SSI aus /system- und /system_ext-Partitionen besteht, verhindern die Unterschiede in der /system_ext-Partition, dass OEMs eine SSI definieren können. OEMs können ihre eigene SSI haben und diese SSI für mehrere Geräte freigeben, indem sie alle Unterschiede entfernen und die /system_ext-Partition gemeinsam nutzen.

In diesem Abschnitt finden Sie Empfehlungen dazu, wie Sie die /system_ext-Partition gemeinsam nutzen können.

Ausgeblendete APIs in der Systempartition freigeben

Viele produktspezifische Apps können nicht in der Produktpartition installiert werden, da sie versteckte APIs verwenden, die in der Produktpartition verboten sind. Wenn Sie gerätespezifische Apps in die Produktpartition verschieben möchten, entfernen Sie die Verwendung versteckter APIs.

Die beste Methode zum Entfernen versteckter APIs aus Apps besteht darin, alternative öffentliche oder System-APIs zu finden, um sie zu ersetzen. Wenn es keine APIs gibt, mit denen die ausgeblendeten APIs ersetzt werden können, können OEMs zu AOSP beitragen, um die neuen System-APIs für ihre Geräte zu definieren.

Alternativ können OEMs benutzerdefinierte APIs definieren, indem sie in der Partition /system_ext eine eigene Java SDK-Bibliothek erstellen. Sie kann versteckte APIs in der Systempartition verwenden und die APIs für die Apps in der Produkt- oder Anbieterpartition bereitstellen. OEMs müssen die Produkt-APIs für die Abwärtskompatibilität einfrieren.

Alle APKs einschließen und einige Paketinstallationen für jedes Gerät überspringen

Bestimmte Pakete, die im Lieferumfang des Systems enthalten sind, sind nicht auf allen Geräten verfügbar. Das Entkoppeln dieser APK-Module, um sie in die Produkt- oder Anbieterpartition zu verschieben, kann schwierig sein. Als Zwischenlösung können OEMs die SSI so konfigurieren, dass alle Module enthalten sind, und dann unerwünschte Module mithilfe einer SKU-Eigenschaft (ro.boot.hardware.sku) herausfiltern. Um den Filter zu verwenden, überlagern OEMs die Framework-Ressourcen config_disableApkUnlessMatchedSku_skus_list und config_disableApksUnlessMatchedSku_apk_list.

Für genauere Einstellungen deklarieren Sie einen Broadcast-Empfänger, der unnötige Pakete deaktiviert. Der Broadcast-Empfänger ruft setApplicationEnabledSetting auf, um das Paket zu deaktivieren, wenn er die Nachricht ACTION_BOOT_COMPLETED empfängt.

RRO definieren, statt statisches Ressourcen-Overlay zu verwenden

Mit einem statischen Ressourcen-Overlay werden die überlagerten Pakete manipuliert. Dies kann jedoch die Definition einer SSI beeinträchtigen. Achten Sie daher darauf, dass die Properties für die RRO aktiviert und richtig festgelegt sind. Wenn OEMs die Eigenschaften so festlegen, können alle automatisch generierten Overlays als RROs verwendet werden.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Wenn eine detaillierte Konfiguration erforderlich ist, definieren Sie eine RRO manuell, anstatt sich auf eine automatisch generierte zu verlassen. Weitere Informationen finden Sie unter Laufzeit-Ressourcen-Overlays (RROs). OEMs können auch nutzerabhängige RROs definieren, die von den Systemeigenschaften abhängen. Verwenden Sie dazu die Attribute android:requiredSystemPropertyName und android:requiredSystemPropertyValue.

Häufig gestellte Fragen

Kann ich mehrere SSIs definieren?

Das hängt von den Gemeinsamkeiten und Merkmalen der Geräte (oder Gerätegruppe) ab. OEMs können versuchen, die system_ext-Partition gemeinsam zu verwenden, wie unter Die system_ext-Partition gemeinsam verwenden beschrieben. Wenn eine Gerätegruppe viele Unterschiede aufweist, sollten Sie mehrere SSIs definieren.

Kann ich generic_system.mk (mainline_system.mk) für eine OEM-GSI ändern?

Nein. OEMs können jedoch ein neues Makefile für eine OEM-GSI definieren, das die generic_system.mk-Datei erbt, und stattdessen das neue Makefile verwenden. Ein Beispiel finden Sie unter Produktpartitionsoberflächen erzwingen.

Kann ich Module aus „generic_system.mk“ entfernen, die mit meiner Implementierung in Konflikt stehen?

Nein. GSI hat eine Mindestanzahl von bootfähigen und testbaren Modulen. Wenn Sie der Meinung sind, dass ein Modul nicht erforderlich ist, reichen Sie bitte einen Fehlerbericht ein, um die generic_system.mk-Datei in AOSP zu aktualisieren.