Android-Entwicklung
assetlinks.json einfügen, optional Paketname und SHA-256 des Signaturzertifikats angeben und die Prüfung starten.
assetlinks.json einfügen oder Beispiel laden.
Diese Schritte wurden lokal nicht getestet.
JSON, Paket und Zertifikatsfingerabdruck werden nur in diesem Tab geprüft; keine Domain wird kontaktiert.
assetlinks.json einfügen oder Beispiel laden.
Wenn ein App-Link im Browser landet, reicht gültiges JSON als Erklärung nicht aus. Android App-Links überprüfen heißt hier: Relation, Paketname und Zertifikatsfingerabdruck müssen in derselben Aussage zum selben Android-App-Ziel stehen.
Die lokale Prüfung hilft vor der Veröffentlichung und bei einem App-Link, der nicht funktioniert. Digital Asset Links validieren heißt dabei nicht, den Gerätestatus zu kennen: HTTP-Antwort und installierte Signatur bleiben eigene Prüfungen.
Eine passende Aussage ist etwas anderes als ein verifiziertes Gerät.
Beim Android App-Links überprüfen werden Paket und SHA-256 aus verschiedenen Aussagen nicht zusammengesetzt. Erst handle_all_urls, Paketname und Fingerabdruck innerhalb desselben android_app-Ziels ergeben einen lokalen Treffer.
Android App-Links überprüfen führt keine Netzabfrage aus. HTTPS, Pfad, JSON-MIME-Typ, Weiterleitungen, autoVerify im Manifest und Gerätestatus stehen deshalb als noch zu prüfende Punkte im Bericht.
Bei Play App Signing ist der SHA-256-Fingerabdruck des App-Signaturschlüssels aus der Play Console maßgeblich. Upload- und Debugschlüssel können abweichen. Das Eingabefeld akzeptiert auch 64 Hex-Zeichen ohne Doppelpunkte.
Die Prüfung startet nur auf Befehl, auch mit Strg/Cmd+Enter. Jede Änderung an JSON, Paket oder Fingerabdruck macht den alten Bericht ungültig und sperrt Kopieren und Download. JSON-Fehler zeigen Zeile und Spalte.
Gültige DAL-Struktur, Treffer in einer Aussage und tatsächliche Verifikation auf dem Gerät sind getrennt. include-Dateien bleiben unaufgelöst. Der vollständige Export enthält auch Einträge jenseits der 50 sichtbaren.
assetlinks.json prüfen umfasst das oberste Array, relation, android_app und web. Probleme werden mit Arrayindex und Feldpfad gemeldet; ein zulässiger include-Verweis wird nicht als kaputte Aussage ausgegeben.
Die erwartete Eingabe wird ohne Rücksicht auf Großschreibung und optionale Doppelpunkte verglichen. Im Dateitext wird das kanonische Format gesondert gemeldet; SHA-1 ist kein Fingerabdruck des geforderten Zertifikats.
Nur handle_all_urls kann die gesuchte App-Link-Zuordnung begründen. Andere Digital Asset Links-Relationen bleiben sichtbar, werden aber nicht als diese Berechtigung gewertet.
Den aktuellen JSON-Bericht kopieren oder herunterladen. Lange Listen erscheinen in 50er-Schritten, der Export enthält alle geprüften Aussagen und Befunde.
Auch eine lesbare Datei kann am falschen Host liegen, weiterleiten oder einen anderen Signaturschlüssel nennen. Android App-Links überprüfen grenzt lokale Aussagen ein; danach folgen Serverantwort, Manifest und Gerätestatus.
Ältere Versionen ignorieren dynamic_app_link_components. Für diese Geräte müssen benötigte Pfade auch im Manifest liegen. Teste die Zielversion; dieser Bericht simuliert keine Android-Version.
Ja, doch dynamische Regeln können den im Manifest festgelegten Geltungsbereich nicht erweitern. Hier wird die Erweiterung nur erkannt, nicht mit dem Manifest verrechnet.
Bei Play App Signing steht der SHA-256-Fingerabdruck des App-Signaturzertifikats in der Play Console. Für eigene Builds hilft keytool auf dem passenden Keystore. Gemeint ist nicht der Hash von assetlinks.json.
Das Gerät kann einen alten Stand zwischenspeichern; außerdem muss die neue Regel zum Manifest passen. Prüfe die öffentlich gelieferte Datei und starte mit adb shell pm verify-app-links --re-verify eine erneute Verifikation.
Stimmt ein Befund nicht?
Füge die geplante Aussage zum Android App-Links überprüfen ein, gleiche das App-Signaturzertifikat ab und arbeite danach die Server- und Geräteliste ab.
Eingaben bleiben in diesem Browser-Tab.