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.

Aktualisierungen von Dienstpaketen

Service-Bundles können als APEX-Pakete unabhängig von vollständigen Systemupdates aktualisiert werden. In SDV wird dieser Aktualisierungsprozess vom SDV-Update-Manager verwaltet. Damit eine Aktualisierung wirksam wird, müssen Sie das Gerät neu starten.

Für Service-Bundle-Updates werden zwei Arten von APEX unterstützt:

Vorinstalliertes APEX: Eine frühere Version des APEX-Pakets ist bereits auf einer der schreibgeschützten Partitionen (/system, /system_ext, /product, /vendor und /odm) vorhanden.
Neues APEX: Auf keiner der schreibgeschützten Partitionen ist ein APEX-Paket mit demselben Namen (wie in apex_manifest.json) vorhanden.

Vorinstalliertes APEX

Dies ist die gängigste und empfohlene Methode zum Aktualisieren von Service-Bundles. Damit dieses Update gültig ist, muss das neue APEX-Paket die folgenden Anforderungen erfüllen:

In der Datei apex_manifest.json muss derselbe Paketname wie beim vorinstallierten APEX verwendet werden.
In der Datei apex_manifest.json muss ein höherer Versionscode als beim vorinstallierten APEX deklariert werden.

Hinweis: Für das vorinstallierte APEX darf kein Versionscode von 0 verwendet werden.
Signieren Sie das APEX mit demselben Schlüsselpaar wie das vorinstallierte APEX.

Neues APEX

Die Verwendung vorinstallierter APEX-Pakete ist zwar die beste Sicherheitsmethode, aber neue APEX-Pakete werden unterstützt. Bei diesem Ansatz sind Partner für die Einhaltung umfassender Sicherheitsprotokolle verantwortlich. Zu diesen Verantwortlichkeiten gehören:

Sichere Verwaltung der Signaturschlüssel, die für diese APEX-Pakete verwendet werden.
Einrichtung eines robusten Prozesses zum Erkennen und Blockieren schädlicher Pakete.
Konvertierung neuer APEX-Pakete in vorinstallierte APEX-Pakete bei nachfolgenden Systemupdates, sofern möglich.

Zum Installieren oder Aktualisieren eines neuen APEX-Pakets sind die folgenden Konfigurationen erforderlich.

Vertrauenswürdige öffentliche Schlüssel vorinstallieren

Zum Installieren eines neuen APEX-Pakets muss der öffentliche Signaturschlüssel auf der Zielpartition vorinstalliert sein. Platzieren Sie den öffentlichen Schlüssel in /partition/etc/brand_new_apex/, wobei /partition/ die Partition darstellt, mit der das APEX-Paket gemäß den Treble-Regeln verknüpft ist. Wenn die Signatur eines APEX-Pakets beispielsweise mit einem öffentlichen Schlüssel in /vendor/etc/brand_new_apex/ überprüft wird, verhält es sich wie ein Anbieter-APEX. Das System lehnt alle neuen APEX-Pakete ab, die nicht mit einem Schlüssel signiert sind, der einem vorinstallierten öffentlichen Schlüssel entspricht.

Schädliches neues APEX-Paket blockieren

Wenn ein neues APEX-Paket nach der Installation als schädlich identifiziert wird, muss es mit einem Systemupdate blockiert werden. Fügen Sie dazu den APEX-Paketnamen einer Sperrlistendatei in /partition/etc/brand_new_apex/blocklist.json hinzu. Diese Sperrliste muss auf der Zielpartition des APEX-Pakets platziert werden (derselben Partition, auf der der öffentliche Schlüssel vorinstalliert wurde). Jede Partition hat eine eigene Sperrlistendatei.