Diese Seite wurde von der Cloud Translation API übersetzt.

dynamisches Systemupdate

Mit Dynamic System Updates (DSU) können Sie ein Android-System-Image erstellen, das Nutzende aus dem Internet herunterladen und die Funktion testen können, ohne sie zu beschädigen. das aktuelle System-Image. In diesem Dokument wird beschrieben, wie DSU unterstützt wird.

Kernel-Anforderungen

Weitere Informationen finden Sie unter Dynamische Partitionen implementieren für Kernel-Anforderungen.

Darüber hinaus stützt sich DSU auf die Kernel-Funktion "device-mapper-verity" (dm-verity). um das Android-System-Image zu verifizieren. Sie müssen also den folgenden Kernel aktivieren Konfigurationen:

CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_FEC=y

Partitionsanforderungen

Ab Android 11 benötigt DSU die /data F2FS- oder ext4-Dateisystem verwenden. 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 mit einem Pixel dauert Gerät:

Mit F2FS: <ph type="x-smartling-placeholder">
- 109s, 8G-Nutzer, 867M-System, Dateisystemtyp: F2FS: verschlüsselung=aes-256-xts:aes-256-cts
- 104s, 8G-Nutzer, 867M-System, Dateisystemtyp: F2FS: Verschlüsselung=Eis
Mit ext4: <ph type="x-smartling-placeholder">
- 135s, 8G-Nutzer, 867M-System, Dateisystemtyp: ext4: verschlüsselung=aes-256-xts:aes-256-cts

Wenn es viel länger auf der Plattform dauert, solltest du prüfen, ob die Halterung Flag enthält ein beliebiges Flag, das einen Schreibvorgang durch „sync“ bewirkt, oder Sie können ein Flag mit dem Wert „async“ angeben. explizit kennzeichnen, um eine bessere Leistung zu erzielen.

Die Partition metadata (16 MB oder größer) ist erforderlich, um datenbezogene den installierten Images. Es muss während der Bereitstellung der ersten Phase bereitgestellt werden.

Die Partition userdata muss das Dateisystem F2FS oder ext4 verwenden. Wenn Sie F2FS verwenden, alle F2FS-bezogenen Patches hinzufügen, die in der Gemeinsamer Android-Kernel

DSU wurde mit Kernel/common 4.9 entwickelt und getestet. Wir empfehlen die Verwendung von Kernel 4.9 und höher.

HAL-Verhalten des Anbieters

Weaver HAL

Der Weaver-HAL bietet eine feste Anzahl von Slots zum Speichern von Nutzerschlüsseln. Die DSU werden zwei zusätzliche Schlüssel-Slots verbraucht. Wenn ein OEM über einen Weaver-HAL verfügt, muss er genügend Slots für ein generisches System-Image (GSI) und ein Host-Image haben.

Gatekeeper HAL

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

Start prüfen

Wenn Sie das Booten von GSI-Images für Entwickler unterstützen möchten sich im Status LOCKED befindet, ohne zu deaktivieren Verified Boot; geben Sie Entwickler-GSI-Schlüssel an, indem Sie die folgende Zeile hinzufügen in die Datei device/<device_name>/device.mk:

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

Rollback-Schutz

Bei Verwendung von DSU muss das heruntergeladene Android-System-Image neuer sein als das das aktuelle System-Image auf dem Gerät. Dazu wird der Sicherheitspatch verglichen Ebenen in der Verifizierter Bootmodus von Android (AVB) AVB-Property-Deskriptor beider System-Images: Prop: com.android.build.system.security_patch -> '2019-04-05'.

Bei Geräten ohne AVB die Sicherheitspatch-Ebene des aktuellen Systems verwenden Image mit dem Bootloader in die Kernel-cmdline oder in die bootconfig-Datei ein: androidboot.system.security_patch=2019-04-05

Hardwareanforderungen

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

Eine logische Partition zum Speichern von GSI.img (1~1,5 G)
Eine leere /data-Partition mit 8 GB als Sandbox zum Ausführen von GSI

Wir empfehlen, mindestens 10 GB freien Speicherplatz zu reservieren, bevor eine DSU gestartet wird. Instanz. DSU unterstützt auch die Zuweisung von einer SD-Karte. Wenn eine SD-Karte vorhanden ist, hat sie die höchste Priorität für die Zuweisung. SD-Karten werden unterstützt: besonders wichtig für Geräte mit geringerer Leistung, die möglicherweise nicht genügend internen Speicher haben. Falls eine SD-Karte vorhanden ist, vergewissern Sie sich, dass sie nicht verwendet wird. DSU unterstützt keine SD-Karten eingeführt haben.

