Dynamische Systemupdates

Mit Dynamic System Updates (DSU) können Sie ein Android-Systemabbild erstellen, das Benutzer aus dem Internet herunterladen und ausprobieren können, ohne das aktuelle Systemabbild zu beschädigen. In diesem Dokument wird beschrieben, wie Sie DSU unterstützen.

Kernel-Anforderungen

Siehe Implementieren von dynamischen Partitionen für die Kernel - Anforderungen.

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

  • CONFIG_DM_VERITY=y
  • CONFIG_DM_VERITY_FEC=y

Partitionsanforderungen

Ab Android 11, erfordert DSU die /data die F2fs oder ext4 - Dateisystem zu verwenden. F2FS bietet eine bessere Leistung und wird empfohlen, aber der Unterschied sollte unbedeutend sein.

Hier sind einige Beispiele dafür, wie lange eine dynamische Systemaktualisierung mit einem Pixel-Gerät dauert:

  • F2FS verwenden:
    • 109s, 8G-Benutzer, 867M-System, Dateisystemtyp: F2FS: Verschlüsselung=aes-256-xts:aes-256-cts
    • 104s, 8G-Benutzer, 867M-System, Dateisystemtyp: F2FS: Verschlüsselung=ice
  • ext4 verwenden:
    • 135s, 8G-Benutzer, 867M-System, Dateisystemtyp: ext4:verschlüsselung=aes-256-xts:aes-256-cts

Wenn es auf Ihrer Plattform viel länger dauert, sollten Sie überprüfen, ob das Mount-Flag ein Flag enthält, das zum Schreiben von „sync“ führt, oder Sie können ein „async“-Flag explizit angeben, um eine bessere Leistung zu erzielen.

Die metadata (16 MB oder mehr) erforderlich , für die Daten in Bezug auf die installierten Bilder zu speichern. Es muss während der Montage der ersten Stufe montiert werden.

Die userdata Partition muss F2fs oder ext4 - Dateisystem verwenden. Wenn F2fs verwenden, schließen alle F2fs Patches in der zur Verfügung stehenden Zusammenhang Android gemeinsamen Kern .

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 Slots zum Speichern von Benutzerschlüsseln. Die DSU belegt zwei zusätzliche Schlüsselsteckplätze. Wenn ein OEM über eine Weaver-HAL verfügt, muss er über genügend Steckplätze für ein generisches System-Image (GSI) und ein Host-Image verfügen.

Pförtner HAL

Der Torwächter HAL muss groß unterstützen USER_ID Werte, weil die GSI - Offsets UIDs an die HAL von 1000000.

Boot überprüfen

Wenn Sie unterstützen möchten Booten Entwickler GSI Bilder in LOCKED Zustand ohne Verified Boot zu deaktivieren, schließen Entwickler GSI Schlüssel , indem Sie die folgende Zeile in die Datei device/<device_name>/device.mk :

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

Rückrollschutz

Bei Verwendung von DSU muss das heruntergeladene Android-Systemabbild neuer sein als das aktuelle Systemabbild auf dem Gerät. Dies wird durch einen Vergleich der Sicherheitspatch Ebenen in der getan Android Verified Boot (AVB) AVB Eigenschaftendeskriptor beider Systemabbilder: Prop: com.android.build.system.security_patch -> '2019-04-05' .

Bei Geräten mit AVB nicht, setzen Sie die Sicherheitspatch Stufe des aktuellen System - Image in die Kernel cmdline oder bootconfig mit dem Bootloader: androidboot.system.security_patch=2019-04-05 .

Hardware-Anforderungen

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

  • Eine logische Partition speichern GSI.img (1 ~ 1,5 G)
  • Eine 8 GB leer /data als Sandbox für den Betrieb der GSI

Wir empfehlen, vor dem Starten einer DSU-Instance mindestens 10 GB freien Speicherplatz zu reservieren. DSU unterstützt auch die Zuweisung 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 entscheidend für Geräte mit geringerer Leistung, die möglicherweise nicht über genügend internen Speicher verfügen. Wenn eine SD-Karte vorhanden ist, stellen Sie sicher, dass sie nicht übernommen wurde. DSU nicht unterstützt angenommen SD - Karten .

Verfügbare Frontends

Sie können DSU mit starten adb , einem OEM - App oder die One-Click - DSU - Loader (in Android 11 oder höher).

Starten von 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 von DSU mit einer App

