Dynamische Systemaktualisierungen

Mit dynamischen Systemaktualisierungen (DSU) können Sie ein Android-Systemabbild erstellen, das Benutzer aus dem Internet herunterladen und ausprobieren können, ohne das Risiko einer Beschädigung des aktuellen Systemabbilds einzugehen. In diesem Dokument wird beschrieben, wie Sie DSU unterstützen.

Kernel-Anforderungen

Informationen zu den Kernel-Anforderungen finden Sie unter „Implementieren dynamischer Partitionen“ .

Darüber hinaus verlässt sich DSU auf die Kernelfunktion „device-mapper-verity“ (dm-verity), um das Android-System-Image zu überprüfen. Daher müssen Sie die folgenden Kernel-Konfigurationen aktivieren:

  • CONFIG_DM_VERITY=y
  • CONFIG_DM_VERITY_FEC=y

Partitionsanforderungen

Ab Android 11 erfordert DSU, dass die /data Partition das F2FS- oder ext4-Dateisystem verwendet. F2FS bietet eine bessere Leistung und wird empfohlen, der Unterschied sollte jedoch unbedeutend sein.

Hier sind einige Beispiele dafür, wie lange ein dynamisches Systemupdate bei einem Pixel-Gerät dauert:

  • Mit F2FS:
    • 109s, 8G-Benutzer, 867M-System, Dateisystemtyp: F2FS: Encryption=aes-256-xts:aes-256-cts
    • 104s, 8G-Benutzer, 867M-System, Dateisystemtyp: F2FS: Verschlüsselung = Eis
  • Verwendung von ext4:
    • 135s, 8G-Benutzer, 867M-System, Dateisystemtyp: ext4: Encryption=aes-256-xts:aes-256-cts

Wenn es auf Ihrer Plattform viel länger dauert, sollten Sie prüfen, ob das Mount-Flag ein Flag enthält, das „sync“-Schreibvorgänge ermöglicht, oder Sie können explizit ein „async“-Flag angeben, um eine bessere Leistung zu erzielen.

Die metadata (16 MB oder größer) ist zum Speichern von Daten im Zusammenhang mit den installierten Images erforderlich. Es muss während der ersten Montagephase montiert werden.

Die userdata muss das Dateisystem F2FS oder ext4 verwenden. Wenn Sie F2FS verwenden, schließen Sie alle F2FS-bezogenen Patches ein, die im gemeinsamen Android-Kernel verfügbar sind.

DSU wurde mit Kernel/Common 4.9 entwickelt und getestet. Es wird empfohlen, für diese Funktion Kernel 4.9 und höher zu verwenden.

HAL-Verhalten des Anbieters

Weber HAL

Der Weaver HAL bietet eine feste Anzahl von Steckplätzen zum Speichern von Benutzerschlüsseln. Die DSU belegt zwei zusätzliche Schlüsselsteckplätze. Wenn ein OEM über ein Weaver-HAL verfügt, muss dieser über genügend Steckplätze für ein generisches System-Image (GSI) und ein Host-Image verfügen.

Pförtner HAL

Der Gatekeeper-HAL muss große USER_ID Werte unterstützen, da der GSI UIDs zum HAL um +1.000.000 versetzt.

Überprüfen Sie den Start

Wenn Sie das Starten von Entwickler-GSI-Images im Status „GESPERRT“ unterstützen möchten, ohne den verifizierten Start zu deaktivieren, schließen Sie Entwickler-GSI-Schlüssel ein, indem Sie die folgende Zeile zur Datei device/<device_name>/device.mk hinzufügen:

$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)

Rollback-Schutz

Bei Verwendung von DSU muss das heruntergeladene Android-Systemabbild neuer sein als das aktuelle Systemabbild auf dem Gerät. Dies erfolgt durch Vergleich der Sicherheitspatchstufen im AVB-Eigenschaftsdeskriptor für Android Verified Boot (AVB) beider Systemabbilder: Prop: com.android.build.system.security_patch -> '2019-04-05' .

Für Geräte, die AVB nicht verwenden, fügen Sie den Sicherheitspatch-Level des aktuellen Systemabbilds mit dem Bootloader in die Kernel-Cmdline oder Bootconfig ein: androidboot.system.security_patch=2019-04-05 .

Hardware-Anforderungen