Verfügbare Front-Ends

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

DSU mit ADB starten

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

DSU mit einer App starten

Der Haupteinstiegspunkt für DSU ist die 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);
    }

Du musst diese App auf dem Gerät bündeln/vorinstallieren. Weil DynamicSystemClient ist eine System-API. Du kannst die App nicht mit der regulären API erstellen. SDK API verwenden und sie nicht bei Google Play veröffentlichen können. Zweck der App:

Image-Liste und entsprechende URL mit einem anbieterdefinierten Schema abrufen
Bilder in der Liste mit dem Gerät abgleichen und kompatible Bilder anzeigen die der Nutzer auswählen kann.

Rufen Sie DynamicSystemClient.start so auf:

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

Die URL verweist auf eine mit gzip komprimierte, nicht dünnbesetzte System-Image-Datei, die Sie mit den folgenden Befehlen:

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

Der Dateiname sollte folgendes Format haben:

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

Beispiele:

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

DSU-Ladeprogramm mit einem Klick

In Android 11 wird das DSU-Ladeprogramm mit nur einem Klick eingeführt, ist ein Frontend in den Entwicklereinstellungen.

Abbildung 1: DSU-Ladeprogramm starten

Wenn der Entwickler auf die Schaltfläche DSU Loader klickt, wird eine vorkonfigurierte DSU-JSON-Deskriptor aus dem Web und zeigt alle anwendbaren Bilder im unverankertes Menü. Wählen Sie ein Image zum Starten der DSU-Installation und den Fortschritt aus. in der Benachrichtigungsleiste angezeigt.

Fortschritt der DSU-Image-Installation

Abbildung 2: Fortschritt der DSU-Image-Installation

Standardmäßig lädt das DSU-Ladeprogramm einen JSON-Deskriptor, der die GSI-Bilder enthält. In den folgenden Abschnitten wird gezeigt, wie OEM-signierte DSU-Pakete erstellt und geladen werden. aus dem DSU-Ladeprogramm heraus.

Funktions-Flag

Die DSU-Funktion befindet sich unter dem Funktions-Flag settings_dynamic_android. Vorher mithilfe von DSU aktivieren, stellen Sie sicher, dass das entsprechende Funktions-Flag aktiviert ist.

Funktions-Flag wird aktiviert.

Abbildung 3: Funktions-Flag aktivieren

Die Benutzeroberfläche für Funktions-Flags ist auf einem Gerät, auf dem ein Nutzer-Build ausgeführt wird, möglicherweise nicht verfügbar. In Verwenden Sie in diesem Fall stattdessen den Befehl adb:

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

Anbieter-Hostsystem-Images in GCE (optional)

Einer der möglichen Speicherorte für die System-Images ist der Compute Engine-Bucket (GCE). Der Release-Administrator verwendet die GCP Storage Console zu das veröffentlichte System-Image hinzufügen, löschen oder ändern.

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

Öffentlicher Zugriff in GCE

Abbildung 4: Öffentlicher Zugriff in GCE

Wie Sie einen Artikel veröffentlichen, erfahren Sie in der Google Cloud-Dokumentation

DSU mit mehreren Partitionen in ZIP-Datei

Ab Android 11 kann DSU mehrere -Partition an. Zum Beispiel kann er neben dem Parameter product.img system.img. Beim Starten erkennt die erste Phase „init“ den DSU-Partitionen installiert und die Partition auf dem Gerät vorübergehend ersetzt, die installierte DSU aktiviert ist. Das DSU-Paket enthält möglicherweise eine Partition, eine entsprechende Partition auf dem Gerät haben.

DSU-Prozess mit mehreren Partitionen

Abbildung 5: DSU-Prozess mit mehreren Partitionen

Vom OEM unterzeichnete DSU

Um sicherzustellen, dass alle auf dem Gerät ausgeführten Images vom Gerät autorisiert sind Hersteller müssen alle Bilder in einem DSU-Paket signiert sein. Beispiel: Angenommen, es gibt ein DSU-Paket, das zwei Partitions-Images enthält:

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

