Selbst gehostetes TWA im "Soft Fail"-Zustand – Vollbild-UI funktioniert, aber native Delegation schlägt fehl

Unterstützung
1

Ich versuche, native Benachrichtigungen für eine TWA meiner selbst gehosteten Discourse-Site zum Laufen zu bringen, und bin auf einen sehr seltsamen „Soft Fail“ bei der Überprüfung von Digital Asset Links gestoßen.

Hier sind die genauen Symptome:

  1. Die App startet und läuft im Vollbildmodus ohne die URL-Leiste, was darauf hindeutet, dass der Asset-Link teilweise funktioniert.

  2. Es erscheint jedoch bei jedem Start eine Toast-Nachricht „Wird in Chrome ausgeführt“.

  3. Am wichtigsten ist, dass die PWA bei der Anforderung der Benachrichtigungsberechtigung den browserähnlichen Prompt anzeigt, nicht den nativen Android-Dialog. Dies beweist, dass die native API-Delegation fehlschlägt.

Dieses Verhalten ist auf allen Testgeräten (Android 12 & 13) und mit APKs, die sowohl von Bubblewrap als auch von Microsofts PWABuilder generiert wurden, konsistent.

Nach umfangreichem Debugging habe ich bestätigt, dass meine gesamte clientseitige und öffentlich zugängliche Serverkonfiguration perfekt zu sein scheint. Das Problem scheint ein subtiles serverseitiges Problem zu sein, das nur den Android-Validator betrifft.

Hier ist, was ich bereits überprüft habe:

  • Signierschlüssel & assetlinks.json: Mein android.keystore SHA-256-Fingerabdruck ist eine 100% exakte Übereinstimmung mit dem Fingerabdruck in meiner Live-Datei /.well-known/assetlinks.json.

  • Serverantwort: Mein Server liefert die assetlinks.json-URL mit einem 200 OK-Status, dem korrekten application/json Content-Type und keinen blockierenden CORS-Headern, wenn dies mit Standard-Webtools überprüft wird.

  • Android App-Konfiguration: Die generierte AndroidManifest.xml ist korrekt und enthält den Standard com.google.browserhelper.trusted.DelegationService.

  • Discourse Admin-Einstellungen: Meine Admin-Sicherheitseinstellungen für cors origins und Allowed crawler user agents sind beide leer.

Angesichts dieses spezifischen „Soft Fail“-Verhaltens lautet meine Frage:

Gibt es eine bekannte Nginx-Regel, eine Firewall-Einstellung oder ein subtiles Serverantwortproblem (wie eine leichte Verzögerung oder ein nicht standardmäßiger Header) in der Standard-Discourse-Selbsthost-Konfiguration, das dazu führen würde, dass der Android-Validator eine „Teilvertrauung“ gewährt (die Vollbild-UI zulässt), aber die für die native API-Delegation erforderliche höhere Vertrauensstufe verweigert?

Ich bin am Ende dessen, was von der Client-Seite aus diagnostiziert werden kann. Jede Einsicht in die tiefgreifende Serverkonfiguration wäre sehr willkommen.