Wenn Sie eine DSU-Instanz starten, werden zwei temporäre Dateien zugewiesen:

  • Eine logische Partition zum Speichern GSI.img (1–1,5 GB)
  • Eine 8 GB große leere /data Partition als Sandbox für die Ausführung von GSI

Wir empfehlen, vor dem Start einer DSU-Instanz mindestens 10 GB freien Speicherplatz zu reservieren. DSU unterstützt auch die Zuordnung von einer SD-Karte. Wenn eine SD-Karte vorhanden ist, hat diese die höchste Priorität für die Zuordnung. Die Unterstützung von SD-Karten ist für Geräte mit geringerer Leistung, die möglicherweise nicht über genügend internen Speicher verfügen, von entscheidender Bedeutung. Wenn eine SD-Karte vorhanden ist, stellen Sie sicher, dass diese nicht übernommen wird. DSU unterstützt keine akzeptierten SD-Karten .

Verfügbare Frontends

Sie können DSU mit adb , einer OEM-App oder dem Ein-Klick-DSU-Loader (in Android 11 oder höher) starten.

Starten Sie DSU mit adb

Geben Sie die folgenden Befehle ein, um DSU mit adb zu starten:

$ simg2img out/target/product/.../system.img system.raw
$ gzip -c system.raw > system.raw.gz
$ adb push system.raw.gz /storage/emulated/0/Download
$ adb shell am start-activity \
-n com.android.dynsystem/com.android.dynsystem.VerificationActivity  \
-a android.os.image.action.START_INSTALL    \
-d file:///storage/emulated/0/Download/system.raw.gz  \
--el KEY_SYSTEM_SIZE $(du -b system.raw|cut -f1)  \
--el KEY_USERDATA_SIZE 8589934592

Starten Sie DSU mit einer App

Der Haupteinstiegspunkt zu DSU ist die API android.os.image.DynamicSystemClient.java :

public class DynamicSystemClient {


...
...

     /**
     * Start installing DynamicSystem from URL with default userdata size.
     *
     * @param systemUrl A network URL or a file URL to system image.
     * @param systemSize size of system image.
     */
    public void start(String systemUrl, long systemSize) {
        start(systemUrl, systemSize, DEFAULT_USERDATA_SIZE);
    }

Sie müssen diese App auf dem Gerät bündeln/vorinstallieren. Da es sich DynamicSystemClient um eine System-API handelt, können Sie die App nicht mit der regulären SDK-API erstellen und nicht bei Google Play veröffentlichen. Der Zweck dieser App ist:

  1. Rufen Sie eine Bilderliste und die entsprechende URL mit einem vom Anbieter definierten Schema ab.
  2. Ordnen Sie die Bilder in der Liste dem Gerät zu und zeigen Sie dem Benutzer kompatible Bilder zur Auswahl an.

  3. Rufen Sie DynamicSystemClient.start wie folgt auf:

    DynamicSystemClient aot = new DynamicSystemClient(...)
   aot.start(
        ...URL of the selected image...,
        ...uncompressed size of the selected image...);

Die URL verweist auf eine komprimierte, nicht-sparse System-Image-Datei, die Sie mit den folgenden Befehlen erstellen können:

$ simg2img ${OUT}/system.img ${OUT}/system.raw
$ gzip ${OUT}/system.raw
$ ls ${OUT}/system.raw.gz

Der Dateiname sollte diesem Format folgen:

<android version>.<lunch name>.<user defined title>.raw.gz

Beispiele:

