요청자는 제공자에게 조치를 취해 달라고 요청할 수 있습니다. 작업이 제공업체에서 지원되는 경우 승인되고 실행되어야 하며, 그렇지 않으면 무시되어야 합니다.
메시지 그룹 이름
값
기기 작업 이벤트
0x04
기기 작업 코드 이름
값
벨소리
0x01
기기에서 벨소리 울리기
이러한 작업의 한 가지 사용 사례는 사용자가 기기를 분실하여 기기를 찾아야 할 때와 같이 시커가 제공업체에 벨소리를 울려 달라고 요청하는 것입니다. 벨소리 작업이 수신되면 제공자는 사용자가 찾을 수 있을 만큼 충분히 큰 볼륨으로 미리 로드된 사운드 파일을 재생하기 시작해야 합니다. 시간이 지남에 따라 소리가 낮은 볼륨에서 최대 볼륨으로 점차 증가하는 것이 좋습니다. 벨소리는 중지를 지시하는 추가 작업이 수신되거나 제한 시간 값이 지날 때까지 계속되어야 합니다.
벨소리를 시작해야 하는지 중지해야 하는지를 나타내는 추가 데이터가 메시지에 포함되며, 이는 여러 구성요소 (왼쪽 및 오른쪽 이어폰)가 있는 제공업체를 지원하도록 확장할 수 있습니다. 첫 번째 바이트에서 비트는 벨소리 시작을 요청하는 경우 1로 설정되고 벨소리 중지를 요청하는 경우 0으로 설정됩니다.
예를 들어 추가 데이터의 첫 번째 바이트가 다음과 같이 설정된 경우
0x00 (0b00000000): 모든 구성요소의 벨소리가 중지되어야 합니다.
0x01 (0b00000001): 오른쪽 벨소리 울림, 왼쪽 벨소리 울림 중지
0x02 (0b00000010): 왼쪽 벨소리 울림, 오른쪽 벨소리 울림 중지
0x03 (0b00000011): 왼쪽과 오른쪽 모두 울림
개별 벨소리를 지원하지 않는 제공업체에서는 1비트만 고려해야 합니다.
0x00 (0b00000000): 벨 울림 중지
0x01 (0b00000001): 벨소리 시작
추가 데이터의 두 번째 바이트는 있는 경우 초 단위의 제한 시간을 나타냅니다. 이 값은 공급자가 자동으로 소리가 꺼지기 전에 울려야 하는 시간을 결정하는 데 사용해야 합니다. 위의 벨소리 울림 예시와 60초의 제한 시간을 기준으로 0x013C이 추가 데이터로 전달됩니다.
벨소리 울림 상태를 다시 Seekers와 동기화
제공자는 벨소리 상태가 변경될 때, 예를 들어 동작으로 인해 벨소리가 중지되는 경우 탐색기에게 알릴 수 있습니다. 그러면 Seeker가 메시지를 수신하고 필요한 경우 UI를 업데이트할 수 있습니다.
제공자는 위의 예에 정의된 것과 동일한 메시지 형식을 따라야 합니다. 시커는 이 메시지를 수신 대기하고 수신되면 확인을 제공합니다.
작업 확인
작업이 수신되면 시커가 작업이 실행되었는지 알 수 있도록 확인해야 합니다. 작업 전송 후 1초 이내에 확인이 수신되지 않으면 (또는 부정 확인이 수신되면) Seeker는 현재 작업이 지원되지 않는다고 가정합니다.
[null,null,["최종 업데이트: 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."]]
