iOS / Android Dev Tools
Fügen Sie die AASA-Datei und mehrere URLs ein; eine App-ID kann optional filtern. Es erfolgt keine Anfrage an die Domain.
Bearbeiten Sie das Beispiel und starten Sie die Prüfung.
Die Prüfung läuft in diesem Browsertab. Eingegebene Domains und URLs werden nicht abgerufen.
Leer lassen für alle deklarierten App-IDs; sonst muss die ID exakt übereinstimmen.
Bearbeiten Sie das Beispiel und starten Sie die Prüfung.
Wenn nur manche Links die App öffnen, zeigt der AASA Validator vor der Veröffentlichung, welche Regel den Pfad zuerst erfasst. Eine reine JSON-Prüfung erklärt nicht, warum ein späterer Ausschluss wirkungslos bleibt.
Dieser AASA Validator wertet den eingefügten Text aus und nennt App-ID und Regelnummer. Serverantwort, Apple-CDN-Cache und Verhalten einer installierten App müssen anschließend getrennt geprüft werden.
Der AASA Validator führt mehrere URLs durch dieselbe Regelreihenfolge und unterscheidet zugelassen, ausgeschlossen und ohne Treffer. Ein falsch gewählter Pfad fällt schon vor dem Deployment auf.
Eine breite Regel kann vor einem späteren Ausschluss gewinnen. Der AASA Validator nennt die entscheidende Regel und warnt vor offensichtlich verdeckten Einträgen.
Fügen Sie das ganze JSON mit applinks.details ein. Das Beispiel verwendet appIDs und components; ältere appID- und paths-Einträge funktionieren ebenfalls. Syntaxfehler nennen Zeile und Spalte. So können Sie die AASA Datei überprüfen.
Eine HTTPS-URL oder einen mit Schrägstrich beginnenden Pfad pro Zeile eingeben. Ein leeres App-ID-Feld prüft alle deklarierten Apps; nach jeder Änderung ist der alte Bericht veraltet.
Lesen Sie Details- und Regelnummer vor dem Export. Ein lokaler Treffer bedeutet nur, dass die eingefügten Regeln eine App wählen; die Deployment-Punkte bleiben ungeprüft.
components berücksichtigt Pfad, Abfrage, Fragment und exclude; ältere paths verarbeiten NOT in Reihenfolge. Der Universal-Link-Test vermischt die Formate nicht. Damit lassen sich Pfadregeln testen.
Vergleichen Sie dieselbe URL mit allen deklarierten IDs oder filtern Sie genau eine. Eine nicht deklarierte ID erscheint anders als ein Pfad ohne Treffer.
Der AASA Validator exportiert Strukturhinweise, Eingabezeilen, Regelnummern und die noch ungeprüften Deployment-Punkte als JSON.
Der AASA Validator beurteilt nur die eingefügten Regeln. Hosting, CDN, Associated Domains, Installation und der Ort des Klicks beeinflussen iOS ebenfalls. Prüfen Sie die Liste und testen Sie am Gerät.
Unter /.well-known/apple-app-site-association oder am Root derselben Domain, ohne Dateiendung und ohne Weiterleitung. Ob Ihr Server das tatsächlich so liefert, bleibt hier ungeprüft.
Geben Sie die konkrete URL ein. Der Bericht nennt die erste entscheidende Regel; ein vorangestelltes NOT kann ausschließen, während ein früheres * spätere Regeln verdeckt.
Nein. Dafür wäre eine Anfrage an den Server nötig. Die lokale Prüfung liest nur den eingefügten Text; Weiterleitungen stehen in der Deployment-Liste als ungeprüft.
Für konkrete Hosts müssen Associated Domains und die dort bereitgestellte Datei zusammenpassen. Wildcard-Domains haben eigene Regeln; prüfen Sie die Host-Konfiguration anhand der Apple-Dokumentation. Dieser Modus prüft keine Domain.
Ist noch eine Regel unklar?
Testen Sie eine reale URL mit der gewünschten App-ID und übernehmen Sie die ungeprüften Serverpunkte in die Freigabe.