Zelf gehoste TWA in "Soft Fail"-status - Volledig scherm UI werkt, maar native delegatie mislukt

Ondersteuning
1

Ik probeer systeemeigen meldingen werkend te krijgen voor een TWA van mijn zelf-gehoste Discourse-site en ben tegen een zeer vreemde “soft fail” met de Digital Asset Link-verificatie aangelopen.

Hier zijn de exacte symptomen:

  1. De app start en draait volledig scherm zonder de URL-balk, wat suggereert dat de asset link gedeeltelijk werkt.

  2. Er verschijnt echter een “Running in Chrome” toastbericht bij elke lancering.

  3. Het allerbelangrijkste is dat wanneer de PWA om toestemming voor meldingen vraagt, het de browser-stijl prompt toont, niet de systeemeigen Android-dialoog. Dit bewijst dat de delegatie van systeemeigen API’s mislukt.

Dit gedrag is consistent op alle testapparaten (Android 12 & 13) en met APK’s gegenereerd door zowel Bubblewrap als Microsoft’s PWABuilder.

Na uitgebreide debugging heb ik bevestigd dat mijn volledige client-side en publiek toegankelijke serverconfiguratie perfect lijkt te zijn. Het probleem lijkt een subtiel server-side probleem te zijn dat alleen de Android-validator beïnvloedt.

Dit is wat ik al heb geverifieerd:

  • Signing Key & assetlinks.json: De SHA-256-vingerafdruk van mijn android.keystore is een 100% exacte match met de vingerafdruk in mijn live /.well-known/assetlinks.json-bestand.

  • Serverreactie: Mijn server serveert de assetlinks.json-URL met een 200 OK-status, de juiste application/json Content-Type, en geen blokkerende CORS-headers wanneer gecontroleerd met standaard webtools.

  • Android App Config: Het gegenereerde AndroidManifest.xml is correct en bevat de standaard com.google.browserhelper.trusted.DelegationService.

  • Discourse Admin Instellingen: Mijn admin beveiligingsinstellingen voor cors origins en Allowed crawler user agents zijn beide leeg.

Gezien dit specifieke “soft fail” gedrag, is mijn vraag:

Is er een bekende Nginx-regel, firewall-instelling, of een subtiel serverreactieprobleem (zoals een lichte vertraging of een niet-standaard header) in de standaard Discourse zelf-gehoste setup dat de Android-validator zou veroorzaken om een “gedeeltelijk vertrouwen” te verlenen (waardoor de UI op volledig scherm mogelijk wordt), maar het hogere vertrouwensniveau dat nodig is voor systeemeigen API-delegatie te weigeren?

Ik heb alles aan de clientzijde gediagnosticeerd. Elke inzichten in de diepe serverconfiguratie zou zeer gewaardeerd worden.