Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Eine Anweisungsliste ist eine JSON-codierte Datei oder ein Snippet an einem bekannten Speicherort.
Speicherort der Erklärungsliste
Informationen dazu, wo diese Liste gespeichert werden sollte, finden Sie unter Erklärung erstellen.
Syntax
Die Erklärungsliste oder das Snippet besteht aus einem JSON-Array mit einer oder mehreren Website- oder App-Erklärungen als JSON-Objekte. Diese Anweisungen können in beliebiger Reihenfolge stehen. So sieht die allgemeine Syntax aus:
Ein Array mit einem oder mehreren Strings, die die Beziehung zum Ziel beschreiben. Liste der definierten BeziehungsstringsBeispiel:delegate_permission/common.handle_all_urls
Ziel
Das Ziel-Asset, auf das sich diese Aussage bezieht. Verfügbare Zieltypen:
URI der Website, die das Ziel der Anweisung ist, im Format http[s]://<hostname>[:<port>], wobei <hostname> vollqualifiziert ist und <port> weggelassen werden muss, wenn Port 80 für HTTP oder Port 443 für HTTPS verwendet wird. Ein Website-Ziel kann nur eine Stammdomain sein. Sie können es nicht auf ein bestimmtes Unterverzeichnis beschränken. Alle Verzeichnisse unter dieser Stammdomain werden berücksichtigt. Subdomains sollten nicht als Übereinstimmung betrachtet werden. Wenn die Erklärungsdatei also auf www.beispiel.de gehostet wird, sollte www.welpen.beispiel.de nicht als Übereinstimmung betrachtet werden. Regeln und Beispiele für den Abgleich von Website-Zielen finden Sie in der Dokumentation zu Zielen. Beispiel:http://www.example.com
Der vollständig qualifizierte Paketname der App, auf die sich diese Erklärung bezieht. Beispiel: com.google.android.apps.maps
sha256_cert_fingerprints
Der SHA256-Fingerabdruck in Großbuchstaben des Zertifikats für die App, auf die sich diese Anweisung bezieht. Sie können diesen Wert mit
openssl oder Java keytool berechnen, wie hier gezeigt:
Wenn Sie die Play App-Signatur für Ihre App verwenden, stimmt der Zertifikatsfingerabdruck, der durch lokales Ausführen von keytool oder openssl generiert wird, in der Regel nicht mit dem auf den Geräten der Nutzer überein. In Ihrem Play Console-Entwicklerkonto können Sie unter Release > Setup > App Integrity nachsehen, ob Sie die Play App-Signatur für Ihre App verwenden. Wenn dies der Fall ist, finden Sie auf derselben Seite auch den richtigen JSON-Snippet für Digital Asset Links für Ihre App.
relation_extensions (optional)
Sie können einer Erklärung ein optionales relation_extensions-Feld hinzufügen, um weitere Informationen zu den Berechtigungen und Verknüpfungen anzugeben, die Sie gewähren möchten. Dieses Feld sollte ein Objekt sein, in dem jeder Schlüssel ein Beziehungsstring ist und der Wert ein Objekt mit den Erweiterungen für diese Beziehung. Clients, die diese Erklärungen anfordern, müssen aktualisiert werden, damit diese Felder berücksichtigt werden.
relation_extensions für die Beziehung delegate_permission/common.handle_all_urls könnte beispielsweise so aussehen:
Die DAL API unterstützt die Rückgabe von „relation_extensions“ in API-Aufrufen, wenn der Parameter return_relation_extensions=true in der Anfrage festgelegt ist.
Auf Dutzende von Kontoauszügen oder mehr skalieren
In einigen Fällen möchte ein Rechtssubjekt möglicherweise viele verschiedene Erklärungen zu verschiedenen Zielen abgeben oder es ist erforderlich, Erklärungen von verschiedenen Rechtssubjekten an dieselben Ziele zu richten. Eine Website ist beispielsweise möglicherweise in vielen verschiedenen länderspezifischen Top-Level-Domains verfügbar und alle möchten eine Aussage zur selben mobilen App machen.
In diesen Fällen können Include-Anweisungen hilfreich sein.
Mit diesem Mechanismus können Sie Zeiger von vielen verschiedenen Principals auf einen zentralen Ort einrichten, an dem Anweisungen für alle Principals definiert werden.
Sie können beispielsweise festlegen, dass der zentrale Speicherort `https://example.com/includedstatements.json` sein soll. Diese Datei kann so konfiguriert werden, dass sie denselben Inhalt wie in den obigen Beispielen enthält.
Um einen Verweis von einer Website auf die Include-Datei einzurichten, ändern Sie `https://example.com/.well-known/assetlinks.json` in:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-09 (UTC)."],[[["\u003cp\u003eA statement list is a JSON file that describes relationships between websites and Android apps, used for features like Digital Asset Links.\u003c/p\u003e\n"],["\u003cp\u003eThe list consists of statements with "relation" and "target" fields, where "target" can be a website or an Android app.\u003c/p\u003e\n"],["\u003cp\u003eWebsite targets are specified using a "site" field with a URL, while Android app targets use "package_name" and "sha256_cert_fingerprints".\u003c/p\u003e\n"],["\u003cp\u003eFor many statements, use "include" to point to a central file to avoid redundancy and simplify management.\u003c/p\u003e\n"],["\u003cp\u003eDetailed syntax and examples are provided to guide you in creating and using statement lists effectively.\u003c/p\u003e\n"]]],[],null,["A statement list is a [JSON-encoded](http://json.org/) file or snippet in a well-known location.\n\nLocation of statement list\n\nSee [Creating a statement list](/digital-asset-links/v1/create-statement) to learn where this list should be stored.\n\nSyntax\n\nThe statement list or snippet consists of\na JSON array of one or more website or app statements as JSON objects. These statements can be in any order. Here is the general syntax: \n\n```\n[\n {\n \"relation\": [\"relation_string\"],\n \"target\": {target_object}\n } , ...\n]\n```\n\nrelation\n: An array of one or more strings that describe the relation being declared about the target. See the list of [defined relation strings](/digital-asset-links/v1/relation-strings). **Example:** `delegate_permission/common.handle_all_urls`\n\ntarget\n: The target asset to whom this statement applies. Available target types:\n\n - **Website target** \n\n ```javascript\n \"target\": {\n \"namespace\": \"web\",\n \"site\": \"\u003cvar translate=\"no\"\u003esite_root_url\u003c/var\u003e\"\n }\n ```\n\n namespace\n : Must be `web` for websites.\n\n site\n : URI of the site that is the target of the statement, in the format `http[s]://\u003c`\u003cvar translate=\"no\"\u003ehostname\u003c/var\u003e`\u003e[:\u003c`\u003cvar translate=\"no\"\u003eport\u003c/var\u003e`\u003e]`, where \u003cvar translate=\"no\"\u003e<hostname>\u003c/var\u003e is fully-qualified, and \u003cvar translate=\"no\"\u003e<port>\u003c/var\u003e must be omitted when using port 80 for HTTP, or port 443 for HTTPS. A website target can only be a root domain; you cannot limit to a specific subdirectory; all directories under this root will match. Subdomains should not be considered to match: that is, if the statement file is hosted on www.example.com, then www.puppies.example.com should not be considered a match. For rules and examples about website target matching, see [the targets documentation](/digital-asset-links/v1/create-statement#targets). **Example:** `http://www.example.com`\n - **Android app target** \n\n ```javascript\n \"target\": {\n \"namespace\": \"android_app\",\n \"package_name\": \"\u003cvar translate=\"no\"\u003efully_qualified_package_name\u003c/var\u003e\",\n \"sha256_cert_fingerprints\": [\"\u003cvar translate=\"no\"\u003ecert_fingerprint\u003c/var\u003e\"]\n }\n ```\n\n namespace\n : Must be `android_app` for Android apps.\n\n package_name\n : The fully-qualified package name of the app that this statement applies to. **Example:** `com.google.android.apps.maps`\n\n sha256_cert_fingerprints\n : The **uppercase SHA265 fingerprint** of the certificate for the app that this\n statement applies to. You can compute this using [`\n openssl`](https://www.openssl.org/) or Java `keytool` as shown here:\n - `openssl x509 -in $CERTFILE -noout -fingerprint -sha256`\n - `keytool -printcert -file $CERTFILE | grep SHA256`\n\n\n **Example:** `[\"14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5\"]`.\n\n If you're using [Play App Signing](https://support.google.com/googleplay/android-developer/answer/9842756)\n for your app, then the certificate fingerprint produced by running `keytool`\n or `openssl` locally usually doesn't match the one on\n users' devices. You can verify whether you're using Play App Signing for your app in your\n [Play Console](https://play.google.com/console/) developer account\n under **Release \\\u003e Setup \\\u003e App Integrity**; if you do,\n then you'll also find the correct Digital Asset Links JSON snippet for your app on the same\n page.\n\nrelation_extensions (optional)\n\n: You can add an optional `relation_extensions` field to a statement to provide more information on the permissions and associations you want to grant. This field should be an object where each key is a relation string, and the value is an object containing the extensions for that relation. Clients that request these statements need to be updated to respect these fields.\n\n For example, `relation_extensions` for the `delegate_permission/common.handle_all_urls` relation may look like: \n\n ```javascript\n {\n \"relation\": [\"delegate_permission/common.handle_all_urls\"],\n \"target\": {\n \"namespace\": \"android_app\",\n \"package_name\": \"com.example.app\",\n \"sha256_cert_fingerprints\": [\"...\"]\n },\n \"relation_extensions\": {\n \"delegate_permission/common.handle_all_urls\": {...}\n }\n }\n \n ```\n\n The DAL API supports returning relation_extensions in API calls when the `return_relation_extensions=true` parameter is set in the request.\n\nExample statement list\n\nHere is an example website statement list that contains statements about both websites and apps: \u003chttp://example.digitalassetlinks.org/.well-known/assetlinks.json\u003e\n\nScaling to dozens of statements or more\n\nIn some cases, a principal might want to make many different statements\nabout different targets, or there might be a need to issue statements from\ndifferent principals to the same set of targets. For example, a website may\nbe available on many different per-country Top Level Domains, and all of them\nmay want to make a statement about the same mobile app.\n\nFor these situations, **include statements** can be helpful.\nUsing this mechanism, you can set up pointers from many different principals to\none central location, which defines statements for all of the principals.\n| **Note:** A maximum of 10 include statements are allowed in a complete statement list tree. This means that the maximum number of files in the tree is: (10 included statement files) + (the root statement file) = 11 total.\n\nFor example, you might decide that the central location\nshould be \\`https://example.com/includedstatements.json\\`. This file can be\nconfigured to contain the same content as in the examples above.\n\nTo set up a pointer from a **web site** to the include file,\nchange \\`https://example.com/.well-known/assetlinks.json\\` to: \n\n```text\n[{\n \"include\": \"https://example.com/includedstatements.json\"\n}]\n```\n\nTo set up a pointer from an **Android app** to the include\nfile, change \\`res/values/strings.xml\\` to: \n\n```scdoc\n\u003cresources\u003e\n ...\n \u003cstring name=\"asset_statements\"\u003e\n [{\n \\\"include\\\": \\\"https://example.com/includedstatements.json\\\"\n }]\n \u003c/string\u003e\n\u003c/resources\u003e\n```\n\nMore Information\n\nThere is a more detailed explanation of the statement list format and the underlying concepts in our [specification document](https://github.com/google/digitalassetlinks/blob/master/well-known/details.md)."]]
