Sur cette page

Déconnexions et reconnexion

Un débranchement USB, une perte du signal BLE, une réinitialisation Bluetooth ou un redémarrage du micrologiciel peuvent interrompre la connexion. Suivez ces étapes pour terminer l’opération interrompue, reconnecter l’appareil et réutiliser le portefeuille sélectionné en toute sécurité.

Ce que le SDK fait déjà

Une déconnexion / reconnexion ordinaire ne fait pas oublier le protocole confirmé connectProtocol. Vous ne choisissez pas de nouveau entre V1 et V2 après une interruption.
Les appels en cours échouent. Le SDK ne rejoue pas la signature, l’effacement ou la mise à jour du micrologiciel.
Protocol V2 conserve l’ordre des appels par appareil. Ne lancez pas un deuxième appel métier pendant la récupération du premier.

Ce que vous devez faire

Abonnez-vous à DEVICE.CONNECT / DEVICE.DISCONNECT une fois au démarrage de l’application.
En cas de DISCONNECT, marquez cette connexion connectId comme occupée/non valide et faites échouer le parcours d’interface actuel. Ne réessayez pas la même méthode ayant des effets de bord.
Effectuez une nouvelle recherche (searchDevices) lorsque l’utilisateur est prêt. Un rebranchement USB ou un nouvel appairage BLE peut créer un nouveau connectId. Mettez en cache les ID USB et BLE séparément. Consultez Identifiants.
Après une nouvelle connexion, actualisez l’état de l’appareil avec getDeviceState. Réutilisez les valeurs persistées de deviceId + passphraseState ; ne persistez pas les données du micrologiciel session_id.
Lors du prochain appel d’adresse / de signature, transmettez la valeur persistée de passphraseState ou useEmptyPassphrase: true. Core reprend la session du micrologiciel dans cette méthode. Ne rouvrez pas une session de portefeuille uniquement pour reconnecter.


import { DEVICE } from '@onekeyfe/hd-core';
 
HardwareSDK.on(DEVICE.DISCONNECT, (payload) => {
  markDisconnected(payload);
  // Fail the open UI flow; do not replay signing or firmware updates.
});
HardwareSDK.on(DEVICE.CONNECT, () => {
  refreshDeviceList();
});

Spécificités BLE

Les autorisations (BLUETOOTH_SCAN / CONNECT, descriptions d’usage Bluetooth iOS, souvent localisation sur Android) doivent rester accordées après l’arrêt du processus. Consultez BLE React Native.
retryCount / timeout contrôlent l’établissement de la connexion avant un appel à l’appareil. Ils ne relancent pas la signature et ne remplacent pas la récupération au niveau de l’application.
Si l’appairage du système est obsolète, arrêtez les tentatives de connexion en boucle. Demandez à l’utilisateur d’oublier l’appareil dans les paramètres Bluetooth du système, puis de l’appairer de nouveau.
Mini n’a pas de BLE. Neo a le BLE mais pas de caméra. Consultez Appareils.

Spécificités USB

WebUSB nécessite une action utilisateur pour afficher de nouveau le sélecteur, sauf si vous transmettez skipWebDevicePrompt sur un appareil encore autorisé. Consultez Paramètres communs.
Un autre onglet ou Bridge qui détient l’appareil peut provoquer une erreur d’acquisition/d’ouverture. Fermez l’autre connexion propriétaire ; n’effectuez pas dispose() en première réaction.

`dispose()`


await HardwareSDK.dispose();

Appelez dispose() uniquement lorsque vous fermez le SDK ou changez env / la pile de transport (par exemple WebUSB → bas niveau). Cet appel supprime toutes les liaisons et tous les curseurs de transport Protocol V2.

N’appelez pas dispose() lors d’une interruption BLE habituelle ou d’un débranchement USB. Recherchez et reconnectez-vous sur la même instance HardwareSDK.

Après le retour de dispose(), vous devez appeler init() de nouveau avant searchDevices.

Redémarrage du micrologiciel

firmwareUpdateV2 / V3 / V4 peuvent entraîner une déconnexion volontaire. Attendez, reconnectez-vous, puis lisez les versions. Ne considérez pas cette interruption comme une mise à jour échouée à rejouer. Consultez Mise à jour du micrologiciel.