Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Exécuter des actions sur l'appareil
Les demandeurs peuvent demander à un fournisseur d'effectuer une action. Si l'action est prise en charge par le fournisseur, elle doit être confirmée et effectuée. Dans le cas contraire, elle doit être ignorée.
Nom du groupe de messages
Valeur
Événement d'action sur l'appareil
0x04
Nom de code de l'action de l'appareil
Valeur
Sonnerie
0x01
Faire sonner un appareil
Un cas d'utilisation de ces actions est celui où le demandeur demande au fournisseur de faire sonner l'appareil, par exemple lorsqu'un utilisateur l'a perdu et doit le localiser. Lorsque l'action de sonnerie est reçue, le fournisseur doit commencer à lire un fichier audio préchargé à un volume suffisamment élevé pour que l'utilisateur puisse le localiser. Il est recommandé d'augmenter progressivement le volume sonore, en partant d'un volume faible jusqu'au volume maximal. La sonnerie doit continuer jusqu'à ce qu'une action supplémentaire soit reçue pour l'arrêter ou qu'une valeur de délai avant expiration soit dépassée.
Des données supplémentaires seront incluses dans le message pour indiquer si la sonnerie doit être lancée ou arrêtée. Cela peut être étendu pour prendre en charge les fournisseurs avec plusieurs composants (un écouteur gauche et un écouteur droit). Dans le premier octet, les bits sont définis sur 1 pour demander à la sonnerie de démarrer ou sur 0 pour demander à la sonnerie de s'arrêter.
Par exemple, si le premier octet de données supplémentaires est défini sur :
0x00 (0b00000000) : tous les composants doivent cesser de sonner
0x01 (0b00000001) : faire sonner l'écouteur droit, arrêter de faire sonner l'écouteur gauche
0x02 (0b00000010) : faire sonner l'écouteur gauche, arrêter la sonnerie de l'écouteur droit
0x03 (0b00000011) : sonneries à gauche et à droite
Pour les fournisseurs qui ne prennent pas en charge la sonnerie individuelle, un seul bit doit être pris en compte :
0x00 (0b00000000) : arrêter la sonnerie
0x01 (0b00000001) : commencer à sonner
Le deuxième octet des données supplémentaires, le cas échéant, représente le délai d'expiration en secondes. Cette valeur doit être utilisée par le fournisseur pour déterminer la durée de la sonnerie avant que le téléphone ne se mette en mode silencieux. En se basant sur l'exemple de sonnerie à droite ci-dessus et sur un délai avant expiration de 60 secondes, 0x013C serait transmis en tant que données supplémentaires.
Synchroniser l'état de la sonnerie avec les demandeurs
Les fournisseurs peuvent souhaiter avertir un demandeur lorsque l'état de la sonnerie change, par exemple si un geste provoque l'arrêt de la sonnerie. Le demandeur peut ensuite recevoir le message et mettre à jour l'UI si nécessaire.
Le fournisseur doit respecter le même format de message que celui défini dans l'exemple ci-dessus. Le Seeker écoutera ce message et fournira un accusé de réception lorsqu'il sera reçu.
Confirmer une action
Lorsqu'une action est reçue, elle doit être confirmée pour que le demandeur sache si elle a été effectuée ou non. Si aucune confirmation n'est reçue dans la seconde qui suit l'envoi d'une action (ou si une confirmation négative est reçue), le Seeker suppose que l'action n'est pas actuellement prise en charge.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/13 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/13 (UTC)."],[[["\u003cp\u003eSeekers can request Providers to perform actions, such as ringing, which should be acknowledged and performed if supported.\u003c/p\u003e\n"],["\u003cp\u003eRinging can be initiated and stopped for single or dual components (like earbuds) using specific data values, with optional timeout duration.\u003c/p\u003e\n"],["\u003cp\u003eProviders can notify Seekers of ringing status changes, enabling UI updates on the Seeker's end.\u003c/p\u003e\n"],["\u003cp\u003eSeekers expect acknowledgements within 1 second to confirm action execution, otherwise assuming unsupported functionality.\u003c/p\u003e\n"],["\u003cp\u003eDevice actions use a specific message group and action codes for communication between Seekers and Providers.\u003c/p\u003e\n"]]],["Seekers request Providers to perform actions, like ringing. Providers acknowledge and execute supported actions or ignore unsupported ones. The \"Ring\" action (0x01) initiates a preloaded sound, potentially ramping up in volume until stopped or timed out. The first data byte indicates which components (e.g., left/right) should ring, using bit flags (1 for start, 0 for stop). The second byte sets a timeout in seconds. Providers should update Seekers of changes to the ringing status, and Seekers must acknowledge the action.\n"],null,["Device action\n-------------\n\nSeekers can request that a Provider takes an action. If the action is supported\nby the Provider, it should be acknowledged and performed, otherwise it should be\nignored.\n\n| Message Group Name | Value |\n|---------------------|-------|\n| Device action event | 0x04 |\n\n| Device Action Code Name | Value |\n|-------------------------|-------|\n| Ring | 0x01 |\n\n### Ringing a device\n\nOne use case for these actions is the Seeker requesting the Provider to ring,\nfor example when a user has lost the device and needs to locate it. When the\nring action is received, the Provider should begin playing a preloaded sound\nfile at a high enough volume that the user is able to locate it. It is\nrecommended that the sound be ramped from a low volume to max volume over\ntime. Ringing should continue until an additional action is received\ndirecting a stop, or a timeout value has passed.\n\nAdditional data will be included in the message to indicate whether the ringing\nshould be started or stopped, which can be expanded to support Providers with\nmultiple components (a left and right bud). In the first byte, bits will be set\nto 1 to request a ring to start or 0 to request a ring to stop.\n\nFor example, if the first byte of additional data is set to:\n\n- 0x00 (0b00000000): All components should stop ringing\n- 0x01 (0b00000001): Ring right, stop ringing left\n- 0x02 (0b00000010): Ring left, stop ringing right\n- 0x03 (0b00000011): Ring both left and right\n\nOn Providers which do not support individual ringing, only 1 bit should be\nconsidered:\n\n- 0x00 (0b00000000): Stop ringing\n- 0x01 (0b00000001): Start ringing\n\n| **Note:** For Providers that include on-head detection, consider checking whether the device is on-head before ringing at max volume.\n\nThe second byte in additional data, if present, represents the timeout in\nseconds. This value should be used by the Provider to determine how long it\nshould ring before silencing itself. Based off of the ring right example above\nand a timeout of 60 seconds, `0x013C` would be passed as the additional data.\n\n#### Syncing ringing status back to Seekers\n\nProviders may want to notify a Seeker when it changes the ringing status, for\nexample if a gesture causes the ringing to stop. The Seeker can then receive\nthe message and update the UI if necessary.\n\nThe Provider should follow the same message format as defined in the example\nabove. Seeker's will listen for this message and provide an acknowledgement when\nit is received.\n\n### Acknowledging an action\n\nWhen an action is received, it should be\n[acknowledged](/nearby/fast-pair/specifications/extensions/acknowledgement#MessageStreamAcknowledgements \"Acknowledgements\") so that the Seeker knows whether\nor not the action was performed. If an acknowledgement is not received within 1\nsecond of sending an action (or a negative-acknowledgement is received) the\nSeeker will assume the action is not currently supported."]]