Der Haupteingangspunkt zu DSU ist der android.os.image.DynamicSystemClient.java API:

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 DynamicSystemClient ein System API ist, können Sie die App mit dem regulären SDK API nicht bauen und man kann es nicht veröffentlichen auf Google Play. Der Zweck dieser App ist:

  1. Rufen Sie eine Bilderliste und die entsprechende URL mit einem vom Anbieter definierten Schema ab.
  2. Vergleichen Sie die Bilder in der Liste mit dem Gerät und zeigen Sie dem Benutzer kompatible Bilder zur Auswahl an.
  3. Invoke DynamicSystemClient.start wie folgt aus :

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

Die URL verweist auf eine gzip-komprimierte System-Image-Datei ohne Sparse, 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

Android 11 führt den One-Click-DSU-Loader ein, der ein Frontend in den Entwicklereinstellungen ist.

Starten des DSU-Loaders

Abbildung 1. Starten des DSU - Loader

Wenn der Entwickler die DSU Loader Schaltfläche klickt, ruft es eine vorkonfigurierte DSU JSON Deskriptors aus dem Internet und zeigt alle Bilder anwendbar in dem schwimmenden Menü. Wählen Sie ein Image aus, um die DSU-Installation zu starten, und der Fortschritt wird in der Benachrichtigungsleiste angezeigt.

Fortschritt der DSU-Image-Installation

Abbildung 2. DSU Bild Installation Fortschritt

Standardmäßig lädt der DSU-Loader einen JSON-Deskriptor, der die GSI-Images enthält. In den folgenden Abschnitten wird gezeigt, wie OEM-signierte DSU-Pakete erstellt und vom DSU-Loader geladen werden.

Feature-Flag

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

Aktivieren des Feature-Flags.

Abbildung 3. Aktivieren der Funktion flag

Die Benutzeroberfläche des Feature-Flags ist auf einem Gerät, auf dem ein Benutzer-Build ausgeführt wird, möglicherweise nicht verfügbar. In diesem Fall verwenden Sie die adb Befehl statt:

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

Host-System-Images des Anbieters auf GCE (optional)

Einer der möglichen Speicherorte für die System-Images ist der Google Compute Engine (GCE)-Bucket. Der Release - Administrator verwendet die GCP - Storage - Konsole hinzufügen / löschen / ändern , um die Freigabe Systemabbilds.

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

Öffentlicher Zugang in GCE

Abbildung 4. Der Zugang der Öffentlichkeit in GCE

Das Verfahren ein Element öffentlich zu machen , ist in der verfügbaren Google Cloud Dokumentation .

DSU mit mehreren Partitionen in ZIP-Datei

Ab Android 11 kann DSU mehr als eine Partition haben. Zum Beispiel kann es ein enthalten product.img neben dem system.img . Beim Booten des Geräts, wobei die erste Stufe init die installierten DSU Partitionen erkennt und ersetzt die On-Device - Partition vorübergehend, wenn die installierte DSU aktiviert ist. Das DSU-Paket kann eine Partition enthalten, die keine entsprechende Partition auf dem Gerät hat.

DSU-Prozess mit mehreren Partitionen

Abbildung 5. DSU Prozess mit mehreren Partitionen

OEM-signierte DSU

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

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

