Dépannage

Identifiez d’abord la couche en échec : fournisseur de portefeuille OneKey, transport matériel ou encodage/décodage QR. Consignez la méthode, le code d’erreur, la version du SDK ou du portefeuille et l’étape ayant échoué.

Une dApp ne trouve pas OneKey

• Confirmez que OneKey est installé et activé dans le profil de navigateur testé. Rechargez la dApp après l’installation.
• Détectez le fournisseur dans le code du navigateur, une fois la page disponible. N’accédez pas à window pendant le rendu serveur.
• Utilisez le fournisseur de votre chaîne. Ne supposez pas qu’un fournisseur injecté par un autre portefeuille appartient à OneKey.
• Suivez le Démarrage rapide dApp ou le guide de votre bibliothèque d’interface de portefeuille.

L’accès au compte ou la signature est refusé

Un refus est une issue utilisateur valide. Effacez l’état d’attente et laissez l’utilisateur réessayer explicitement ; ne continuez pas à ouvrir des demandes d’autorisation ou de signature.

Si le compte ou le réseau change, actualisez l’état de votre application avant de créer la prochaine demande. Pour Ethereum, consultez Accès aux comptes et l’API du fournisseur.

Un appareil USB n’apparaît pas dans la liste

1. Vérifiez que votre navigateur prend en charge WebUSB et que la page est servie dans un contexte sécurisé.
2. Ouvrez le sélecteur USB à partir d’une action utilisateur, comme un bouton de connexion, et sélectionnez l’appareil souhaité.
3. Vérifiez le câble et fermez toute autre application ou tout autre onglet susceptible d’utiliser l’appareil.
4. Relancez la découverte et gérez un résultat vide avant d’appeler une méthode d’appareil.

Suivez le Guide WebUSB. Les exigences diffèrent pour mobile natif et BLE React Native ; les instructions USB de navigateur ne s’appliquent pas à tous les transports.

Une demande attend indéfiniment

Vérifiez si le SDK attend une réponse d’interface, comme un PIN ou un choix de phrase secrète, ou une confirmation sur l’appareil. Enregistrez les gestionnaires avant de lancer un appel et répondez à la demande précise comme décrit dans le guide de l’API Core.

Gardez les opérations d’appareil sérialisées. Si l’utilisateur annule ou si le transport se déconnecte, effacez l’état d’interface en attente et signalez le résultat. Ne rejouez pas automatiquement une demande de signature ou une opération modifiant l’appareil après un résultat incertain.

Une méthode n’est pas prise en charge

Vérifiez la méthode dans la référence de prise en charge des appareils et chaînes, puis vérifiez vos versions du SDK et du micrologiciel. La prise en charge d’une chaîne, d’un appareil ou d’un transport n’implique pas celle de toutes les méthodes.

Une réponse QR ne se décode pas

Vérifiez que vous utilisez le type de registre attendu et que tous les fragments d’une réponse QR multipartie ont été reçus. Faites correspondre la réponse à la demande initiale lorsque le format fournit un identifiant de requête. Consultez le guide QR Ethereum et EVM.

Signaler un problème

Choisissez le dépôt responsable de l’intégration en échec :

Incluez :

• Le comportement attendu et le comportement observé.
• Une reproduction minimale avec des données de test et les étapes exactes.
• La version du SDK/paquet, l’environnement d’exécution, le système, le transport et, si pertinent, le modèle et le micrologiciel de l’appareil.
• Le nom de la méthode, le code d’erreur et un message d’erreur expurgé des données sensibles.

Ne publiez pas de phrases de récupération, clés privées, PIN, phrases secrètes, identifiants d’accès, identifiants de session ni journaux de portefeuille non expurgés. Pour une faille de sécurité présumée, suivez la politique de sécurité du dépôt concerné au lieu de révéler les détails d’exploitation dans une issue publique.