Sowohl system.img als auch product.img müssen vom OEM-Schlüssel signiert werden, bevor sie in die ZIP-Datei. Häufig wird eine asymmetrische Methode Algorithmus, z. B. RSA, bei dem der geheime Schlüssel zum Signieren des Pakets und des der öffentliche Schlüssel zur Verifizierung verwendet wird. Die Ramdisk in der ersten Phase muss die Kopplung enthalten. öffentlichen Schlüssel, z. B. /avb/*.avbpubkey. Wenn das Gerät bereits AVB unterstützt, wird das vorhandenen Signaturvorgangs ausreichen. In den folgenden Abschnitten wird die des Signaturvorgangs und heben Sie die Platzierung des AVB-Pubkeys hervor, mit dem der die Bilder im DSU-Paket verifizieren.

DSU-JSON-Deskriptor

Der DSU-JSON-Deskriptor beschreibt DSU-Pakete. Es werden zwei Primitive unterstützt. Erstens enthält die include-Primitive zusätzliche JSON-Deskriptoren oder Weiterleitungen den DSU-Loader an einen neuen Speicherort zu übergeben. Beispiel:

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

Zweitens wird das Primitiv image verwendet, um freigegebene DSU-Pakete zu beschreiben. Innenansicht gibt es mehrere Attribute:

Die Attribute name und details sind Strings, die auf der Seite Dialogfeld, in dem der Nutzer auswählen kann.
Die Attribute cpu_api, vndk und os_version werden verwendet für Kompatibilitätsprüfungen, die im nächsten Abschnitt beschrieben werden.
Mit dem optionalen pubkey-Attribut wird -Schlüssel, der mit dem geheimen Schlüssel gekoppelt ist, der zum Signieren des DSU-Pakets verwendet wird. Wenn angegeben, kann der DSU-Dienst prüfen, ob das Gerät über den Schlüssel verfügt zur Verifizierung des DSU-Pakets verwendet wird. Dadurch wird die Installation einer nicht erkannten DSU vermieden. -Paket, beispielsweise die Installation einer von OEM-A signierten DSU auf einem Gerät des OEM-B.
Das optionale Attribut tos verweist auf eine Textdatei mit folgenden Informationen: die Nutzungsbedingungen für das entsprechende DSU-Paket. Wenn ein Entwickler ein DSU-Paket mit dem angegebenen Attribut für die Nutzungsbedingungen auswählt, das Das in Abbildung 6 gezeigte Dialogfeld wird geöffnet und der Entwickler wird aufgefordert, die Nutzungsbedingungen zu akzeptieren. bevor Sie das DSU-Paket installieren.

Abbildung 6: Dialogfeld mit den Nutzungsbedingungen

Hier ist ein DSU-JSON-Deskriptor für die GSI-Referenz:

{
   "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ätsverwaltung

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

cpu_api ist ein String, der die Gerätearchitektur beschreibt. Dieses Attribut ist obligatorisch und wird mit der Systemeigenschaft ro.product.cpu.abi verglichen. Die Werte müssen genau übereinstimmen.
os_version ist eine optionale Ganzzahl, die einen Android-Release angibt. Für Bei Android 10 ist os_version z. B. 10 und für Android 11: os_version ist 11. Wenn diese angegeben ist, muss es gleich oder größer als ro.system.build.version.release sein. Systemeigenschaften. Mit dieser Prüfung wird verhindert, dass ein GSI-Image von Android 10 auf einem Android 11 gestartet wird Anbietergerät, das derzeit nicht unterstützt wird. Das Starten eines GSI-Images für Android 11 auf einem Android 10-Gerät ist zulässig.
vndk ist ein optionales Array, das alle VNDKs angibt, die in das DSU-Paket. Wenn angegeben, prüft der DSU-Loader, ob die Zahl extrahiert aus der Systemeigenschaft ro.vndk.version ist enthalten.

DSU-Schlüssel aus Sicherheitsgründen widerrufen

Im äußerst seltenen Fall, dass das zum Signieren der DSU-Bilder verwendete RSA-Schlüsselpaar sollte die Ramdisk so schnell wie möglich aktualisiert werden, um die den manipulierten Schlüssel hat. Neben der Aktualisierung der Bootpartition können Sie kompromittierte Schlüssel mithilfe einer DSU-Schlüsselsperrliste (schwarze Liste der Schlüssel) von einem HTTPS- URL

Die DSU-Schlüsselsperrliste enthält eine Liste der widerrufenen öffentlichen AVB-Schlüssel. Während der DSU-Installation werden die öffentlichen Schlüssel in den DSU-Images validiert. mit der Sperrliste. Wenn die Bilder ein gesperrtes öffentliches Profil enthalten wird der DSU-Installationsvorgang angehalten.

Aus Sicherheitsgründen sollte die URL der Schlüsselsperrliste eine HTTPS-URL sein. und wird in einem Ressourcenstring angegeben:

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

Der Wert des Strings ist https://dl.google.com/developers/android/gsi/gsi-keyblacklist.json, das ist ein Sperrliste für von Google veröffentlichte GSI-Schlüssel. Dieser Ressourcenstring kann überlagert und angepasst, damit OEMs, die die DSU-Funktion übernehmen, eine eigene schwarze Liste führen. Dies bietet dem OEM die Möglichkeit, bestimmte öffentliche Schlüssel verwenden, 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 im beschriebenen Format. beim Generieren des AVB-Pubkeys .
status gibt den Widerrufsstatus des Schlüssels an. Derzeit ist die einzige unterstützter Wert ist REVOKED.
reason ist ein optionaler String, der den Grund für den Widerruf beschreibt.

DSU-Verfahren

In diesem Abschnitt wird beschrieben, wie mehrere DSU-Konfigurationsverfahren durchgeführt werden.

Neues Schlüsselpaar generieren

Verwenden Sie den Befehl openssl, um ein Paar aus privatem und öffentlichem RSA-Schlüssel in .pem zu generieren. Format (z. B. bei 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 Hardwaresicherheitsmodul (HSM). In diesem Fall ist nach dem Schlüssel möglicherweise ein x509-Zertifikat für den öffentlichen Schlüssel verfügbar. Generation. Weitere Informationen finden Sie im Abschnitt Kopplungs-Pubkey der Ramdisk hinzufügen. finden Sie eine Anleitung zum Generieren des öffentlichen AVB-Schlüssels aus einem x509-Zertifikat.

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.

Kopplungs-Pubkey der Ramdisk hinzufügen

Die oem_cert.avbpubkey muss auf /avb/*.avbpubkey gesetzt werden, um die signiertes DSU-Paket. Konvertiere zuerst den öffentlichen Schlüssel im PEM-Format in das öffentliche AVB-Format Schlüsselformat:

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

Füge dann den öffentlichen Schlüssel mit den folgenden Schritten in die Ramdisk der ersten Phase ein.

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

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)

Lege fest, dass das Droidcore-Ziel vom hinzugefügten oem_cert.avbpubkey abhängig ist:
```
droidcore: oem_cert.avbpubkey
```

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

oem_cert.avbpubkey liegt im AVB-Binärformat für den öffentlichen Schlüssel vor. SHA-1 für Folgendes verwenden: sie lesbar machen, bevor Sie sie in den JSON-Deskriptor einfügen:

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

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

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

DSU-Paket signieren

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

Methode 1: Artefakt wiederverwenden, das im ursprünglichen AVB-Signaturprozess erstellt wurde ein DSU-Paket zu erstellen. Alternativ können Sie das bereits unterschriebene und aus den extrahierten Bildern die ZIP-Datei zu erstellen. direkt in der Datei speichern.

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

$ 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 von add_hashtree_footer mit avbtool finden Sie unter avbtool verwenden.

DSU-Paket lokal bestätigen

Es wird empfohlen, alle lokalen Images anhand des öffentlichen Kopplungsschlüssels mit diese Befehle:


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

Ein DSU-Paket erstellen

Im folgenden Beispiel wird ein DSU-Paket erstellt, das eine system.img und einen product.img:

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

Nachdem beide Bilder signiert sind, erstellen Sie mit dem folgenden Befehl die ZIP-Datei:

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

Ein-Klick-DSU anpassen

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

OEMs können die Liste überschreiben, indem sie die persist.sys.fflag.override.settings_dynamic_system.list definieren die auf ihren eigenen JSON-Deskriptor verweist. Zum Beispiel kann ein OEM JSON-Metadaten bereitstellen, die GSI sowie proprietäre Bilder des OEMs 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 möglich, dass ein OEM veröffentlichte DSU-Metadaten verkettet, wie in Abbildung 7 dargestellt.

Verkettung veröffentlichter DSU-Metadaten

Abbildung 7: Verkettung veröffentlichter DSU-Metadaten