Informationen für Einsteiger
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Überblick
Mit dem Digital Asset Links-Protokoll und der Digital Asset Links API kann eine App oder Website öffentliche, überprüfbare Aussagen zu anderen Apps oder Websites machen. Für eine Website kann beispielsweise deklariert werden, dass sie mit einer bestimmten Android-App verknüpft ist, oder dass Nutzeranmeldedaten für eine andere Website freigegeben werden sollen.
Digital Asset Links können beispielsweise für folgende Zwecke eingesetzt werden:
- Für Website A wird deklariert, dass Links zu der zugehörigen Website auf Mobilgeräten in einer dafür vorgesehenen App geöffnet werden müssen, wenn die App installiert ist.
- Website A erklärt, dass sie ihre Chrome-Nutzeranmeldedaten an Website B weitergeben kann, damit sich der Nutzer nicht bei Website B anmelden muss, wenn er auf Website A angemeldet ist.
- App A deklariert, dass sie Geräteeinstellungen wie den Standort mit Website B teilen kann.
Wichtige Begriffe
- Hauptkonto: Das Hauptkonto ist die App oder Website, die die Aussage äußert. Bei Digital Asset Links ist das Hauptkonto immer die App oder Website, in der die Liste der Kontoauszüge gehostet wird.
- Anweisungsliste: Anweisungen sind in einer Anweisungsliste enthalten, die eine oder mehrere Anweisungen enthält. Eine Anweisungsliste ist im Klartext und öffentlich zugänglich. Sie befindet sich an einem Ort, der vom Hauptkonto kontrolliert wird und schwer zu fälschen oder zu manipulieren ist.
Dabei kann es sich um eine frei stehende Datei oder um Abschnitte eines anderen, größeren Artikels handeln. Auf einer Website ist es zum Beispiel eine ganze Datei, in einer Android-App ein Abschnitt im App-Manifest.
Die Kontoauszüge können von jedem auf unzulässige Weise angesehen und bestätigt werden. Weitere Informationen finden Sie in der Dokumentation zur Liste der Anweisungen.
- Anweisung : Eine Anweisung ist ein eng strukturiertes JSON-Konstrukt, das aus einer relation (die in der Anweisung vorgesehenen Aktionen, z. B. „Freigabe von Anmeldedaten aktivieren“) und einem relation (die Website oder App, auf die sich die Beziehung bezieht) besteht. Daher ist jede Anweisung wie ein Satz, in dem principal (Prinzipal) relation über target angibt.
- Anweisungsnutzer:Ein Anweisungsnutzer fordert eine Anweisungsliste von einem Hauptkonto an, prüft bei einem bestimmten Hauptkonto, ob eine Anweisung vorhanden ist, und kann die angegebene Aktion ausführen, sofern vorhanden. Weitere Informationen finden Sie in der Dokumentation.
Beispiel für eine schnelle Verwendung
Hier ein sehr vereinfachtes Beispiel dafür, wie Digital Asset Links für die Website www.beispiel.de verwendet werden können, um anzugeben, dass alle Links zu URLs auf dieser Website in einer dafür vorgesehenen App und nicht im Browser geöffnet werden sollen:
- Auf der Website www.beispiel.de wird unter https://www.beispiel.de/.well-known/assetlinks.json eine Anweisungsliste veröffentlicht. Dies ist der offizielle Name und die Stelle für eine Anweisungsliste auf einer Website. Anweisungslisten an einem anderen Ort oder unter einem anderen Namen sind für diese Website nicht gültig. In unserem Beispiel besteht die Anweisungsliste aus einer Anweisung, mit der der Android-App die Berechtigung erteilt wird, Links auf der zugehörigen Website zu öffnen:
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target" : { "namespace": "android_app", "package_name": "com.example.app",
"sha256_cert_fingerprints": ["hash_of_app_certificate"] }
}]
Eine Anweisungsliste unterstützt ein Array von Anweisungen innerhalb der Zeichen [ ]. Unsere Beispieldatei enthält jedoch nur eine Anweisung.
sha256_cert_fingerprints ist der SHA256-Fingerabdruck des Signaturzertifikats Ihrer App.
Weitere Informationen finden Sie in der Dokumentation zu Android-App-Links.
- Die in der obigen Anweisung aufgeführte Android-App hat einen Intent-Filter, der das Schema, den Host und das Pfadmuster der URLs angibt, die verarbeitet werden sollen: in diesem Fall https://www.beispiel.de. Der Intent-Filter enthält das spezielle Attribut
android:autoVerify, das neu für Android M ist. Es gibt an, dass Android die Anweisung auf der im Intent-Filter beschriebenen Website überprüfen soll, wenn die App installiert wird.
- Ein Nutzer installiert die Anwendung. Android sieht den Intent-Filter mit dem Attribut
autoVerify und prüft, ob die Anweisungsliste auf der angegebenen Website vorhanden ist. Falls vorhanden, prüft Android, ob die Datei eine Anweisung enthält, die eine Linkverarbeitung für die Anwendung gewährt, und überprüft die Anwendung anhand der Anweisung anhand eines Zertifikats-Hashs. Wenn alles in Ordnung ist, leitet Android alle https://www.example.com Intents an die example.com-App weiter.
- Der Nutzer klickt auf seinem Gerät auf einen Link zu https://www.example.com/welpen. Dieser Link kann sich an einer beliebigen Stelle befinden: in einem Browser, in einem Vorschlag der Google Search Appliance oder an einem anderen Ort. Android leitet den Intent an die Anwendung „example.com“ weiter.
- Die App „example.com“ empfängt den Intent und versucht, ihn zu verarbeiten. Dabei wird die Seite „Welpen“ in der App geöffnet. Wenn die App die Verarbeitung des Links abgelehnt hat oder die App nicht auf dem Gerät installiert war, wurde der Link an den nächsten Standard-Intent-Handler gesendet, der diesem Intent-Muster (häufig dem Browser) entspricht.
Wichtige Hinweise und Einschränkungen:
- Das Protokoll authentifiziert das Hauptkonto, das die Anweisung tätigt, nicht, aber die Anweisung befindet sich an einem bestimmten Ort, der eng mit dem Hauptkonto verbunden ist und unter der Kontrolle des Hauptkontos steht.
- Das Protokoll authentifiziert das Anweisungsziel nicht, aber es ermöglicht dem Aufrufer, das Ziel zu authentifizieren. Eine Anweisung identifiziert beispielsweise Ziele mobiler Apps anhand des Zertifikats-Hashs und des Paketnamens.
- Das Protokoll führt nativ keine Anweisungsaktionen aus. Es ermöglicht vielmehr die Offenlegung von Anweisungen, die eine verarbeitende Anwendung validieren und dann entscheiden muss, ob und wie damit zu handeln. Android M führt diese Schritte nativ für Sie aus. Wenn eine Website beispielsweise die Linkverarbeitung an eine bestimmte App delegiert, prüft und verifiziert Android die Anweisung, verifiziert die Ziel-App und bietet der App dann die Option, den angegebenen Link zu verarbeiten.
- Das Protokoll ermöglicht keine Aussagen über zwei Dritte. Das heißt, Website A kann keine Aussagen über Website B treffen, Website A jedoch keine Aussagen über die Beziehung von Website B zu Website C. Wenn Website B jedoch Website A vertraut, kann sie für Website A nach einer Erklärung suchen, die die Berechtigung für Website C erteilt, und dann entscheiden, diese zu implementieren.
Nächste Schritte
- Prüfen Sie, ob es eine explizite Dokumentation für Ihren Anwendungsfall gibt.
- Weitere Informationen zum Erstellen einer Aussage
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2024-06-26 (UTC).
[null,null,["Zuletzt aktualisiert: 2024-06-26 (UTC)."],[[["\u003cp\u003eDigital Asset Links enable apps and websites to make verifiable statements about their relationships with other apps and websites, such as link handling or credential sharing.\u003c/p\u003e\n"],["\u003cp\u003eThese statements are stored in a publicly accessible statement list, typically an "assetlinks.json" file hosted by the app or website making the statement.\u003c/p\u003e\n"],["\u003cp\u003eAndroid M and above automatically uses Digital Asset Links to verify website-to-app associations and direct links to the appropriate app if installed.\u003c/p\u003e\n"],["\u003cp\u003eThe protocol provides a foundation for trust and delegation between digital entities but relies on consumers to validate and act upon the statements.\u003c/p\u003e\n"]]],[],null,["# Getting Started\n\nOverview\n--------\n\nThe Digital Asset Links protocol and API enable an app or website to make public,\nverifiable *statements* about other apps or websites. For example, a website\ncan declare that it is associated with a specific Android app, or it can declare that\nit wants to share user credentials with another website.\n\nHere are some possible uses for Digital Asset Links:\n\n- Website A declares that links to its site should open in a designated app on mobile devices, if the app is installed.\n- Website A declares that it can share its Chrome user credentials with website B so that the user won't have to log in to website B if it is logged into website A.\n- App A declares that it can share device settings, such as location, with website B.\n\n### Key terms\n\n- **Principal:** The principal is the app or website making the statement. In Digital Asset Links, the principal is always the app or website that hosts the statement list.\n- **Statement list** : Statements are contained in a *statement list* that contains one or more statements. A statement list is cleartext and publicly accessible, in a location that is controlled by the principal and difficult to spoof or tamper with. It can be a free-standing file, or a section of another, larger item. For example, on a website, it is an entire file; in an Android app, it is a section in the app manifest. Statements can be viewed and verified by anyone, using non-proprietary methods. [See the statement list documentation for more information](/digital-asset-links/v1/create-statement).\n- **Statement:** A statement is a tightly structured JSON construct that consists of a *relation* (what the statement says to do, for example: Enable sharing credentials) and a *target* (the website or app that the relation applies to). Therefore, each statement is like a sentence, where *principal* says *relation* about *target* . \n- **Statement consumer:** A statement consumer requests a statement list from a principal, checks for the presence of a statement against a given principal, and if it exists, can perform the action specified. [See the statement comsuming documentation for more information](/digital-asset-links/v1/consuming)*.*\n\nQuick usage example\n-------------------\n\nHere's a very simplified example of how the website www.example.com could\nuse Digital Asset Links to specify that any links to URLs in that site should\nopen in a designated app rather than the browser:\n\n1. The website www.example.com publishes a statement list at https://www.example.com/.well-known/assetlinks.json. This is the official name and location for a statement list on a site; statement lists in any other location, or with any other name, are not valid for this site. In our example, the statement list consists of one statement, granting its Android app the permission to open links on its site: \n\n ```\n [{\n \"relation\": [\"delegate_permission/common.handle_all_urls\"],\n \"target\" : { \"namespace\": \"android_app\", \"package_name\": \"com.example.app\",\n \"sha256_cert_fingerprints\": [\"hash_of_app_certificate\"] }\n }]\n ```\n A statement list supports an array of statements within the \\[ \\] marks, but our example file contains only one statement. `sha256_cert_fingerprints` is the SHA256 fingerprints of your app's signing certificate. Find more details in the [Android App Links documentation](https://developer.android.com/training/app-links/verify-android-applinks#web-assoc).\n2. The Android app listed in the statement above has an intent filter that specifies the scheme, host, and path pattern of URLs that it wants to handle: in this case, https://www.example.com. The intent filter includes a special attribute `android:autoVerify`, new to Android M, which indicates that Android should verify the statement on the website described in the intent filter when the app is installed.\n3. A user installs the app. Android sees the intent filter with the `autoVerify` attribute and checks for the presence of the statement list at the specified site; if present, Android checks whether that file includes a statement granting link handling to the app, and verifies the app against the statement by certificate hash. If everything checks out, Android will then forward any https://www.example.com intents to the example.com app.\n4. The user clicks a link to https://www.example.com/puppies on their device. This link could be anywhere: in a browser, in a Google Search Appliance suggestion, or anywhere else. Android forwards the intent to the example.com app.\n5. The example.com app receives the intent and chooses to handle it, opening the puppies page in the app. If for some reason the app had declined to handle the link, or if the app were not on the device, then the link would have been sent to the next default intent handler matching that intent pattern (often the browser).\n\nImportant considerations and limitations:\n-----------------------------------------\n\n- The protocol does not authenticate the principal making the statement, but the statement is located in a specific location strongly associated with the principal, and under control of the principal.\n- The protocol does not authenticate the statement target, but it provides a means for the caller to authenticate the target (for example, a statement identifies mobile app targets by certificate hash and package name).\n- The protocol does not natively perform any statement actions; rather, it enables the ability to expose statements, which a consuming application must validate and then decide whether and how to act upon. Android M natively performs these steps for you; for example, if a website delegates link handling to a specific app, Android checks and verifies the statement, verifies the target app, and then offers the app the option to handle the given link.\n- The protocol does not enable making statements about two third parties: that is, website A can make a statement about website B, but website A cannot make a statement about website B's relationship to website C. However, if website B trusts website A, it can check website A for a statement granting permission to website C, and decide to implement that.\n\nNext steps\n----------\n\n1. [See if there is explicit documentation for your use case.](/digital-asset-links/v1/using)\n2. [Learn about creating a statement.](/digital-asset-links/v1/create-statement)"]]