  • o.aosp_taimen-userdebug.2018dev.raw.gz
  • p.aosp_taimen-userdebug.2018dev.raw.gz

Ein-Klick-DSU-Loader

Mit Android 11 wird der Ein-Klick-DSU-Loader eingeführt, ein Frontend in den Entwicklereinstellungen.

Starten des DSU-Loaders

Abbildung 1. Starten des DSU-Loaders

Wenn der Entwickler auf die Schaltfläche „DSU Loader“ klickt, ruft er einen vorkonfigurierten DSU-JSON-Deskriptor aus dem Web ab und zeigt alle anwendbaren Bilder im schwebenden Menü an. Wählen Sie ein Image aus, um die DSU-Installation zu starten. Der Fortschritt wird in der Benachrichtigungsleiste angezeigt.

Fortschritt der DSU-Image-Installation

Abbildung 2. Fortschritt der DSU-Image-Installation

Standardmäßig lädt der DSU-Loader einen JSON-Deskriptor, der die GSI-Bilder enthält. In den folgenden Abschnitten wird gezeigt, wie Sie OEM-signierte DSU-Pakete erstellen und diese aus dem DSU-Loader laden.

Feature-Flag

Die DSU-Funktion befindet sich unter dem Funktionsflag settings_dynamic_android . Stellen Sie vor der Verwendung von DSU sicher, dass das entsprechende Feature-Flag aktiviert ist.

Aktivieren des Feature-Flags.

Abbildung 3. Aktivieren des Feature-Flags

Die Feature-Flag-Benutzeroberfläche ist möglicherweise auf einem Gerät, auf dem ein Benutzerbuild ausgeführt wird, nicht verfügbar. Verwenden Sie in diesem Fall stattdessen den Befehl adb :

$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1

Hostsystem-Images des Anbieters auf GCE (optional)

Einer der möglichen Speicherorte für die Systemabbilder ist der Google Compute Engine (GCE)-Bucket. Der Release-Administrator verwendet die GCP-Speicherkonsole , um das veröffentlichte System-Image hinzuzufügen/zu löschen/zu ändern.

Die Bilder müssen öffentlich zugänglich sein, wie hier gezeigt:

Öffentlicher Zugriff in GCE

Abbildung 4. Öffentlicher Zugriff in GCE

Das Verfahren zum Veröffentlichen eines Elements finden Sie in der Google Cloud-Dokumentation .

DSU mit mehreren Partitionen in ZIP-Datei

Ab Android 11 kann DSU mehr als eine Partition haben. Beispielsweise kann es neben system.img auch eine product.img enthalten. Wenn das Gerät startet, erkennt die erste Init init Stufe die installierten DSU-Partitionen und ersetzt vorübergehend die Gerätepartition, wenn das installierte DSU aktiviert ist. Das DSU-Paket enthält möglicherweise eine Partition, für die es auf dem Gerät keine entsprechende Partition gibt.

DSU-Prozess mit mehreren Partitionen

Abbildung 5. DSU-Prozess mit mehreren Partitionen

OEM-signiertes DSU

Um sicherzustellen, dass alle auf dem Gerät ausgeführten Bilder vom Gerätehersteller autorisiert sind, müssen alle Bilder in einem DSU-Paket signiert werden. Angenommen, es gibt ein DSU-Paket, das zwei Partitionsbilder wie unten enthält:

dsu.zip {
    - system.img
    - product.img
}

Sowohl system.img als auch product.img müssen mit dem OEM-Schlüssel signiert werden, bevor sie in die ZIP-Datei eingefügt werden. Die gängige Praxis ist die Verwendung eines asymmetrischen Algorithmus, beispielsweise RSA, bei dem der geheime Schlüssel zum Signieren des Pakets und der öffentliche Schlüssel zur Überprüfung des Pakets verwendet wird. Die Ramdisk der ersten Stufe muss den öffentlichen Paring-Schlüssel enthalten, zum Beispiel /avb/*.avbpubkey . Wenn das Gerät bereits AVB unterstützt, reicht das bestehende Signaturverfahren aus. Die folgenden Abschnitte veranschaulichen den Signiervorgang und verdeutlichen die Platzierung des AVB-Pubkeys, der zur Überprüfung der Bilder im DSU-Paket verwendet wird.

DSU-JSON-Deskriptor

Der DSU-JSON-Deskriptor beschreibt DSU-Pakete. Es unterstützt zwei Grundelemente. Erstens schließt das include Grundelement zusätzliche JSON-Deskriptoren ein oder leitet den DSU-Loader an einen neuen Speicherort um. Zum Beispiel:

{
    "include": ["https://.../gsi-release/gsi-src.json"]
}

Zweitens wird das image verwendet, um veröffentlichte DSU-Pakete zu beschreiben. Innerhalb des Bildprimitivs gibt es mehrere Attribute:

  • Bei den Attributen name und details handelt es sich um Zeichenfolgen, die im Dialogfeld angezeigt werden und vom Benutzer ausgewählt werden können.

  • Die Attribute cpu_api , vndk und os_version werden für Kompatibilitätsprüfungen verwendet, die im nächsten Abschnitt beschrieben werden.

  • Das optionale pubkey Attribut beschreibt den öffentlichen Schlüssel, der mit dem geheimen Schlüssel gekoppelt ist, der zum Signieren des DSU-Pakets verwendet wird. Wenn es angegeben ist, kann der DSU-Dienst prüfen, ob das Gerät über den Schlüssel verfügt, der zur Überprüfung des DSU-Pakets verwendet wird. Dadurch wird die Installation eines nicht erkannten DSU-Pakets vermieden, beispielsweise die Installation eines von OEM-A signierten DSU auf einem von OEM-B hergestellten Gerät.

  • Das optionale tos Attribut verweist auf eine Textdatei, die die Nutzungsbedingungen für das entsprechende DSU-Paket beschreibt. Wenn ein Entwickler ein DSU-Paket mit dem angegebenen Attribut „Nutzungsbedingungen“ auswählt, wird das in Abbildung 6 gezeigte Dialogfeld geöffnet, in dem der Entwickler aufgefordert wird, die Nutzungsbedingungen zu akzeptieren, bevor er das DSU-Paket installiert.

    Dialogfeld „Nutzungsbedingungen“.

    Abbildung 6. Dialogfeld „Nutzungsbedingungen“.

Als Referenz finden Sie hier einen DSU-JSON-Deskriptor für die GSI:

{
   "images":[
      {
         "name":"GSI+GMS x86",
         "os_version":"10",
         "cpu_abi": "x86",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_x86-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI+GMS ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI x86_64",
         "os_version":"10",
         "cpu_abi": "x86_64",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_x86_64-exp-QP1A.190711.020.C4-5928301.zip"
      }
   ]
}

Kompatibilitätsmanagement

Mehrere Attribute werden verwendet, um die Kompatibilität zwischen einem DSU-Paket und dem lokalen Gerät anzugeben:

  • cpu_api ist eine Zeichenfolge, die die Gerätearchitektur beschreibt. Dieses Attribut ist obligatorisch und wird mit der Systemeigenschaft ro.product.cpu.abi verglichen. Ihre Werte müssen genau übereinstimmen.

  • os_version ist eine optionale Ganzzahl, die eine Android-Version angibt. Für Android 10 ist os_version beispielsweise 10 und für Android 11 ist os_version 11 . Wenn dieses Attribut angegeben wird, muss es gleich oder größer als die Systemeigenschaft ro.system.build.version.release sein. Diese Prüfung wird verwendet, um das Booten eines Android 10 GSI-Images auf einem Android 11-Anbietergerät zu verhindern, was derzeit nicht unterstützt wird. Das Booten eines Android 11 GSI-Images auf einem Android 10-Gerät ist zulässig.

  • vndk ist ein optionales Array, das alle VNDKs angibt, die im DSU-Paket enthalten sind. Wenn es angegeben wird, prüft der DSU-Loader, ob die aus der Systemeigenschaft ro.vndk.version extrahierte Nummer enthalten ist.

Aus Sicherheitsgründen DSU-Schlüssel widerrufen

In dem äußerst seltenen Fall, dass das zum Signieren der DSU-Bilder verwendete RSA-Schlüsselpaar kompromittiert wird, sollte die Ramdisk so schnell wie möglich aktualisiert werden, um den kompromittierten Schlüssel zu entfernen. Zusätzlich zur Aktualisierung der Startpartition können Sie kompromittierte Schlüssel mithilfe einer DSU-Schlüsselsperrliste (Schlüssel-Blacklist) von einer HTTPS-URL aus blockieren.

Die DSU-Schlüsselwiderrufsliste enthält eine Liste der widerrufenen öffentlichen AVB-Schlüssel. Während der DSU-Installation werden die öffentlichen Schlüssel in den DSU-Images anhand der Sperrliste validiert. Wenn festgestellt wird, dass die Bilder einen widerrufenen öffentlichen Schlüssel enthalten, wird der DSU-Installationsprozess angehalten.

Die URL der Schlüsselsperrliste sollte eine HTTPS-URL sein, um die Sicherheitsstärke sicherzustellen, und wird in einer Ressourcenzeichenfolge angegeben:

frameworks/base/packages/DynamicSystemInstallationService/res/values/strings.xml@key_revocation_list_url

Der Wert der Zeichenfolge ist https://dl.google.com/developers/android/gsi/gsi-keyblacklist.json , eine Sperrliste für von Google veröffentlichte GSI-Schlüssel. Diese Ressourcenzeichenfolge kann überlagert und angepasst werden, sodass OEMs, die die DSU-Funktion übernehmen, ihre eigene Schlüssel-Blacklist bereitstellen und verwalten können. Dies bietet dem OEM die Möglichkeit, bestimmte öffentliche Schlüssel zu blockieren, ohne das Ramdisk-Image des Geräts zu aktualisieren.

Das Format der Sperrliste ist:

{
   "entries":[
      {
         "public_key":"bf14e439d1acf231095c4109f94f00fc473148e6",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      },
      {
         "public_key":"d199b2f29f3dc224cca778a7544ea89470cbef46",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      }
   ]
}
  • public_key ist der SHA-1-Digest des widerrufenen Schlüssels in dem Format, das im Abschnitt zum Generieren des AVB-Pubkeys beschrieben wird.
  • status gibt den Sperrstatus des Schlüssels an. Derzeit ist der einzige unterstützte Wert REVOKED .
  • reason ist eine optionale Zeichenfolge, die den Grund für den Widerruf beschreibt.

DSU-Verfahren

In diesem Abschnitt wird beschrieben, wie Sie verschiedene DSU-Konfigurationsverfahren durchführen.

Erzeugen Sie ein neues Schlüsselpaar

Verwenden Sie den Befehl openssl , um ein privates/öffentliches RSA-Schlüsselpaar im .pem Format zu generieren (z. B. mit einer Größe von 2048 Bit):

$ openssl genrsa -out oem_cert_pri.pem 2048
$ openssl rsa -in oem_cert_pri.pem -pubout -out oem_cert_pub.pem

Der private Schlüssel ist möglicherweise nicht zugänglich und wird nur in einem Hardware-Sicherheitsmodul (HSM) aufbewahrt. In diesem Fall ist möglicherweise nach der Schlüsselgenerierung ein x509-Public-Key-Zertifikat verfügbar. Anweisungen zum Generieren des öffentlichen AVB-Schlüssels aus einem x509-Zertifikat finden Sie im Abschnitt „Pairing-Pubkey zur Ramdisk hinzufügen“ .

So konvertieren Sie ein x509-Zertifikat in das PEM-Format:

$ openssl x509 -pubkey -noout -in oem_cert_pub.x509.pem > oem_cert_pub.pem

Überspringen Sie diesen Schritt, wenn das Zertifikat bereits eine PEM-Datei ist.

Fügen Sie den Pairing-Pubkey zur Ramdisk hinzu

Der oem_cert.avbpubkey muss unter /avb/*.avbpubkey abgelegt werden, um das signierte DSU-Paket zu überprüfen. Konvertieren Sie zunächst den öffentlichen Schlüssel im PEM-Format in das öffentliche AVB-Schlüsselformat:

$ avbtool extract_public_key --key oem_cert_pub.pem --output oem_cert.avbpubkey

Fügen Sie dann den öffentlichen Schlüssel mit den folgenden Schritten in die Ramdisk der ersten Stufe ein.

  1. Fügen Sie ein vorgefertigtes Modul hinzu, um den avbpubkey zu kopieren. Fügen Sie beispielsweise device/<company>/<board>/oem_cert.avbpubkey und device/<company>/<board>/avb/Android.mk mit Inhalten wie diesem hinzu:

    include $(CLEAR_VARS)

LOCAL_MODULE := oem_cert.avbpubkey
LOCAL_MODULE_CLASS := ETC
LOCAL_SRC_FILES := $(LOCAL_MODULE)
ifeq ($(BOARD_USES_RECOVERY_AS_BOOT),true)
LOCAL_MODULE_PATH := $(TARGET_RECOVERY_ROOT_OUT)/first_stage_ramdisk/avb
else
LOCAL_MODULE_PATH := $(TARGET_RAMDISK_OUT)/avb
endif

include $(BUILD_PREBUILT)

  2. Machen Sie das Droidcore-Ziel vom hinzugefügten oem_cert.avbpubkey abhängig:

    droidcore: oem_cert.avbpubkey

Generieren Sie das AVB-Pubkey-Attribut im JSON-Deskriptor

Der oem_cert.avbpubkey liegt im binären AVB-Public-Key-Format vor. Verwenden Sie SHA-1, um es lesbar zu machen, bevor Sie es in den JSON-Deskriptor einfügen:

$ sha1sum oem_cert.avbpubkey | cut -f1 -d ' '
3e62f2be9d9d813ef5........866ac72a51fd20

Dies ist der Inhalt des pubkey Attributs des JSON-Deskriptors.

   "images":[
      {
         ...
         "pubkey":"3e62f2be9d9d813ef5........866ac72a51fd20",
         ...
      },

Unterzeichnen Sie ein DSU-Paket

Verwenden Sie eine dieser Methoden, um ein DSU-Paket zu signieren:

  • Methode 1: Verwenden Sie das durch den ursprünglichen AVB-Signaturprozess erstellte Artefakt erneut, um ein DSU-Paket zu erstellen. Ein alternativer Ansatz besteht darin, die bereits signierten Bilder aus dem Release-Paket zu extrahieren und die extrahierten Bilder direkt zur Erstellung der ZIP-Datei zu verwenden.

  • Methode 2: Verwenden Sie die folgenden Befehle, um DSU-Partitionen zu signieren, wenn der private Schlüssel verfügbar ist. Jedes img innerhalb eines DSU-Pakets (der ZIP-Datei) wird separat signiert:

    $ key_len=$(openssl rsa -in oem_cert_pri.pem -text | grep Private-Key | sed -e 's/.*(\(.*\) bit.*/\1/')
$ for partition in system product; do
    avbtool add_hashtree_footer \
        --image ${OUT}/${partition}.img \
        --partition_name ${partition} \
        --algorithm SHA256_RSA${key_len} \
        --key oem_cert_pri.pem
done

Weitere Informationen zum Hinzufügen add_hashtree_footer mit avbtool finden Sie unter Verwenden von avbtool .

Überprüfen Sie das DSU-Paket lokal

Es wird empfohlen, alle lokalen Images mit den folgenden Befehlen anhand des öffentlichen Kopplungsschlüssels zu überprüfen:


for partition in system product; do
    avbtool verify_image --image ${OUT}/${partition}.img  --key oem_cert_pub.pem
done

Die erwartete Ausgabe sieht folgendermaßen aus:

Verifying image dsu/system.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/system.img
: Successfully verified sha1 hashtree of dsu/system.img for image of 898494464 bytes

Verifying image dsu/product.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/product.img
: Successfully verified sha1 hashtree of dsu/product.img for image of 905830400 bytes

Erstellen Sie ein DSU-Paket

Das folgende Beispiel erstellt ein DSU-Paket, das eine system.img und eine product.img enthält:

dsu.zip {
    - system.img
    - product.img
}

Nachdem beide Bilder signiert wurden, verwenden Sie den folgenden Befehl, um die ZIP-Datei zu erstellen:

$ mkdir -p dsu
$ cp ${OUT}/system.img dsu
$ cp ${OUT}/product.img dsu
$ cd dsu && zip ../dsu.zip *.img && cd -

Passen Sie das Ein-Klick-DSU an

Standardmäßig verweist der DSU-Loader auf Metadaten von GSI-Bildern, die https://...google.com/.../gsi-src.json lauten.

OEMs können die Liste überschreiben, indem sie die Eigenschaft persist.sys.fflag.override.settings_dynamic_system.list definieren, die auf ihren eigenen JSON-Deskriptor verweist. Beispielsweise kann ein OEM JSON-Metadaten bereitstellen, die GSI sowie proprietäre OEM-Bilder wie dieses umfassen:

{
    "include": ["https://dl.google.com/.../gsi-src.JSON"]
    "images":[
      {
         "name":"OEM image",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"...",
         "vndk":[
            27,
            28,
            29
         ],
         "spl":"...",
         "pubkey":"",
         "uri":"https://.../....zip"
      },

}

Es ist für einen OEM möglich, veröffentlichte DSU-Metadaten zu verketten, wie in Abbildung 7 dargestellt.

Verkettung veröffentlichter DSU-Metadaten

Abbildung 7. Verkettung veröffentlichter DSU-Metadaten