Mit dynamischen Systemupdates (DSU) können Sie ein Android-System-Image erstellen, das Nutzer aus dem Internet herunterladen und ausprobieren können, ohne das Risiko, das aktuelle System-Image zu beschädigen. In diesem Dokument wird beschrieben, wie Sie DSU unterstützen.
Kernelanforderungen
Informationen zu den Kernel-Anforderungen finden Sie unter Dynamische Partitionen implementieren.
Darüber hinaus stützt sich DSU auf die Kernelfunktion „device-mapper-verity“ (dm-verity), um das Android-System-Image zu prüfen. Sie müssen daher die folgenden Kernelkonfigurationen aktivieren:
CONFIG_DM_VERITY=yCONFIG_DM_VERITY_FEC=y
Anforderungen an Partitionen
Ab Android 11 muss die /data-Partition das Dateisystem F2FS oder ext4 verwenden. F2FS bietet eine bessere Leistung und wird empfohlen, aber der Unterschied sollte nicht signifikant sein.
Hier sind einige Beispiele dafür, wie lange ein dynamisches Systemupdate auf einem Pixel-Gerät dauert:
- Mit F2FS:
- 109 Sekunden, 8 GB Nutzer, 867 MB System, Dateisystemtyp: F2FS: encryption=aes-256-xts:aes-256-cts
- 104 s, 8 G Nutzer, 867 M System, Dateisystemtyp: F2FS: encryption=ice
- Mit ext4:
- 135 Sekunden, 8 GB Nutzer, 867 MB 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 Bereitstellungsflag ein Flag enthält, das das Schreiben von „sync“ ermöglicht. Sie können auch explizit ein „async“-Flag angeben, um eine bessere Leistung zu erzielen.
Die Partition metadata (16 MB oder größer) ist zum Speichern von Daten im Zusammenhang mit den installierten Images erforderlich. Sie muss während der ersten Bereitstellung bereitgestellt werden.
Die Partition userdata muss das Dateisystem F2FS oder ext4 verwenden. Wenn Sie F2FS verwenden, müssen Sie alle F2FS-bezogenen Patches einschließen, die im Android Common Kernel verfügbar sind.
DSU wurde mit kernel/common 4.9 entwickelt und getestet. Für diese Funktion wird die Verwendung von Kernel 4.9 oder höher empfohlen.
HAL-Verhalten des Anbieters
Weaver HAL
Die Weaver HAL bietet eine feste Anzahl von Slots zum Speichern von Nutzerschlüsseln. Die DSU verbraucht zwei zusätzliche Schlüsselslots. Wenn ein OEM einen Weaver-HAL hat, muss er genügend Slots für ein generisches System-Image (GSI) und ein Host-Image haben.
Gatekeeper HAL
Die Gatekeeper HAL muss große USER_ID-Werte unterstützen, da die GSI UIDs in der HAL um + 1.000.000 verschiebt.
Start prüfen
Wenn Sie das Booten von GSI-Images von Entwicklern im GESPERRTEN Zustand unterstützen möchten, ohne den sicheren Start zu deaktivieren, fügen Sie GSI-Schlüssel von Entwicklern hinzu. Fügen Sie dazu der Datei device/<device_name>/device.mk die folgende Zeile hinzu:
$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)
Rollback-Schutz
Bei Verwendung von DSU muss das heruntergeladene Android-Systemimage neuer als das aktuelle Systemimage auf dem Gerät sein. Dazu werden die Sicherheitspatch-Ebenen im verifizierten Android-Boot-Modus (AVB) AVB-Attributdeskriptor von beiden System-Images verglichen: Prop: com.android.build.system.security_patch ->
'2019-04-05'.
Bei Geräten, die AVB nicht verwenden, geben Sie die Sicherheitspatchebene des aktuellen System-Images in die Kernel-Befehlszeile oder die Boot-Konfiguration mit dem Bootloader 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 bis 1,5 G) - Eine leere 8-GB-
/data-Partition als Sandbox für die Ausführung der GSI
Wir empfehlen, vor dem Starten einer DSU-Instanz mindestens 10 GB freien Speicherplatz zu reservieren. DSU unterstützt auch die Zuweisung von einer SD-Karte. Wenn eine SD-Karte vorhanden ist, hat sie für die Zuweisung die höchste Priorität. Die Unterstützung von SD-Karten ist für Geräte mit geringerer Leistung, die möglicherweise nicht genügend internen Speicher haben, entscheidend. Falls eine SD-Karte vorhanden ist, vergewissern Sie sich, dass sie nicht verwendet wird. DSU unterstützt keine adoptierten SD-Karten.
Verfügbare Front-Ends
Sie können die DSU über adb, eine OEM-App oder den DSU-Ladeprogramm mit nur einem Klick (unter Android 11 oder höher) starten.
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 über eine 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);
}
Sie müssen diese App auf dem Gerät bündeln oder vorinstallieren. Da DynamicSystemClient eine System-API ist, können Sie die App nicht mit der regulären SDK-API erstellen und nicht bei Google Play veröffentlichen. Zweck der App:
- Bildliste und zugehörige URL mit einem vom Anbieter definierten Schema abrufen
- Gleichen Sie die Bilder in der Liste mit dem Gerät ab und zeigen Sie dem Nutzer kompatible Bilder an, aus denen er sie auswählen kann.
So rufen Sie
DynamicSystemClient.startauf: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-Imagedatei, 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 muss folgendermaßen formatiert sein:
<android version>.<lunch name>.<user defined title>.raw.gz
Beispiele:
o.aosp_taimen-userdebug.2018dev.raw.gzp.aosp_taimen-userdebug.2018dev.raw.gz
DSU-Ladeprogramm mit nur einem Klick
In Android 11 wird das DSU-Ladeprogramm mit einem Klick eingeführt, das ein Front-End in den Entwicklereinstellungen ist.
Abbildung 1: DSU-Ladeprogramm starten
Wenn der Entwickler auf die Schaltfläche DSU-Ladeprogramm klickt, wird ein vorkonfigurierter DSU-JSON-Beschreibungsblock aus dem Web abgerufen und alle entsprechenden Bilder werden im schwebenden Menü angezeigt. Wählen Sie ein Image aus, um die DSU-Installation zu starten. Der Fortschritt wird in der Benachrichtigungsleiste angezeigt.
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 Sie vom OEM signierte DSU-Pakete erstellen und über den DSU-Ladeprogramm laden.
Funktions-Flag
Die DSU-Funktion ist unter dem Funktions-Flag settings_dynamic_android verfügbar. Achten Sie vor der Verwendung von DSU darauf, dass das entsprechende Funktions-Flag aktiviert ist.
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. Verwenden Sie in diesem Fall stattdessen den Befehl adb:
$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1
Anbieterhost-System-Images in GCE (optional)
Einer der möglichen Speicherorte für die System-Images ist der Google Compute Engine-Bucket (GCE). Der Release-Administrator verwendet die GCP Storage Console, um das veröffentlichte System-Image hinzuzufügen, zu löschen oder zu ändern.
Die Images müssen wie hier gezeigt öffentlich zugänglich sein:
Abbildung 4 Öffentlicher Zugriff in GCE
Wie Sie ein Element veröffentlichen, erfahren Sie in der Google Cloud-Dokumentation.
DSU mit mehreren Partitionen in ZIP-Datei
Ab Android 11 kann die DSU mehr als eine Partition haben. Es kann beispielsweise zusätzlich zum system.img ein product.img enthalten. Beim Starten des Geräts erkennt die erste Phase init die installierten DSU-Partitionen und ersetzt vorübergehend die Partition auf dem Gerät, wenn die installierte DSU aktiviert ist. Das DSU-Paket kann eine Partition enthalten, die keine entsprechende Partition auf dem Gerät hat.
Abbildung 5: DSU-Prozess mit mehreren Partitionen
Vom OEM signierte DSU
Damit alle auf dem Gerät ausgeführten Images vom Gerätehersteller autorisiert sind, müssen alle Images in einem DSU-Paket signiert sein. 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 aufgenommen werden. Es ist üblich, einen asymmetrischen Algorithmus zu verwenden, z. B. RSA, bei dem das Paket mit dem geheimen Schlüssel signiert und mit dem öffentlichen Schlüssel verifiziert wird. Die Ramdisk in der ersten Phase muss den öffentlichen Kopplungsschlüssel enthalten, z. B. /avb/*.avbpubkey. Wenn das Gerät bereits AVB verwendet, reicht das vorhandene Signaturverfahren aus. In den folgenden Abschnitten wird der Signaturvorgang veranschaulicht. Außerdem wird die Platzierung des AVB-Pubkeys erläutert, mit dem die Bilder im DSU-Paket verifiziert werden.
DSU-JSON-Deskriptor
Der DSU-JSON-Deskriptor beschreibt DSU-Pakete. Es werden zwei Primitive unterstützt.
Erstens enthält der include-Primitive zusätzliche JSON-Deskriptoren oder leitet den DSU-Loader an einen neuen Speicherort weiter. Beispiel:
{
"include": ["https://.../gsi-release/gsi-src.json"]
}
Zweitens wird das image-Primitive verwendet, um veröffentlichte DSU-Pakete zu beschreiben. Das Bildprimitiv enthält mehrere Attribute:
Die Attribute
nameunddetailssind Strings, die im Dialogfeld angezeigt werden, damit der Nutzer sie auswählen kann.Die Attribute
cpu_api,vndkundos_versionwerden für Kompatibilitätsprüfungen verwendet, die im nächsten Abschnitt beschrieben werden.Das optionale Attribut
pubkeybeschreibt den öffentlichen Schlüssel, der mit dem geheimen Schlüssel gekoppelt ist, der zum Signieren des DSU-Pakets verwendet wird. Wenn er angegeben ist, kann der DSU-Dienst prüfen, ob sich auf dem Gerät der Schlüssel befindet, der zum Verifizieren des DSU-Pakets verwendet wird. So wird verhindert, dass ein nicht erkanntes DSU-Paket installiert wird, z. B. eine von OEM A signierte DSU auf einem Gerät von OEM B.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 Attribut „Nutzungsbedingungen“ auswählt, wird das in Abbildung 6 gezeigte Dialogfeld geöffnet. Darin wird der Entwickler aufgefordert, die Nutzungsbedingungen zu akzeptieren, bevor er das DSU-Paket installieren kann.
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
Mit mehreren Attributen wird die Kompatibilität zwischen einem DSU-Paket und dem lokalen Gerät angegeben:
cpu_apiist ein String, der die Gerätearchitektur beschreibt. Dieses Attribut ist obligatorisch und wird mit dem Systemattributro.product.cpu.abiverglichen. Die Werte müssen genau übereinstimmen.os_versionist eine optionale Ganzzahl, die einen Android-Release angibt. Beispiel: Für Android 10 istos_version=10und für Android 11 istos_version=11. Wenn dieses Attribut angegeben ist, muss es gleich oder größer als das Systemattributro.system.build.version.releasesein. Mit dieser Prüfung wird verhindert, dass ein Android 10-GSI-Image auf einem Android 11-Gerät eines Anbieters gestartet wird, was derzeit nicht unterstützt wird. Das Starten eines GSI-Images für Android 11 auf einem Android 10-Gerät ist zulässig.vndkist ein optionales Array, das alle im DSU-Paket enthaltenen VNDKs angibt. Wenn angegeben, prüft das DSU-Ladeprogramm, ob die aus dem Systemattributro.vndk.versionextrahierte Zahl enthalten ist.
DSU-Schlüssel aus Sicherheitsgründen widerrufen
Im extrem seltenen Fall, dass das zum Signieren der DSU-Images verwendete RSA-Schlüsselpaar kompromittiert ist, sollte die Ramdisk so schnell wie möglich aktualisiert werden, um den manipulierten Schlüssel zu entfernen. Neben dem Aktualisieren der Bootpartition können Sie manipulierte Schlüssel mithilfe einer DSU-Schlüsselsperrliste (schwarze Liste für Schlüssel) über eine 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 anhand der Widerrufsliste überprüft. Wenn die Images einen widerrufenen öffentlichen Schlüssel enthalten, wird die DSU-Installation beendet.
Die URL der Schlüsselentzugsliste muss eine HTTPS-URL sein, um die Sicherheit zu gewährleisten. Sie 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, eine Widerrufsliste für von Google veröffentlichte GSI-Schlüssel. Dieser Ressourcenstring kann überlagert und angepasst werden, sodass OEMs, die die DSU-Funktion verwenden, ihre eigene Schlüssel-Sperrliste bereitstellen und verwalten können. Dadurch kann der OEM bestimmte öffentliche Schlüssel blockieren, ohne das Ramdisk-Image des Geräts zu aktualisieren.
Das Format der Widerrufsliste lautet:
{
"entries":[
{
"public_key":"bf14e439d1acf231095c4109f94f00fc473148e6",
"status":"REVOKED",
"reason":"Key revocation test key"
},
{
"public_key":"d199b2f29f3dc224cca778a7544ea89470cbef46",
"status":"REVOKED",
"reason":"Key revocation test key"
}
]
}
public_keyist der SHA-1-Digest des widerrufenen Schlüssels im Format, das im Abschnitt AVB-öffentlichen Schlüssel generieren beschrieben wird.statusgibt den Widerrufsstatus des Schlüssels an. Derzeit istREVOKEDder einzige unterstützte Wert.reasonist 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
Mit dem Befehl openssl können Sie ein RSA-Schlüsselpaar im .pem-Format generieren (z. B. mit einer Größe von 2.048 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 Security Module (HSM) aufbewahrt. In diesem Fall ist nach der Schlüsselgenerierung möglicherweise ein x509-Zertifikat für den öffentlichen Schlüssel verfügbar. Eine Anleitung zum Generieren des AVB-Public-Keys aus einem X509-Zertifikat finden Sie im Abschnitt Dem RAM-Disk den Pairing-Public-Key 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.
Kopplungs-Pubkey der Ramdisk hinzufügen
Das oem_cert.avbpubkey muss unter /avb/*.avbpubkey platziert werden, um das signierte DSU-Paket zu überprüfen. Konvertieren Sie zuerst den öffentlichen Schlüssel im PEM-Format in das AVB-Format für öffentliche Schlüssel:
$ 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 vorgefertigtes Modul hinzu, um die
avbpubkeyzu kopieren. Fügen Sie beispielsweisedevice/<company>/<board>/oem_cert.avbpubkeyunddevice/<company>/<board>/avb/Android.mkmit folgendem Inhalt 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)Lege fest, dass das Droidcore-Ziel vom hinzugefügten
oem_cert.avbpubkeyabhängig ist:droidcore: oem_cert.avbpubkey
Generieren Sie das AVB-pubkey-Attribut im JSON-Deskriptor.
Die oem_cert.avbpubkey ist im Binärformat des AVB-öffentlichen Schlüssels. Verwenden Sie SHA-1, um sie lesbar zu machen, bevor Sie sie in den JSON-Deskriptor einfügen:
$ sha1sum oem_cert.avbpubkey | cut -f1 -d ' '
3e62f2be9d9d813ef5........866ac72a51fd20
Das ist der Inhalt des Attributs pubkey des JSON-Beschreibungsobjekts.
"images":[
{
...
"pubkey":"3e62f2be9d9d813ef5........866ac72a51fd20",
...
},
DSU-Paket signieren
Verwenden Sie eine der folgenden Methoden, um ein DSU-Paket zu signieren:
Methode 1: Das Artefakt, das durch den ursprünglichen AVB-Signaturvorgang erstellt wurde, wiederverwenden, um ein DSU-Paket zu erstellen. Alternativ können Sie die bereits signierten Images aus dem Release-Paket extrahieren und die ZIP-Datei direkt mit den extrahierten Images erstellen.
Methode 2: Verwenden Sie die folgenden Befehle, um DSU-Partitionen zu signieren, wenn der private Schlüssel verfügbar ist. Jede
imgin einem DSU-Paket (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 von add_hashtree_footer mit avbtool finden Sie unter avbtool verwenden.
DSU-Paket lokal prüfen
Es wird empfohlen, mit den folgenden Befehlen alle lokalen Images anhand des öffentlichen Kopplungsschlüssels zu vergleichen:
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
DSU-Paket erstellen
Im folgenden Beispiel wird ein DSU-Paket erstellt, das eine system.img und eine product.img enthält:
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 -
DSU mit nur einem Klick anpassen
Standardmäßig verweist das DSU-Ladeprogramm auf die Metadaten von GSI-Bildern, nämlich https://...google.com/.../gsi-src.json.
OEMs können die Liste überschreiben, indem sie das Attribut persist.sys.fflag.override.settings_dynamic_system.list definieren, das auf ihren eigenen JSON-Deskriptor verweist. Ein OEM kann beispielsweise JSON-Metadaten bereitstellen, die GSI sowie proprietäre Bilder des OEMs wie die folgenden 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.
Abbildung 7: Verkettung veröffentlichter DSU-Metadaten