🌉 Intégration Hotspot via le Bridge Unifié

Purge déclenchée depuis Display

Sur Android, PURGE_USER_DATA ouvre tvconfig://apps/purge. Si TVconfig annonce la métadonnée fr.tvcast.tvconfig.capability.PURGE_RESULT_V1=true, il renvoie un broadcast ciblé à fr.tvcast.display (fr.tvcast.tvconfig.action.PURGE_RESULT) avec le même request_id et un booléen success. Le host attend ce résultat, remet Display au premier plan puis répond avec payload.completion="completed". Sans cette capacité, le host répond payload.completion="accepted" après l'ouverture du deeplink : la demande est transmise mais pas confirmée. Le payload vide d'un ancien host est également interprété comme accepted.

En mode accepted, le Web affiche une notification informative, ne marque pas la purge comme terminée dans le CMS et ne déclenche pas de redémarrage sur cette seule réponse. Un délai maximal de 120 secondes côté host et de 130 secondes côté web évite une attente infinie en mode confirmé. Une erreur ou un timeout ne relance pas la purge : cela pourrait effectuer deux rotations du mot de passe SoftAP. Seule la réponse explicite « Unknown action: PURGE_USER_DATA » autorise le repli vers PURGE_DATA pour les anciens hosts.

Le pilotage du hotspot par l'application hôte native est réalisé à travers l'API postMessage du Bridge Unifié. Ce mécanisme permet de standardiser les commandes quel que soit le matériel sous-jacent.

Spécifications des Messages

L'application hôte doit implémenter les messages suivants pour supporter la gestion complète du hotspot.

1. Récupérer le statut (HOTSPOT_GET)

Permet de savoir si le hotspot est actuellement activé et de récupérer ses identifiants.

• Requête :

  { "type": "TV_API_REQUEST", "action": "HOTSPOT_GET", "requestId": "..." }

• Réponse attendue :

  {
  	"type": "TV_API_RESPONSE",
  	"requestId": "...",
  	"ok": true,
  	"payload": {
  		"enabled": true,
  		"ssid": "MonWiFi_Hotel",
  		"password": "..."
  	}
  }

2. Démarrer le hotspot (HOTSPOT_SET)

Demande à l'hôte d'activer le point d'accès Wi-Fi.

• Requête :

  {
  	"type": "TV_API_REQUEST",
  	"action": "HOTSPOT_SET",
  	"requestId": "...",
  	"params": { "subAction": "start" }
  }

• Réponse attendue : ok: true une fois que le hotspot est fonctionnel.

3. Arrêter le hotspot (HOTSPOT_SET)

Demande à l'hôte de désactiver le point d'accès Wi-Fi.

• Requête :

  {
  	"type": "TV_API_REQUEST",
  	"action": "HOTSPOT_SET",
  	"requestId": "...",
  	"params": { "subAction": "stop" }
  }

---

🛠️ Implémentation du Bridge

La classe UnifiedPlatformBridge (src/lib/classes/platforms/platformBridge.ts) orchestre ces échanges :

1. Envoi : Elle forge le message JSON et l'envoie à window.parent.
2. Timeout : Elle attend une réponse pendant 5 secondes avant de basculer sur un fallback.
3. Fallback : Si le bridge ne répond pas, le système tente d'utiliser une implémentation native locale (ex: LG webOS direct ou Capacitor Android) si elle est disponible pour la plateforme courante.

Roadmap d'Évolution

• Phase 1 : Implémentation des messages de base (Status, Start, Stop).
• Phase 2 : Gestion des événements asynchrones (ex: notifier l'UI si le hotspot s'arrête suite à une erreur système).
• Phase 3 : Extension aux futurs hôtes (Android natif, nouveaux modèles de Smart TV).

---

Retour à l'index Hotspot | Retour à l'accueil