Sowohl system.img und product.img muss vom OEM - Schlüssel signiert werden , bevor sie in die ZIP - Datei gesetzt 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 zum Verifizieren verwendet wird. Die erste Stufe Ramdisk muss die Schnipsel öffentlichen Schlüssel, zum Beispiel umfassen, /avb/*.avbpubkey . Wenn das Gerät bereits AVB übernommen hat, reicht das bestehende Signierverfahren aus. Die folgenden Abschnitte veranschaulichen den Signiervorgang und heben die Platzierung des AVB-Pubkeys hervor, der verwendet wird, um die Images im DSU-Paket zu überprüfen.

DSU JSON-Deskriptor

Der DSU-JSON-Deskriptor beschreibt DSU-Pakete. Es unterstützt zwei Primitive. Erstens, die include primitive enthält zusätzliche JSON - Deskriptoren oder leitet den DSU - Loader an einen neuen Standort. Zum Beispiel:

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

Zweitens, das image ist primitiv verwendet freigegebene DSU - Pakete zu beschreiben. Innerhalb des Bildprimitiven gibt es mehrere Attribute:

  • Die name und details Attribute sind Zeichenfolge , die im Dialogfeld angezeigt werden , für den Benutzer zu wählen.

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

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

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

    Dialogfeld "Nutzungsbedingungen"

    Abbildung 6. Nutzungsbedingungen Dialogfeld

Als Referenz hier ein 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 ein String, der die Gerätearchitektur beschreibt. Dieses Attribut ist obligatorisch und wird mit der verglichenen ro.product.cpu.abi Systemeigenschaft. Ihre Werte müssen genau übereinstimmen.

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

  • vndk ist ein optionales Array , das alle VNDKs angibt , die in der DSU - Paket enthalten sind. Wenn es angegeben, die Lader DSU überprüft , ob die Zahl aus der extrahierten ro.vndk.version Systemeigenschaft ist im Preis inbegriffen.

Widerrufen von DSU-Schlüsseln aus Sicherheitsgründen

Im äußerst seltenen Fall, in dem das zum Signieren der DSU-Images 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 zum Aktualisieren der Bootpartition können Sie kompromittierte Schlüssel mithilfe einer DSU-Schlüsselsperrliste (Schlüssel-Blacklist) von einer HTTPS-URL blockieren.

Die DSU-Schlüsselsperrliste enthält eine Liste widerrufener öffentlicher AVB-Schlüssel. Während der DSU-Installation werden die öffentlichen Schlüssel in den DSU-Images mit der Sperrliste validiert. Wenn festgestellt wird, dass die Images einen widerrufenen öffentlichen Schlüssel enthalten, wird der DSU-Installationsprozess beendet.

Die URL der Schlüsselsperrliste sollte eine HTTPS-URL sein, um die Sicherheitsstärke zu gewährleisten, 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 , die eine Sperrliste für Google ist veröffentlicht GSI Tasten. 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 Widerrufsliste 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 die SHA-1 - Digest des Schlüssels widerrufen wird , in dem beschriebenen Format in dem den AVB pubkey Erzeugungsabschnitt.
  • status zeigt den Sperrstatus des Schlüssels. Derzeit ist der einzige unterstützte Wert REVOKED .
  • reason ist ein optionaler String in dem der Grund für den Widerruf.

DSU-Verfahren

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

Generieren eines neuen Schlüsselpaars

Verwenden Sie den openssl Befehl ein RSA private / öffentliches Schlüsselpaar zu erzeugen , in .pem - Format (zum Beispiel 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 möglicherweise nicht zugänglich sein und wird nur in einer gehaltenen Hardware - Sicherheitsmodul (HSM) . In diesem Fall ist möglicherweise nach der Schlüsselgenerierung ein x509-Zertifikat für den öffentlichen Schlüssel verfügbar. Sehen Sie das Hinzufügen der Paarung pubkey zum Ramdisk Abschnitt für Anweisungen , um die AVB der öffentlichen Schlüssel von einem x509 - Zertifikat zu generieren.

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.

Hinzufügen des Pairing-Pubkeys zur Ramdisk

Die oem_cert.avbpubkey muss unter gesetzt werden /avb/*.avbpubkey die 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 eine vorkompilierte Modul das kopieren avbpubkey . Zum Beispiel Add device/<company>/<board>/oem_cert.avbpubkey und device/<company>/<board>/avb/Android.mk mit Inhalt wie folgt aus :

    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 hängen von dem zusätzlichen oem_cert.avbpubkey :

    droidcore: oem_cert.avbpubkey
    

Generieren des AVB-Pubkey-Attributs im JSON-Deskriptor

Die oem_cert.avbpubkey ist in der AVB öffentlichen Schlüssel Binärformat. 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

Dadurch wird der Inhalt des seine pubkey Attributs des JSON - Descriptor.

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

Signieren eines DSU-Pakets

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

  • Methode 1: Wiederverwenden des Artefakts, das durch den ursprünglichen AVB-Signierungsprozess erstellt wurde, 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 zu verwenden, um die ZIP-Datei zu erstellen.

  • 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 - Paket (die ZIP - Datei) separat unterzeichnet:

    $ 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 über das Hinzufügen von add_hashtree_footer mit avbtool finden Sie verwenden avbtool .

Lokales Überprüfen des DSU-Pakets

Es wird empfohlen, alle lokalen Images mit den folgenden Befehlen gegen den öffentlichen Paarungsschlüssel 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 so 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 eines DSU-Pakets

Im folgenden Beispiel wird ein DSU - Paket , das eine enthält system.img und product.img :

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 -

Anpassen der Ein-Klick-DSU

Standardmäßig werden die Lader DSU verweist auf eine Metadaten von GSI Bilder , die ist https://...google.com/.../gsi-src.json .

OEMs kann durch die Definition das die Liste überschreibt persist.sys.fflag.override.settings_dynamic_system.list Eigenschaft , dass Punkte auf ihren eigenen JSON - Descriptor. Ein OEM kann beispielsweise JSON-Metadaten bereitstellen, die GSI sowie proprietäre OEM-Images wie diese enthalten:

{
    "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 einem OEM möglich, veröffentlichte DSU-Metadaten zu verketten, wie in Abbildung 7 gezeigt.

Verketten veröffentlichter DSU-Metadaten

Abbildung 7. Chaining veröffentlicht DSU Metadaten